Re: "Symbol X has different size in shared object" bug reappears
>>>> Martin Buchholz writes:
On non-Linux platforms, we build XEmacs using a runpath that is
computed from the link path. For example, we do this while linking:
-L/usr/local/lib -L/usr/ccs/lib
-Xlinker -R/usr/dt/lib:/usr/openwin/lib
-L/usr/dt/lib -L/usr/openwin/lib
(Note that there are no shared libs in /usr/local/lib or
/usr/ccs/lib...)
On Solaris, this is essential, because the default runpath contains
only /usr/lib and not /usr/openwin/lib, so we could never build an
X-capable XEmacs.
I've generally felt that we should be doing this even on
platforms
like Linux where /etc/ld.so.conf gives us the runtime library search
path. However, Steve was strong in his insistence that we don't
specify a run-path via -R, and that we let /etc/ld.so.conf win out.
I've never understood Steve's opinion on this, and claim that
it's led
in part to the current Xaw3d disaster.
If we do the same thing on Linux, and link like this:
-L /usr/X11R6/lib -R /usr/X11R6/lib -L /usr/lib -R /usr/lib
Just one note: /usr/lib and /lib are searched by default by the
dynamic linker, it always look's there [1]
(syntax might differ) we would be guaranteed not to get surprised by
a
AFAIK -Wl,--rpath=/usr/X11R6/lib.
rogue Xaw.so which is actually a Xaw3d library, because our link
path
and our run path would be the same. We can still lose if the system
is upgraded or the binary is transported to another system, but that
problem exists on every system.
We should try it at least for those paths the user specifies as
special Linkpath.
Andreas
Footnotes:
[1] If you configured glibc with --prefix=/usr which is done with
every distribution.
--
Andreas Jaeger
SuSE Labs aj(a)suse.de
private aj(a)arthur.rhein-neckar.de