On Wed, Nov 12, 2003 at 12:48:25PM -0700, Marc Aurele La France wrote:
>On Tue, 11 Nov 2003, David Dawes wrote:
>> On Mon, Nov 10, 2003 at 03:09:14PM -0500, David Dawes wrote:
>> >On Mon, Nov 10, 2003 at 11:36:54AM -0800, Alan Coopersmith wrote:
>> >>David Dawes wrote:
>> >>> I've noticed that the reference to in6addr_any in xtrans has broken
>> >>> libICE.so compatibility, at least on FreeBSD 4.3. This shows up a
>> >>> runtime loader error when attempting to run applications built against
>> >>> an older version of the library:
>
>> >>> /usr/libexec/ld-elf.so.1: /usr/X11R6/lib/libICE.so.6: Undefined symbol
>> >>> "in6addr_any"
>
>> >>> It is almost certainly related to in6addr_any being a const.
>
>> >>> I'm not sure if this is a localised problem, or if it affects a
>> >>> wider range of platforms. I'm committing a workaround that makes
>> >>> use of IN6ADDR_ANY_INIT when available, and that works here.
>
>> >>> Has anyone seen this to be a problem on other platforms?
>
>> >>We have no problem like that on Solaris - but on Solaris in6addr_any
>> >>is defined in libsocket.so, which libICE.so is linked with, so it
>> >>always automatically gets resolved at runtime. I haven't seen any
>> >>problem reports on other platforms either.
>
>> >On FreeBSD it is in libc.so. I thought that since 'cc' is used to
>> >create libICE.so, it was implicitly linked against -lc, based on the
>> >comment in bsdLib.rules:
>
>> >#ifndef BaseShLibReqs
>> >#define BaseShLibReqs /* -lc implied by $(CC) */
>> >#endif
>
>> >If I add it explicitly it solves the problem.
>
>> Just to follow up on this, I think I've found the reason for the problem.
>> The application I noticed this with was built in 1999 against an older
>> libc (libc.so.3 on FreeBSD 3.x). That older libc doesn't have any IPv6
>> support, so without -lc specified explicitly for libICE.so, the application
>> loads only the old libc that doesn't have in6addr_any. Linking libICE.so
>> explicitly against -lc allows both the old and new libc's to be loaded
>> at runtime, and this seems to work. I'm naively assuming that the new
>> libc gets used solely for the X libs and the old one solely for the
>> app's own code, and that since the X library ABIs should be independent
>> of libc, everything will work happily together.
>
>> However, Matthieu reminded me that explicitly linking our shared libraries
>> against libc can cause problems on some BSD versions that link threaded
>> apps with -lc_r (instead of -lc), and I believe that was one of the main
>> reasons for not linking shared libraries against -lc explicitly on these
>> platforms.
>
>> I'm not sure what the best answer to all of this is.
>
>So the newer libc isn't compatible with the old one?
I believe that's the case. I don't know what the extent of the
incompatibilities is (I think some interfaces were removed).
ldd shows both versions getting loaded when an app is linked against
the old one and libICE.so is linked against the new one:
libm.so.2 => /usr/lib/libm.so.2 (0x28098000)
libXaw3d.so.6 => /usr/X11R6/lib/libXaw3d.so.6 (0x280b4000)
libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x280f1000)
libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x28106000)
libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x2814f000)
libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x28158000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x2816f000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x2817c000)
libxpg4.so.2 => /usr/lib/libxpg4.so.2 (0x28237000)
libc.so.3 => /usr/lib/libc.so.3 (0x2823b000)
libc.so.4 => /usr/lib/libc.so.4 (0x282bb000)
libXThrStub.so.6 => /usr/X11R6/lib/libXThrStub.so.6 (0x28353000)
It is (or at least used to be) considered important on FreeBSD that
old apps continue to run if you choose to install the old system
libraries. They are provided as part of the installation for that
reason. I don't know if what I'm seeing is just a case of good
luck, or whether achieving this sort of compatibility for X
applications would require another approach.
David
--
David Dawes
developer/release engineer The XFree86 Project
www.XFree86.org/~dawes
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
