Building a library with another library

Started by
5 comments, last by WhiskyJoe 10 years, 9 months ago

Hello people,

So lately I have been starting to work on a 2D game engine for the fun of it. Although it's just for the fun of it, should it one day be something worthwhile, I would like to share it with others.

Now the problem I have run in to has to do with the fact that I want to compile the engine into a static library, but as a base, I am working with SDL (or SFML, haven't really decided yet). Because I want the user to only have to include 1 dependency, I link it with the library I am making. Effectively I am just abstracting away other libraries.

Now this is working fine and all, but I stumble upon the lovely warnings:


1>SDL2_image.lib(SDL2_image.dll) : warning LNK4006: __NULL_IMPORT_DESCRIPTOR already defined in SDL2.lib(SDL2.dll); second definition ignored
1>SDL2_image.lib(SDL2_image.dll) : warning LNK4221: This object file does not define any previously undefined public symbols, so it will not be used by any link operation that consumes this library

Now I have found several solution, or rather answers to "fix" this.

The most common answer is to simply let the user link with the library, but that is exactly the thing I want to prevent.

One other way is to prevent defining the same symbols or make sure they're the same if it can't be prevented, but I don't have access to SDL nor do I really want fiddle around in it.

The last option is to ignore it, mostly it will work out fine anyway, be it the fact that I don't like the "mostly" part.

So my question to you people: What do you guys advice on doing about this? Building a library that consists of other libraries.

Perhaps there are some more elegant or better solutions. Anything at all would help. smile.png

Advertisement

May I ask what did you do to link that in the first place? You say you're making a static library but as far as I know static libraries can't automatically reference other libraries because they're just archives of object files, so the other libraries it needs have to be linked when the program is built (I think I saw somewhere a workaround with GCC that tells the toolchain to include other libraries, but I'm not sure how reliable is that).

Don't pay much attention to "the hedgehog" in my nick, it's just because "Sik" was already taken =/ By the way, Sik is pronounced like seek, not like sick.

May I ask what did you do to link that in the first place? You say you're making a static library but as far as I know static libraries can't automatically reference other libraries because they're just archives of object files, so the other libraries it needs have to be linked when the program is built (I think I saw somewhere a workaround with GCC that tells the toolchain to include other libraries, but I'm not sure how reliable is that).

I add them to the Additional Dependencies in the projects configuration -> Librarian

http://www.joeyfladderak.com/ImageUploads/20130710123336467.png

CMake will automatically link dependent libraries of libraries you are linking, provided you correctly specified them in the TARGET_LINK_LIBRARIES of the library you are linking too. CMake 2.8.11 also added some interesting possibilities for inheriting compiler/linker options and public include directories using the same mechanism.

That only works for targets you specified within CMake though, not some .lib you are pulling in from somewhere precompiled. There is probably a way to get this done (I faintly remember reading about specifying external libraries) but I haven't actively used it so far.

Unfortunately you can't get rid of the warning if you link the items together into a static lib. You have to step up a level and link the libraries from the executable directly in order to remove the warning. This sucks but it is the only real option given that every link library has this descriptor as the terminal for the list of sections in the import descriptions. I have ended up with this same problem myself and found that while annoying, it can not actually cause you any problems so long as you *know* the executable will not attempt to link the same libraries twice. You'd get multiply defined symbols in that case anyway so it *should* be impossible. An example of this problem can be found in the SFML libraries when built statically, due to SFML building statically but using GL, AL and Freetype DLL's, it generates this warning. It is completely safe to ignore in this case and can't cause problems unless for instance those libraries were linked from a DLL the exe used or tried to link to those libraries from the exe directly. (Of course the possible problems end up leading to DLL hell issues thanks to Window's crappy memory model for shared libraries, though sometimes it can actually be useful in goofball cases.)

As to the CMake suggestion BitMaster gives, you could check out: CMake 5 which is an overview of the new 2.8.11 abilities.

I add them to the Additional Dependencies in the projects configuration -> Librarian

Don't do that. Create a post build step to merge the resulting libraries, e.g.

lib.exe /OUT:CombinedLib.lib lib1.lib lib2.lib lib3.lib

I add them to the Additional Dependencies in the projects configuration -> Librarian

Don't do that. Create a post build step to merge the resulting libraries, e.g.

lib.exe /OUT:CombinedLib.lib lib1.lib lib2.lib lib3.lib

Wouldn't that in theory still give the same problem?

Also, what would lib.exe be?

This topic is closed to new replies.

Advertisement