Hi, i’m a pro license holder, and need some help to solve an issue i’m having with JUCE HuckleBerry 5
I’m running MinGW GCC compiler on windows 10 home edition. I get the error message below when trying to build the
"hello world" example project in CLion IDE 2017.2 with bundled CMake 3.8.2, here is what i get below
“C:\Program Files\JetBrains\CLion 2017.2\bin\cmake\bin\cmake.exe” --build C:\JUCE\examples\HelloWorld\Source\cmake-build-debug --target Source – -j 1
Scanning dependencies of target Source
[ 33%] Building CXX object CMakeFiles/Source.dir/Main.cpp.obj
[ 66%] Building CXX object CMakeFiles/Source.dir/MainComponent.cpp.obj
[100%] Linking CXX executable Source.exe
CMakeFiles\Source.dir/objects.a(Main.cpp.obj): In function WinMain@16': C:/JUCE/examples/HelloWorld/Source/Main.cpp:133: undefined reference tojuce::JUCEApplicationBase::createInstance’
C:/JUCE/examples/HelloWorld/Source/Main.cpp:133: undefined reference to juce::JUCEApplicationBase::main()' CMakeFiles\Source.dir/objects.a(Main.cpp.obj): In function_static_initialization_and_destruction_0’:
C:/JUCE/modules/juce_core/juce_core.h:342: undefined reference to juce::this_will_fail_to_link_if_some_of_your_compile_units_are_built_in_release_mode::this_will_fail_to_link_if_some_of_your_compile_units_are_built_in_release_mode()' CMakeFiles\Source.dir/objects.a(Main.cpp.obj): In functionZN16HelloWorldWindowC1Ev’:
C:/JUCE/examples/HelloWorld/Source/Main.cpp:42: undefined reference to juce::LookAndFeel::getDefaultLookAndFeel()' C:/JUCE/examples/HelloWorld/Source/Main.cpp:42: undefined reference tojuce::LookAndFeel::findColour(int) const’
C:/JUCE/examples/HelloWorld/Source/Main.cpp:44: undefined reference to juce::String::String(char const*)' C:/JUCE/examples/HelloWorld/Source/Main.cpp:44: undefined reference tojuce::DocumentWindow::DocumentWindow(juce::String const&, juce::Colour, int, bool)'
C:/JUCE/examples/HelloWorld/Source/Main.cpp:44: undefined reference to juce::String::~String()' C:/JUCE/examples/HelloWorld/Source/Main.cpp:42: undefined reference tojuce::Colour::~Colour()'
C:/JUCE/examples/HelloWorld/Source/Main.cpp:47: undefined reference to juce::ResizableWindow::setContentOwned(juce::Component*, bool)' C:/JUCE/examples/HelloWorld/Source/Main.cpp:50: undefined reference tojuce::Component::centreWithSize(int, int)'
C:/JUCE/examples/HelloWorld/Source/Main.cpp:53: undefined reference to juce::Component::setVisible(bool)' C:/JUCE/examples/HelloWorld/Source/Main.cpp:44: undefined reference tojuce::String::~String()'
C:/JUCE/examples/HelloWorld/Source/Main.cpp:42: undefined reference to juce::Colour::~Colour()' C:/JUCE/examples/HelloWorld/Source/Main.cpp:44: undefined reference tojuce::DocumentWindow::~DocumentWindow()'
CMakeFiles\Source.dir/objects.a(Main.cpp.obj): In function ZN16HelloWorldWindowD1Ev': C:/JUCE/examples/HelloWorld/Source/Main.cpp:57: undefined reference tojuce::DocumentWindow::~DocumentWindow()‘
CMakeFiles\Source.dir/objects.a(Main.cpp.obj): In function `ZN16HelloWorldWindow18closeButtonPressedEv’:
As you can see, CMake is compiling two source files:
[ 33%] Building CXX object CMakeFiles/Source.dir/Main.cpp.obj
[ 66%] Building CXX object CMakeFiles/Source.dir/MainComponent.cpp.obj
then it is trying to link the executable
[100%] Linking CXX executable Source.exe
but it fails with a bunch of linker errors.
The linker is complaining that it cannot find any symbols from JUCE. And it is rightfully complaining, since CMake didn’t compile any of the JUCE modules.
The HelloWorld example project depends on 6 JUCE modules: juce_core, juce_data_structures, juce_events, juce_graphics, juce_gui_basics, and juce_gui_extra. You need to make sure that these JUCE modules are compiled and then linked with the object files that are specific to the HelloWorld project.
Thanks for replying, i assumed the 6 JUCE modules were included by #include “…/JuceLibraryCode/JuceHeader.h”,
when preprocessor runs, which i can clearly see in main.cpp and
MainComponent .h, i can also see include gaurd (#pragma once) in JuceHeader.h.
Obviously all 6 modules are being included, i’ve tested cmake command
include_directories and it finds all modules no problem. The problem seems
to be something to do with something in scope of JUCE::, maybe a file is
missing ? I tried #include with my own files in various different
locations, and cmake compiled and built the small 3 file project no
problem, so i’m confused when you say cmake isn’t actually compiling any of
the 6 JUCE modules, even though both source files Main.cpp and
MainComponent.cpp #include “…/JuceLibraryCode/JuceHeader.h”, and i can see
all 6 modules in JuceHeader.h, so i’m confused as Cmake isn’t complaining
that it can’t actually find any files (“no such file or directory”), so
please help me further investigate and resolve this issue, i am a pro
license holder, you can find my license details on your system
Thanks
Thanks for swift reply, i understand your point. Obviously if this is whats
causing the problem, then maybe i have to import all the .cpp files in to
CLion IDE, from all 6 modules, or discover whether or not cmake has a
command to search for .cpp files in the 6 module folders, either way, then
maybe this may satisfy the linker ? This still puzzles me as to which .cpp
file is actually responsible for the scope error i often see
"JUCE::someclassmethod", undefined reference, i can’t find a class, header
or source file named “JUCE”, so once again i’m confused, i’m also confused
with declaration “class JUCE_API someclassname”, i’ve never seen such
syntax in C++ whereby 2 seperate names with a space in between have been
used to declare a class name, please enlighten me sir, much appreciated
Thanks for your time & help
…and just a comment that if you’re not familiar with how C++ linking works, then trying to roll your own makefile and use MINGW is really jumping in at the deep end. Why not start with Visual Studio and let the Projucer handle all the project generation for you.
I have found an issue with your JUCE library. What i have discovered is
that a source file is refering to
a folder that does not seem to exist. #include statements in
TestEntries.cpp located at
C:\JUCE\examples\Demo\Source\Demos\Box2DTests, refers to 2 files as shown
below
but after seeing this error
C:\JUCE\examples\Demo\Source\Demos\Box2DTests\TestEntries.cpp:19:31: fatal
error: …/Framework/Test.h: No such file or directory
i looked in this location only to see that no such directory “Framework” or
files “Test.h” or “Render.h” actually exists, so i’m assuming this is
a missing directory, it just doesn’t make sense. Also, it’s very annoying
that the projucer only supports the following IDE’s
Xcode
Visual Studio
Linux Makefile
Android
Codeblocks
Due to this inconvenience of not supporting various other IDE’s such as
jetbrains CLion etc, personally, i beleive it’s about time the designers of
the projucer introduce a new flexible export feature, implemented in a way
that simplifys the entire process of exporting all required module source
and header files from the projucer, to a desired directory location,
enabling users to then import those files into their IDE of choice (CLion
IDE etc)
Restricting users to only the above mentioned IDE’s, is extremely
unacceptable and very annoying. It’s important to understand that users
have their own
personel preference of IDE they want to work in, so please do something
about this annoying issue as soon as possible, to make us developers life
more
fun and savvy. Projucer helps generate code for specific types of projects
(GUI, OpenGL, Static library etc), but it’s extremely annoying when one
has to waste time doing alkinds of cumbersome inconvenient things like
having to manually (drag & drop) copy the projucer generated files to a
desired
location, in order to import those files (modules) into an IDE of choice
(jetbrains CLion etc). CLion does have the ability to import source files
but the process can be much clearer and simplified if a new flexible
"export project" feature is implemented into the projucer, instead of just
the current available options on the “target platforms :” section in
projucers new project dialogue. Not all developers are running Linux at the
moment
maybe in future, and i don’t use Visual Studio or Xcode, so it makes sense
for a new export project feature to be added to the projucer. I hope you
understand what i’ve explained, so far i havn’t had any success building
even 1 JUCE application, not even examples (hello world etc). Of course i
will start using Linux in future, i love the Linux open source platform,
but at the moment i’m using windows 10 Home, so we definetly need a much
more streamlined elegant way to export projucer generated projects to a
directory (or new directory) location, then import all those files into
IDE’s such as CLion, which is the IDE i’m currently using. I havn’t got
time to implement this functionality into projucer myself, as i’m busy
with my own idea’s (useful tools, home automation systems etc), so please
do atleast discuss this issue with your team members and hopefully come
to a conclusion as to what type of new export project feature can be
introduced to the projucer
Yep, we’ve discussed it before, and have no immediate plans to add CLion support.
It would be of interest to only a tiny handful of our users, and supporting each export target is a very big ongoing commitment for us, as it adds a testing burden to everything we do in future.
Plus: people are already using JUCE in CLion. Like was said above in this thread, it’s only a matter of throwing a handful of CPP files into your build.
If you want to go off-piste and not use the projucer (as lots of people do) then it’s up to you to manage your own build setup. The file I linked to above contains everything you need to know about how to manually include modules in a non-projucer based build system, and it’s really not difficult.
I think that these IDEs cover almost everyone. The fact that CLion forces you to use CMake and not any other project/solution (one of them being the leader on their respective platform) is their issue. Even if I like CMake a lot.
@silentwind: I played a bit with CLion 2017.2, and I made this CMakeLists.txt file that you can use to build the HelloWorld project: CMakeLists.txt
I hope this helps you getting started with JUCE using CLion.
I am also actively working on a project called JUCE.cmake (https://github.com/McMartin/JUCE.cmake), which makes it possible to use CMake (and IDE built on top of CMake like CLion and QtCreator) to build JUCE projects. Unfortunately, JUCE.cmake doesn’t support JUCE 5, nor the MinGW compiler yet, but it will come in the future. Stay tuned!
Thanks for your reply sir. Well, after some time spent tinkering around
with various modules, eventually i was able to build a static library
for 1 JUCE module, but only after commenting out an error on line 56 in
header file juce_TargetPlatform.h, along with a few warning messages,
please see below
juce_graphics.cpp line 55
#if JUCE_MINGW && JUCE_USE_DIRECTWRITE #warning “DirectWrite not currently implemented with mingw…” #undef JUCE_USE_DIRECTWRITE #endif
Is direct write an essential component ?
What alternative solutions do you suggest ?
Must i try a different compiler, e.g CLang LLVM etc ?
juce_TargetPlatform.h line 56
#error “No global header file was included!”
i’m confused as to which file this error refers to
I also want to know when JUCE update is due for release
DirectWrite is useful for advanced text layout. Like I already said, I’d strongly recommend just using Visual Studio to get started, and move on to other unsupported build systems when you have more of an idea how everything works. We don’t officially support or test MINGW, we rely on user contributions to keep it working.
Try looking at the line where the error is. It explains it right there:
/*
Most projects will contain a global header file containing various settings that
should be applied to all the code in your project. If you use the projucer, it'll
set up a global header file for you automatically, but if you're doing things manually,
you may want to set the JUCE_APP_CONFIG_HEADER macro with the name of a file to include,
or just include one before all the module cpp files, in which you set
JUCE_GLOBAL_MODULE_SETTINGS_INCLUDED=1 to silence this error.
(Or if you don't need a global header, then you can just define JUCE_GLOBAL_MODULE_SETTINGS_INCLUDED
globally to avoid this error).
Note for people who hit this error when trying to compile a JUCE project created by
a pre-v4.2 version of the Introjucer/Projucer, it's very easy to fix: just re-save
your project with the latest version of the Projucer, and it'll magically fix this!
*/
#error "No global header file was included!"
Ok, well i don’t use visual studio because of the amount of con’s it has,
i.e unnecessary bloat code (libraries etc), license confusion and
complications, CLion is much more lightweight and licensing is more
straightforward and less expensive than visual studio. Please let me know
which other variations of GCC compilers officially supported by JUCE, other
than MinGW ? Also let me know if CLang LLVM and other popular compilers can
be used with JUCE with minimal issues, as i hate Visual Studio, not my
personal preference. Surly JUCE supports other GCC compilers other than
MinGW GCC ? Maybe you can tell me what i need to know for a custom GCC
build ? But do let me know if compilers CLang LLVM, or Intel will be
adeqate ?
Yeah, I was the same before, but then I realised, that not having to worry about all that stuff reduces my time to market significantly.
By removing your so called bloat, you add additional work searching solutions, that were already solved by the IDE.
It is probably just a matter of perspective.
But it is totally fine, if you have your personal preference, nobody can argue with that…
I don’t have nearly the same experience. You can have VS with just the core C++, as for any other compiler. You don’t need MFC or ATL or C# or all that stuff. Just install the core C++, and that’s it.
And even if you did install them, the projucer projects are barebone and don’t use them, so no bloat anywhere. And the support for VS is far better than mingW (did finally release their 64bits compiler?).
Intel compiler works also really well… in VS. Don’t forget that it is not the same as Intel Compiler for Linux, different team, and they mimick cl, not gcc (recall it’s icl on Windows, not icc).
