On Tue, 2003-04-08 at 21:03, Havoc Pennington wrote: > Well, all I'm saying is that it's known and advertised by the > maintainers of glibc that if you statically link or use symbols > starting with __ that your stuff will break - so if you don't want to > stuff to break, you might want to avoid doing those things. ;-) I tend to stray towards the ANSI standard consistently so I don't do things like that, however the libraries I use aren't always as nice :( > Incidentally, if your app is LSB-compliant it will automatically > follow these rules. LSB-compliancy really doesn't *seem* to help game binaries as they typically use several additional libraries, ones that in my case are rather obscure and somewhat difficult to compile properly :| > > How does a commercial or non-commercial (in my case) developer properly > > release binaries for other platforms and avoid all of these currently > > very ugly issues? The last thing users really want to deal with is > > library dependencies, C++ ABI changes, glibc ABI changes, etc. > > For glibc, not knowing specifically what breakage you are seeing, the > way you need to deal with the change is to only use what you're > supposed to. Don't statically link to glibc, and don't use internal > symbols starting with __. If you're using the well-specified official > ABI of glibc, and your app still breaks, then that's considered a bug. ./ags: /lib/libc.so.6: version `GLIBC_2.3' not found (required by ./ags) ./ags: /lib/libc.so.6: version `GCC_3.0' not found (required by ./ags) For example the above came from one of my users, I'm guessing the above means I need to somehow link against the compat-libstdc++ and use gcc296 to compile the binaries instead of gcc3.2.2 included with RedHat 9. I guess the main reason I got set on doing static linking is because Loki did the same thing when they distributed their binaries. Which I'm grateful for, because I cannot run their older dynamic binaries on my box even with the compatibility libraries installed. Weird stuff happens. > If you're heavily relying on old thread behavior, at least for now you > can also set LD_ASSUME_KERNEL=2.2.5 as a workaround. Thankfully I don't do any thread stuff directly, and Allegro, the main library that's used seems to be quite clean in it's thread implementation so far. > For C++, the matter is more complicated; the gcc project has not > wanted to commit to a stable ABI until they had a test suite > validating that the ABI was conformant to standard ABI specs. What > I've heard is that they have that now and once we upgrade to latest > gcc the ABI will not change again. Is this true of RedHat 9's version of gcc, or of gcc 3.3 when it becomes the version in RedHat? > Re: library dependencies, if you follow the LSB rules this will also > be a non-issue. Though the LSB doesn't cover C++ yet due to the > historical lack of ABI commitment from the gcc project, that problem > should be solved pretty quickly now that there is commitment. > > So for now users do need to install a compat-libstdc++ in order to run > C++ binaries from 7.3 on 8 or 9. However if they install > compat-libstdc++ then all 7.3 C++ binaries should run fine. But what about users of other distributions, such as Mandrake, Debian, etc. honestly I'd love to say I don't care about them because I much prefer RedHat, but that wouldn't make me very popular ;) Do they have equivalent versions of compatability libraries for their distributions? How does one go about specifying the compatability libstdc++ instead of the normal one when using gcc296 or is that somehow automatic? Should I static link against just libstdc++ and the obscure libraries I use and dynamically link libc, libdl, libm, libpthread, etc.? Anyway, the input / help is greatly appreciated I've been battling with this issue for several weeks now, and very few people are informed enough to give me a good answer. -- Shawn <drevil@xxxxxxxxxxxx> http://www.warpcore.org/
