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

[Allan McRae]

Gerardo Exequiel Pozzi wrote:
> 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
>   

Although I do like the idea of setting LDFLAGS="-Wl,--as-needed 
-Wl,--no-undefined" (and maybe even -Wl,-Bsymbolic-functions) as some 
sort of default (as pacman-3.3 will have support for LDFLAGS added to 
pacman), many things are still broken about this.  When gcc-4.4 is 
finally released, I may add this patch[1] to binutils which improves 
this a bit, but for a large number of packages these flags cause 
breakages. So implementing this would cause a large amount of work in 
the short term for what may be a minimal gain.

[1] 
http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/elflink.c.diff?r1=1.328&r2=1.329&cvsroot=src

Allan