Re: in6addr_any reference breaks libICE.so compatibility
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? Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: in6addr_any reference breaks libICE.so compatibility
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
Re: in6addr_any reference breaks libICE.so compatibility
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. -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc.- Sun Software Group User Experience Engineering: G11N: X Window System ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: in6addr_any reference breaks libICE.so compatibility
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. Maybe it needs to be added explicitly in OpenBSDLib.rules too? David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
