[arch-general] What about unused direct libraries in ELF files?
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
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
participants (2)
-
Allan McRae
-
Gerardo Exequiel Pozzi