Firefox and shlib analysis

[infracaninophile]

Reported by Walter Hurry:

On 12/12/2012 23:17, Walter Hurry wrote:

That looks like a useful feature. But why is it saying this?

pkg: (firefox-17.0.1,1) shared library libxpcom.so not found
pkg: (firefox-17.0.1,1) shared library libmozalloc.so not found
(lots more output snipped)

$ locate libxpcom.so
/usr/local/lib/firefox/libxpcom.so
$ locate libmozalloc.so
/usr/local/lib/firefox/libmozalloc.so
$ file /usr/local/lib/firefox/libxpcom.so
/usr/local/lib/firefox/libxpcom.so: ELF 64-bit LSB shared object, x86-64,
version 1 (FreeBSD), dynamically linked, stripped
$ file /usr/local/lib/firefox/libmozalloc.so
/usr/local/lib/firefox/libmozalloc.so: ELF 64-bit LSB shared object,
x86-64, version 1 (FreeBSD), dynamically linked, stripped
$

Ah -- that would be a bug. At a guess, it's not finding the shlibs
because they're in a location not on the usual path and there's
something odd about the RPATH settings in the binaries. I shall
investigate further.

[infracaninophile]

Scott Hetzel:

This same issue with firefox was reported in this PR:

http://www.freebsd.org/cgi/query-pr.cgi?pr=131237

And included a simple fix which was rejected by the firefox maintainer
due to firefox sets LD_LIBRARY_PATH at runtime to find its share
libraries.

[infracaninophile]

Unfortunately it seems to be a fairly common effect in some large projects. Other packages showing the same symptoms:

thunderbird (yeah -- that one was predictable...)
openjdk6
virtualbox-ose

... and that's just out of what's installed on my desktop: by no means comprehensive. As far as I can tell from a quick check, openjdk6 doesn't rely on setting LD_LIBRARY_PATH in the environment.

[bapt]

this is a firefox problem not our it should use -Wl,-R,'$ORIGIN/.. as a ldflag at build time. see https://bugzilla.mozilla.org/show_bug.cgi?id=259945

[infracaninophile]

On 13/12/2012 08:41, Baptiste Daroussin wrote:

this is a firefox problem not our it should use -Wl,-R,'$ORIGIN/.. as
a ldflag at build time. see
https://bugzilla.mozilla.org/show_bug.cgi?id=259945

Hmmm.... lots of discussion about Solaris there. Is there an official
policy about these sorts of thing in FreeBSD?

Also I need to look into the other examples which seem to be seeing a
similar effect for a different reason.

[bapt]

No need a policy, what is important is that LD_LIBRARY_PATH tweaks are tweaks and can lead to failures where -Wl,-R,'$ORIGIN is clean that is what is used in libreoffice

[infracaninophile]

On 15/12/2012 14:16, ajtiM wrote:

My system: FreeBSD 9.1-RC3 #0 r242324: Tue Oct 30 00:18:27 UTC 2012
root@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386

I installed new pkg, I have WITH_PKGNG=yes in /etc/make.conf, I ran pkg2ng and
I use portmaster. I turned ON SHLIBS=YES in pkg.conf and pkg_check -Ba show:

pkg check -Ba
pkg: (fltk-1.3.2) shared library libfltk_images.so.1.3 not found
pkg: (fltk-1.3.2) shared library libfltk_forms.so.1.3 not found
pkg: (fltk-1.3.2) shared library libfltk.so.1.3 not found
pkg: (fltk-1.3.2) shared library libfltk.so.1.3 not found
[... repetetive stuff elided ...]
allocate memory
pkg: elf_begin() for /usr/local/man/man1/jackstart.1.gz failed: I/O error:
Cannot allocate memory
pkg: Cannot mmap "/var/run/ld-elf.so.hints": Cannot allocate memory

I rebuilt hugin, fltk and jack and ran again but I got the same.

Thank you for the report. I'll add it to issue #403 at the pkgng github
(#403) so it doesn't get forgotten.

I'm slowly collecting examples of applications where the shlib analysis
doesn't work properly so I can debug them. Sometimes it seems to be due
to ports needing LD_LIBRARY_PATH set in the environment, which we can't
do much about, but there are other cases which seemingly have a
different etiology.

Cheers,

Matthew

Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey

[infracaninophile]

On 15/12/2012 18:23, Walter Hurry wrote:

On Sat, 15 Dec 2012 15:31:03 +0000, Matthew Seaman wrote:

'm slowly collecting examples of applications where the shlib analysis
doesn't work properly

In case you don't already have them in your list:
opnjdk7
libreoffice

Thanks. Added to the list. It always has to be the really big projects
(and tedious to debug because of that) doesn't it.

Cheers,

Matthew 

Dr Matthew J Seaman MA, D.Phil.

PGP: http://www.infracaninophile.co.uk/pgpkey
JID: matthew@infracaninophile.co.uk

[infracaninophile]

Here's a special case that needs to be handled properly:

worm:...matthew/src/pkgng:# objdump -x /usr/local/lib/firefox/plugin-container | grep RPATH
  RPATH       $ORIGIN

$ORIGIN = installation directory of that shlib / elf binary

[infracaninophile]

For the case of firefox, shlib analysis is working just fine now:

worm:...src/pkgng/tests:# pkg check -vB firefox
Reanalyzing files for shlibs: firefox
worm:...src/pkgng/tests:# pkg info -Bb firefox
firefox-20.0,1
Shared Libs required:
    libxul.so
    libxpcom.so
    libvpx.so.1
    libv4l2.so.0
    libstartup-notification-1.so.0
    libssl3.so.1
    libsqlite3.so.8
    libsmime3.so.1
    libpng15.so.15
    libplds4.so.1
    libplc4.so.1
    libpixman-1.so.9
    libpangoft2-1.0.so.0
    libpangocairo-1.0.so.0
    libpango-1.0.so.0
    libnssutil3.so.1
    libnss3.so.1
    libnspr4.so.1
    libmozalloc.so
    libjpeg.so.11
    libiconv.so.3
    libhunspell-1.3.so.0
    libgtk-x11-2.0.so.0
    libgthread-2.0.so.0
    libgobject-2.0.so.0
    libglib-2.0.so.0
    libgio-2.0.so.0
    libgdk_pixbuf-2.0.so.0
    libgdk-x11-2.0.so.0
    libfreetype.so.9
    libfontconfig.so.1
    libffi.so.6
    libevent-2.0.so.6
    libdbus-glib-1.so.2
    libdbus-1.so.3
    libcairo.so.2
    libatk-1.0.so.0
    libasound.so.2
    libXt.so.6
    libXrender.so.1
    libXrandr.so.2
    libXinerama.so.1
    libXi.so.6
    libXfixes.so.3
    libXext.so.6
    libXdamage.so.1
    libXcursor.so.1
    libXcomposite.so.1
    libX11.so.6
Shared Libs provided:
    libxul.so
    libxpcom.so
    libmozgnome.so
    libmozalloc.so
    libdbusservice.so
    libbrowsercomps.so
worm:...src/pkgng/tests:#