Problem compiling JUCE static library


#1

I’ve been working with v1.46 for a long time and I am finally upgrading to release v1.51. I’ve got Juce compiling fine and can run any project that does NOT link to Juce with a static library.

My problem is that I want to link with the static library, but when I do I get a bunch of linker errors and warnings. All I’ve done is to create a VS 2008 project using the experimental Jucer that uses the “Linked to Juce Static Library” option. Anyone know what I could be doing wrong? I’ve tried looking up the warning I’m getting but haven’t found much helpful information.

248 Warnings - all the same format, except for lots of different juce classes where the is

1>jucelib_static_Win32_debug.lib(juce_<Juce class name>.obj) : warning LNK4229: invalid directive '/FAILIFMISMATCH:_MSC_VER=1600' encountered; ignored 1>jucelib_static_Win32_debug.lib(juce_<Juce class name>.obj) : warning LNK4229: invalid directive '/FAILIFMISMATCH:_ITERATOR_DEBUG_LEVEL=2' encountered; ignored

385 Errors - all seem to be the same format as these four errors

[code]1>jucelib_static_Win32_debug.lib(juce_.obj) : error LNK2001: unresolved external symbol “void __cdecl std::_Xlength_error(char const *)” (?_Xlength_error@std@@YAXPBD@Z)

1>jucelib_static_Win32_debug.lib(juce_.obj) : error LNK2001: unresolved external symbol “void __cdecl std::_Xout_of_range(char const *)” (?_Xout_of_range@std@@YAXPBD@Z)

1>jucelib_static_Win32_debug.lib(juce_.obj) : error LNK2001: unresolved external symbol “private: static void __cdecl std::locale::facet::_Facet_Register(class std::locale::facet *)” (?_Facet_Register@facet@locale@std@@CAXPAV123@@Z)

1>jucelib_static_Win32_debug.lib(juce_.obj) : error LNK2001: unresolved external symbol “class std::error_category const & __cdecl std::iostream_category(void)” (?iostream_category@std@@YAABVerror_category@1@XZ)[/code]


#2

I’ve never seen that warning before, but it looks like it’s trying to tell you that you’ve built the lib with a different compiler version to the exe…?

Personally I’d recommend not bothering with a static library. Haven’t used one myself for ages, and life’s much simpler without them. What’s you reason for wanting to use one?


#3

Well I’m using VS 2008 to compile both so I don’t think it would be a problem with the compiler.

For your other question… I’m not sure I have a good reason other than I’m working with a project someone else started. In the VS solution I’m trying to upgrade I’ve got the Juce project as well as 4 other projects that use Juce. Removing the old Juce project and replacing it with v1.51 just seemed like the easiest thing to do, but has given me more trouble than I would of guessed.

The way the projects are structured is there are 2 executables and 2 libraries. All projects use Juce, 1 executable links to both libraries, and the 2nd executable links to only 1 library. If I removed the Juce project and wanted to link to Juce’s source files then I assume I would have to attach the Juce files to one of the library projects. Then the linking would take place for those .lib files instead of the Juce .lib file.

I’m not sure I like the sound of this solution but it’s all I can really think of. Any better suggestions?


#4

I use Juce in a static library. It’s so much easier. If I make changes to the Juce source code I can get them compiled instantly without having to re-amalgamate. Through the use of Visual Studio 2008 custom property sheets (and my own environment variables) I can easily switch which version of the Juce source tree I am using (I can choose between my own fork with some customizations, the latest tip, or the 1.51 version). This change affects all my projects at once since they share the property sheet. My browse info always works correctly (except when Juce forward declares certain things in files that sort alphabetically lower than the actual file), and brings up the proper .cpp instead of the amalgamated file.

This having been said, it is certainly possible to have Juce in a static library, and I am 100% confident that any problems you are facing on your end, are related to some changes you have done to your .vcproj file.

If you absolutely have to make the static library function correctly, then you should just start over with a fresh Juce .vcproj, and use that as the basis for building your static library.


#5

It might be a problem with debug vs. release versions of the static Juce lib and the Visual Studio libs. You might try adding libcmtd.lib to the ignore list in your link command to see if that helps.

Also make sure that you are compiling for multi-threaded debug (or release) in the Juce lib as well as your project that links against it.

Hope this helps.


#6

Thanks for the replies everyone, it ended up being a couple of problems you guys had pointed to.

(1) Some of the projects were using the multi-thread debug and some were using multi-threaded DLL
(2) In VS 2010 they allow you to use either 2008 or 2010 toolsets for compiling and my projects were using a mixture

Once I compiled all projects using the multi-threaded debug/release, used only VS 2010 toolsets, and removed library ignores it compiled fine. Somehow I think it had originally worked with a mixture of these settings since I had the library ignores in place.