Timothy Redaelli wrote:
Javier Villavicencio wrote:
Hello,
A bit of background first:
Currently firefox-2* and seamonkey-1.1.1 doesn't build on
Gentoo/FreeBSD. The main reason is that upstream (I think) has 'fixed'
how the pthread lib has to be linked, and now it needs -lc to link
successfully. This little issue is easily solvable the same way as it's
done by the FreeBSD ports patches [1].
The next issue (having the above one fixed) is that the resulting binary
(firefox or seamonkey's -bin) is linked against libc_r.so.6 *and*
libpthread.so.2 (which are two of the thread implementations available
in FreeBSD).
No, actual firefox-bin is only linked with libpthread.so.2 (directly
with -lpthread)
# wget
ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-6-stable/Latest/firefox.tbz
# mkdir firefox ; tar xjf firefox.tbz -C firefox
# scanelf -nR . | grep c_r
Nice to know, by the way i was talking about g/fbsd there not vanilla
freebsd. (I don't have an install yet, i was using a friend's server to
try some gcc tests).
BUT!!, why 'our' mozilla tries to link against libc_r.so.6 then? afaics
we do not touch the 'selection' of the threading library, and i haven't
seen anything besides the GECKO_PTHREADS_LIBS, and even if I pass that
variable (with -lpthread) to make our build still uses libc_r.so.6.
And why the only way to make it work is by remapping libpthread.so.2 to
libc_r.so.6, or (as I have experimented) by removing libpthread.so.2
from the linkage? Or is this also being done in some wrapper on vanilla
fbsd?
Besides this, what's your suggestion? make all mozilla ebuilds patch
accordingly to avoid libc_r and use libpthread alone?
--
gentoo-dev@gentoo.org mailing list
