Properly deploying static libraries?

#1

Just a minor issue I’m having here. I have a static library all set and compiled. Since this was a release version, I thought it’d be best to go ahead and compile it using my release configuration (IE, fully optimized, no debugging crap).
That works just fine. However, I have problems whenever I add this library ass a dependency to another project that’s in debug mode. The particular error I get is this:
“warning LNK4204 … is missing debugging information for referencing module; linking object as if no debug info”

Of course, if I go back and recompile my static library using the debug configuration, I won’t get this error. But what I can’t help but wonder is that every time I use another static library (say, openmayaui.lib), I never get a warning like this, even though I’m still using the same library regardless of whether or not I’m in debug mode for my current project. But I somehow doubt that libraries like those included in the Maya API are unoptimized debug releases.
So I have to ask, is there some specific way that I should be compiling my static libraries so that they’ll do well when used in projects that are compiled in both debug and release configurations? Should I just be compiling an optimized build and include debugging info, or something else?

Thanks

#2

not sure if this relates to your problem, but openmayaui is a dynamic library innit?

#3

That’s about right. Static libraries are built into the main binary while shared are, well, not. This means that it’s a lot less problematic for the linker if they’re all compiled with the same symbols/options and while linking nodebug libs with debug code isn’t quite the same as trying to link x86 code with PPC libs it could cause problems with debugging if a problem is related to something being done by code in the libs.

The best way to sort this would probably be to have differently named libs compiled side-by-side and most IDEs these days allow you to have a different set of options for debug/final code so you can have dmy.lib and my.lib compiled at the same time and just switch your options set when you want to debug.

Of course, if you have a lot of programs sharing these libs you might want to look into creating dynamic/shared libs. How to do this will depend on your compiler and it’s not something I’ve ever looked at in windows.

#4

Eh, for my purposes, taking the type to pull everything together as a dynamic library might not be worth it. Not that it’s terribly difficult to do that, but it can kind of be a pain in the ass. Well, I’ll see.
But I had a feeling that I was going to have to keep them as separate builds like that, so thanks for confirming what I was suspecting. :slight_smile:

#5

I’ve had some similar issues in the past. I believe the answer that I ended up going with is to disable using the runtime/MFC as DLLs, and just link everything into the library that it needs (Properties/General/Use of MFC:Use standard windows libraries). This has advantages and disadvantages. It will make your executables larger. If they update the runtime, it won’t call the updated versions of the functions without a recompile. I believe that this is what they do with Maya and other static libs.

Although, for the specific problem of debug/release conflicting, usually I have a different output directory for each configuration, and use dependencies to link properly across.

#6

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.