Re: The broken libjpeg-6b is in RH 5.1
> - libtool does not support the concept of inter-library dependencies
> (see its author's page about this at
> http://www.profitpress.com/libtool/deplibs.html - he has valid reasons,
> but it is unfortunate for Linux).
1) group of Debian developers could try and work together to get him
the information he needs, or
2) Debian could fund his creation of this feature. It's important to
us, I think, and it's important to the free software community at
large. Although lower-profile than Gnome, it seems important enough
to spend money on.
> - Recent versions of libtool compile everything with an explicit -rpath
> setting. Binaries built with it cannot be run on systems that have the
> same libraries, but in different locations.
> An example of this problematic behaviour is with Red Hat's TriTeal CDE
> 1.2 on Debian "hamm" systems: the CDE is libc5, and was compiled -rpath
> /usr/X11R6/lib . Thus, on a Debian "hamm" system, ld.so only looks for
> the X libraries there, and thinks it finds them, but they are the wrong
> ones: on Debian "hamm" (and thus, Debian 2.0), /usr/X11R6/lib contains
> X libraries for use with libc6. The result of this is that many CDE
> applications dump core and require editing of their binaries (replacing
> the RPATH in the Dynamic Section (see objdump --all-headers) with NULLs)
> before they can be run successfully.
Could someone who is sufficiently knowledgable (you?) build a tool to
do this automatically that could be run from in debian/rules---so that
when people run lintian on their packages, and it bitches about the
rpath, people can add a couple of lines like:
find -type f -name '*.so.*' | xargs -r remove-rpath
find -perm +x | xargs -r remove-rpath
to debian/rules and have the problem zapped?
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com