[arch-general] What about unused direct libraries in ELF files?

[Gerardo Exequiel Pozzi]

Hi

Like my previus message about RPATH in ELF files, I am interested in
know opinions of arch-dev-team about ELF files that have direct unused
libraries.
(I will open a ticket if considered this important in Arch Linux, and
gradually helping to fix it for each package that are necessary, like
for rpath [#1], also a check for namcap can be implemented like for
rpath [#2])

This problem, is in most cases about this issue is the way that libtool
or pkg-config is used in the build systems.

For example, "pacman" package the pacman binary really only depends on
libc.so.6 and libalpm.so.3 all other libs (libdownload.so
libarchive.so.2 libacl.so.1 libattr.so.1 libbz2.so.1.0 libz.so.1) are
depends of libalpm.so.3 only.

Other example are "convert" from imagemagick: It has many unused direct
libraries:

$ ldd -u -r /usr/bin/convert
Unused direct dependencies:

        /usr/lib/liblcms.so.1
        /usr/lib/libtiff.so.3
        /usr/lib/libfreetype.so.6
        /usr/lib/libjasper.so.1
        /usr/lib/libjpeg.so.62
        /usr/lib/libgs.so.8
        /usr/lib/libpng12.so.0
        /usr/lib/libfontconfig.so.1
        /usr/lib/libwmflite-0.2.so.7
        /usr/lib/libXext.so.6
        /usr/lib/libXt.so.6
        /lib/libbz2.so.1.0
        /usr/lib/libIlmImf.so.6
        /usr/lib/libImath.so.6
        /usr/lib/libHalf.so.6
        /usr/lib/libIex.so.6
        /usr/lib/libIlmThread.so.6
        /usr/lib/librsvg-2.so.2
        /usr/lib/libgdk_pixbuf-2.0.so.0
        /usr/lib/libcairo.so.2
        /usr/lib/libgobject-2.0.so.0
        /usr/lib/libgmodule-2.0.so.0
        /usr/lib/libglib-2.0.so.0
        /usr/lib/libxml2.so.2
        /usr/lib/libz.so.1
        /usr/lib/libgomp.so.1
        /lib/libpthread.so.0
        /usr/lib/libltdl.so.7
        /usr/lib/libSM.so.6
        /usr/lib/libICE.so.6
        /usr/lib/libX11.so.6

This not only affect executables, also libraries. So very complicated
dependency "graphs" are here.

Derived from this, another issue appears:  undefined symbols, because in
shared libs this behavior are permited (ldd -u -r
/usr/lib/libgdbm_compat.so.3.0.0, but this is a documented [a program
that uses it also needs a -lgdbm] )

For example now the KDE packages (from Pierre) [#3] when solved all
RPATH also solved this issue, with linking flags "--as-needed" and
"--no-undefined"

Good Luck!


[#1] http://bugs.archlinux.org/task/13890 - Packaging creation and rpath
issues
[#2] http://bugs.archlinux.org/task/14049 - [namcap] should check about
insecure RPATH in ELF files
[#3] http://bugs.archlinux.org/task/13965 - [kde] Compile KDE with
CMAKE_SKIP_RPATH


-- 

Gerardo Exequiel Pozzi ( djgera )
http://www.djgera.com.ar
KeyID: 0x1B8C330D
Key fingerprint = 0CAA D5D4 CD85 4434 A219  76ED 39AB 221B 1B8C 330D