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

Reply via email to