In the last episode (Nov 02), Steve Kargl said: > On Sat, Nov 02, 2002 at 04:19:10PM -0800, Juli Mallett wrote: > > Keep in mind this only affects linking a closed library, and that > > this situation is a bit absurd, given that a reasonable solution > > exists, and if necessary, can be packaged up nicely... > > "A bit absurd"? Can you explain why it is absurb and can you > give me the reasonable solution that you have? > > > Developers using this sort of environment are asking for trouble. > > It seems to me a serious developer will develop where the tools are > > working and supported (keep in mind this is a issue with a vendor > > LIBRARY being LINKED in, not a TOOL being USED), > > The TOOL was working fine until __sF was made static.
It may work fine for 5.0. There's no guarantee that later on 5.*'s libc.so ABI will diverge even more from 4.*'s libc.so and break it again. > > or set up a proper cross-env to target the platform where the library > > is targettted > > This is what I guess we'll have to do. The 4.* -> 5.* link issue is exactly the same issue as the gcc 2.95 -> 3.0 -> 3.2 C++ ABI one. At least they changed the name mangling so it was physically impossible to let old libs link with new libs, instead of letting people think their program linked okay, only to have it mysteriously fail later. Maybe we should have a freebsd-4-devel package that provides a gcc/g++ 2.95 that will link with 4.* crt0 and libc, etc? -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message