Thanks; I guess that means that for now I keep the production build machine is 4.8-STABLE, and I keep 5.x as a "play" environment until people move over. The fun will begin when migration begins in significant numbers, but I still need to support both! -- -- Karl Denninger (karl_at_denninger.net) Internet Consultant & Kids Rights Activist http://www.denninger.net Tired of spam at your company? LOOK HERE! http://childrens-justice.org Working for family and children's rights http://diversunion.org LOG IN AND GET YOUR TANK STICKERS TODAY! On Sat, Jun 14, 2003 at 12:28:11PM -0500, Dan Nelson wrote: > In the last episode (Jun 14), Karl Denninger said: > > On Sat, Jun 14, 2003 at 09:43:01AM -0700, Doug White wrote: > > > On Sat, 14 Jun 2003, Karl Denninger wrote: > > > > > > > Can it be done with a command-line switch to the compiler or gcc, > > > > or am I consigned to dual-booting? > > > > > > You mean building apps linked against 4.X libs vs. 5.X? With some > > > creative -L flags you might be able to get it to not use > > > /usr/lib/libc* and use /usr/lib/compat/libc* instead, which has > > > copies of certain 4.X libs in it. > > > > > > Let us know if you get it working :) > > > > Will play with that one.... > > That won't work. The reason shared libraries get their versions bumped > and the old ones move into compat is that the ABI changes. Unless you > kept the headers for those old shlibs laying around someplace, gcc will > compile programs using the ABI for the libs in /usr/lib. > > > The problem is that I have a lot of users on the 4.x release(s) of > > the OS, and have binary apps that I'm supporting for them. Linking > > static is an option, but does ugly things to the file sizes. > > That will break the first time a 5.0-compiled library decides to use a > syscall not in 4.x.Received on Sat Jun 14 2003 - 09:58:19 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:11 UTC