Linux libraries
Author
Suppose you were modding a game. The game SDK baseline is gcc 2.95. You are using a newer gcc to compile a dll(.so) for this game. There are users that have these old versions of glibc that will obviously not run these newer dlls(.so).
Are there any options to get around this other than installing the old gcc 2.95 and recompiling it?
Is it safe to compile the .so and static link to the newer glibc(with the assumption that the user will then not need the newer glibc in this case) if the game only communicated plain basic data across the dll boundary, no complex dynamic types?
i wouldn't worry about that. Most users upgrade regularly compared to windows, and most opensource libraries (glibc in particular) remain backwards compatible for a long time (until its doesn't break the release or its long been deprecated).
I would take a lucky chance with this, although be warned its not always the case (maya relies heavily on old libraries).
why not try it out if you can?
I would take a lucky chance with this, although be warned its not always the case (maya relies heavily on old libraries).
why not try it out if you can?
Author
My experience says otherwise. Many linux server administrators for games have servers that still run old versions, and in some cases don't have the option of upgrading. Also I think I heard 3.x binaries are not compatible with 2.95 libraries or something like that. I wouldn't be here asking if there weren't significant users complaining about not being able to run. "I can run Enemy Territory fine, but your mod won't run for me, wtf!"
I don't know anyone personally that can test my statically linked library on a 2.95 machine. Anyone care to help me out?
I don't know anyone personally that can test my statically linked library on a 2.95 machine. Anyone care to help me out?
Bear in mind that (I think) the C++ ABI changed on gcc between 2.95 and 3.0
Of course this doesn't affect programs written in C, nor those which only use C linkages (even if they're in C++). It's only relevant for programs in C++ which use C++ linkages. This includes libstdc++ however.
libc is of course a C library and therefore not affected by this change. Neither is this a Linux-specific change, but applies to gcc on all platforms.
libc itself should generally speaking, be independent of what gcc version you use. I believe that its ABI is backwards compatible from a long time ago (but not necessarily forward compatible).
I also see no reason why a game mod library need to use the C runtime particularly. Malloc/Free perhaps, but nothing else. Maybe not even those if the game provides its own memory allocation functions.
A game could even insist that its mods did not use the C library runtime, so that everything goes via functions that it provides.
Mark
Of course this doesn't affect programs written in C, nor those which only use C linkages (even if they're in C++). It's only relevant for programs in C++ which use C++ linkages. This includes libstdc++ however.
libc is of course a C library and therefore not affected by this change. Neither is this a Linux-specific change, but applies to gcc on all platforms.
libc itself should generally speaking, be independent of what gcc version you use. I believe that its ABI is backwards compatible from a long time ago (but not necessarily forward compatible).
I also see no reason why a game mod library need to use the C runtime particularly. Malloc/Free perhaps, but nothing else. Maybe not even those if the game provides its own memory allocation functions.
A game could even insist that its mods did not use the C library runtime, so that everything goes via functions that it provides.
Mark
Author
I haven't been developing on linux for long, so please forgive my linux ignorance. The project in question is actually a bot library for Enemy Territory among other games. http://www.omni-bot.de
Enemy Territory, being a somewhat old game apparently uses 2.95 and GLIBC_2.1 as the minimum spec. It uses pure C (no c++). My bot dll/.so library however is entirely C++, and I export the function like so:
extern "C"
{
// function: ExportBotFunctionsFromDLL
// Allow the bot dll to fill in a struct of bot functions the interface
// can then call.
OMNIBOT_API void ExportBotFunctionsFromDLL(Bot_EngineFuncs_t *_pBotFuncs);
}
This gets a struct of function pointers back to the game.
I'm running debian sarge with a newer version of gcc, so it ends up requiring GLIBC_2.3, and refusing to load the bot dll on systems that will run the base line stuff the game uses(GLIBC_2.1 I think). Perhaps because my bot also uses libstdc++. Unfortunately this seems to be a significant amount of people.
I want my bot to be able to run with older installs as well. It took me a long time to get even what I have now set up to a state I could actually compile stuff in, I'd rather not have to do it again with an older distro if possible.
Any linux gurus have any alternatives? Or am I doomed to downgrade to a new distro?
Enemy Territory, being a somewhat old game apparently uses 2.95 and GLIBC_2.1 as the minimum spec. It uses pure C (no c++). My bot dll/.so library however is entirely C++, and I export the function like so:
extern "C"
{
// function: ExportBotFunctionsFromDLL
// Allow the bot dll to fill in a struct of bot functions the interface
// can then call.
OMNIBOT_API void ExportBotFunctionsFromDLL(Bot_EngineFuncs_t *_pBotFuncs);
}
This gets a struct of function pointers back to the game.
I'm running debian sarge with a newer version of gcc, so it ends up requiring GLIBC_2.3, and refusing to load the bot dll on systems that will run the base line stuff the game uses(GLIBC_2.1 I think). Perhaps because my bot also uses libstdc++. Unfortunately this seems to be a significant amount of people.
I want my bot to be able to run with older installs as well. It took me a long time to get even what I have now set up to a state I could actually compile stuff in, I'd rather not have to do it again with an older distro if possible.
Any linux gurus have any alternatives? Or am I doomed to downgrade to a new distro?
You might be able to sort it out, by statically linkling the C library and/or libstdc++
This shouldn't bloat your .so very much, as you probably only use a few functions from these libraries, so not very much of them will be included.
I'm not totally sure however whether that will have any knock-on effects on linking against a dynamic binary. It should be ok.
I'm also not totally sure how to static-link these standard libraries. Perhaps you'll have to tell the linker to ignore its own idea of what the standard libraries are, and instead provide your own suggestions for it to use.
This would of course mean linking against libc.a instead of libc.so (and similarly for the stdc++)
In principle you should be able to link against static versions of the libraries, even when producing a dynamically linked executable. What I'm not sure about, is whether it would work.
Mark
This shouldn't bloat your .so very much, as you probably only use a few functions from these libraries, so not very much of them will be included.
I'm not totally sure however whether that will have any knock-on effects on linking against a dynamic binary. It should be ok.
I'm also not totally sure how to static-link these standard libraries. Perhaps you'll have to tell the linker to ignore its own idea of what the standard libraries are, and instead provide your own suggestions for it to use.
This would of course mean linking against libc.a instead of libc.so (and similarly for the stdc++)
In principle you should be able to link against static versions of the libraries, even when producing a dynamically linked executable. What I'm not sure about, is whether it would work.
Mark
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
