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). Bah, the two libs linked isn't *exactly* the issue, as they
have all weak symbols this shouldn't be a problem, the exact issue
without mapping libpthread.so.2 to libc_r.so.6 by using libmap.conf[2]
is pretty different [3], and that's why I think upstream started using
libc_r instead of libpthread for FreeBSD (as in, this happens also when
firefox is only linked to libpthread using either -pthread or -lpthread).
While looking for a possible *correct* solution for this, I found that
the reason was that the mozilla (firefox/seamonkey) -bin is linked with
the arguments: "-lc_r -pthread" which causes both libraries (libc_r and
libphtread) to be linked to the resulting binary. Here we (and i bet
upstream wanted this too) only want libc_r.so.6 to be linked to the
final binary.
The origin of the "-pthread" addition to that commandline is NSPR_LIBS
which is filled by dev-libs/nspr "nspr-config --libs" output, which is
generated by nspr using the LDFLAGS make var.
This has an easy (yet incorrect imho) fix actually:
The easiest way to fix this would be to remove NSPR_LIBS from the
linkage of firefox/seamonkey-bin, which isn't even needed actually, as
the OS LDFLAGS (LIBS actually, naming the variables) are already handled
by Makefiles automagic, and this binary doesn't really 'need' the nspr
libraries at all, someone may think about a missing -lpthread or -lnspr4
on Linux, I have tested it without linking against NSPR_LIBS and firefox
starts perfectly fine, those who have --as-needed in their LDFLAGS, may
check which libraries is firefox-bin linked against and I'm sure they'll
see a quite reduced number of libraries than me.
Now the questions:
This makes me wonder if NSPR_LIBS is actually correct in this regard
(and, perhaps, a fix for nspr is needed and not mozilla?), since, afaik
on FreeBSD, the *decision* of which threading implementation has to be
used resides in the final executable, not in their libraries. These
guys [4] learned it the hard way, and they left nice references to good
information.
But this can also be just unintended overhead (or some sort of
preloading stuff?) to the firefox/seamonkey-bin binary? As it works
perfectly fine without having NSPR_LIBS in the commandline during the
linkage (even on Linux, again), being the "easy fix" actually correct also.
Or (I'm going all crazy here) it's something weird in the toolchain that
might be wrong? As far as I can see, and using [5] as a testcase,
vanilla FreeBSD does exactly the same thing (as we currently do) when
compiling a program using both -lc_r and -pthread (or '-lthr
-pthread/-lc_r -lthr'), always both libraries get linked. It also does
follow the order, as in if -lc_r or -lthr is used with -pthread, the
specified library (libc_r or libthr) it's the first in the list of
linked libs in the final binary (and also seems to be the only one used,
running that testcase on gdb shows that it dies on the function called
from the first library linked).
Another possibility: upstream forgot about nspr and that one should be
linked to (or just specify in the --libs output) libc_r.so as well? (I
haven't tested that yet)
Or maybe something else? Overall, how do you feel this problem should be
fixed/approached?
[1]http://www.freebsd.org/cgi/cvsweb.cgi/ports/www/firefox/files/patch-config-rules.mk
[2]http://www.freebsd.org/cgi/man.cgi?query=libmap.conf
[3]http://rafb.net/p/O6xRqU15.html
[4]https://forge.continuent.org/jira/browse/CAROB-117
[5]http://autoconf-archive.cryp.to/acx_pthread.html
--
Javier.
--
gentoo-dev@gentoo.org mailing list
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). Bah, the two libs linked isn't *exactly* the issue, as they
have all weak symbols this shouldn't be a problem, the exact issue
without mapping libpthread.so.2 to libc_r.so.6 by using libmap.conf[2]
is pretty different [3], and that's why I think upstream started using
libc_r instead of libpthread for FreeBSD (as in, this happens also when
firefox is only linked to libpthread using either -pthread or -lpthread).
While looking for a possible *correct* solution for this, I found that
the reason was that the mozilla (firefox/seamonkey) -bin is linked with
the arguments: "-lc_r -pthread" which causes both libraries (libc_r and
libphtread) to be linked to the resulting binary. Here we (and i bet
upstream wanted this too) only want libc_r.so.6 to be linked to the
final binary.
The origin of the "-pthread" addition to that commandline is NSPR_LIBS
which is filled by dev-libs/nspr "nspr-config --libs" output, which is
generated by nspr using the LDFLAGS make var.
This has an easy (yet incorrect imho) fix actually:
The easiest way to fix this would be to remove NSPR_LIBS from the
linkage of firefox/seamonkey-bin, which isn't even needed actually, as
the OS LDFLAGS (LIBS actually, naming the variables) are already handled
by Makefiles automagic, and this binary doesn't really 'need' the nspr
libraries at all, someone may think about a missing -lpthread or -lnspr4
on Linux, I have tested it without linking against NSPR_LIBS and firefox
starts perfectly fine, those who have --as-needed in their LDFLAGS, may
check which libraries is firefox-bin linked against and I'm sure they'll
see a quite reduced number of libraries than me.
Now the questions:
This makes me wonder if NSPR_LIBS is actually correct in this regard
(and, perhaps, a fix for nspr is needed and not mozilla?), since, afaik
on FreeBSD, the *decision* of which threading implementation has to be
used resides in the final executable, not in their libraries. These
guys [4] learned it the hard way, and they left nice references to good
information.
But this can also be just unintended overhead (or some sort of
preloading stuff?) to the firefox/seamonkey-bin binary? As it works
perfectly fine without having NSPR_LIBS in the commandline during the
linkage (even on Linux, again), being the "easy fix" actually correct also.
Or (I'm going all crazy here) it's something weird in the toolchain that
might be wrong? As far as I can see, and using [5] as a testcase,
vanilla FreeBSD does exactly the same thing (as we currently do) when
compiling a program using both -lc_r and -pthread (or '-lthr
-pthread/-lc_r -lthr'), always both libraries get linked. It also does
follow the order, as in if -lc_r or -lthr is used with -pthread, the
specified library (libc_r or libthr) it's the first in the list of
linked libs in the final binary (and also seems to be the only one used,
running that testcase on gdb shows that it dies on the function called
from the first library linked).
Another possibility: upstream forgot about nspr and that one should be
linked to (or just specify in the --libs output) libc_r.so as well? (I
haven't tested that yet)
Or maybe something else? Overall, how do you feel this problem should be
fixed/approached?
[1]http://www.freebsd.org/cgi/cvsweb.cgi/ports/www/firefox/files/patch-config-rules.mk
[2]http://www.freebsd.org/cgi/man.cgi?query=libmap.conf
[3]http://rafb.net/p/O6xRqU15.html
[4]https://forge.continuent.org/jira/browse/CAROB-117
[5]http://autoconf-archive.cryp.to/acx_pthread.html
--
Javier.
--
gentoo-dev@gentoo.org mailing list
