| 1 |
Hello, |
| 2 |
|
| 3 |
A bit of background first: |
| 4 |
Currently firefox-2* and seamonkey-1.1.1 doesn't build on |
| 5 |
Gentoo/FreeBSD. The main reason is that upstream (I think) has 'fixed' |
| 6 |
how the pthread lib has to be linked, and now it needs -lc to link |
| 7 |
successfully. This little issue is easily solvable the same way as it's |
| 8 |
done by the FreeBSD ports patches [1]. |
| 9 |
|
| 10 |
The next issue (having the above one fixed) is that the resulting binary |
| 11 |
(firefox or seamonkey's -bin) is linked against libc_r.so.6 *and* |
| 12 |
libpthread.so.2 (which are two of the thread implementations available |
| 13 |
in FreeBSD). Bah, the two libs linked isn't *exactly* the issue, as they |
| 14 |
have all weak symbols this shouldn't be a problem, the exact issue |
| 15 |
without mapping libpthread.so.2 to libc_r.so.6 by using libmap.conf[2] |
| 16 |
is pretty different [3], and that's why I think upstream started using |
| 17 |
libc_r instead of libpthread for FreeBSD (as in, this happens also when |
| 18 |
firefox is only linked to libpthread using either -pthread or -lpthread). |
| 19 |
|
| 20 |
While looking for a possible *correct* solution for this, I found that |
| 21 |
the reason was that the mozilla (firefox/seamonkey) -bin is linked with |
| 22 |
the arguments: "-lc_r -pthread" which causes both libraries (libc_r and |
| 23 |
libphtread) to be linked to the resulting binary. Here we (and i bet |
| 24 |
upstream wanted this too) only want libc_r.so.6 to be linked to the |
| 25 |
final binary. |
| 26 |
|
| 27 |
The origin of the "-pthread" addition to that commandline is NSPR_LIBS |
| 28 |
which is filled by dev-libs/nspr "nspr-config --libs" output, which is |
| 29 |
generated by nspr using the LDFLAGS make var. |
| 30 |
|
| 31 |
This has an easy (yet incorrect imho) fix actually: |
| 32 |
The easiest way to fix this would be to remove NSPR_LIBS from the |
| 33 |
linkage of firefox/seamonkey-bin, which isn't even needed actually, as |
| 34 |
the OS LDFLAGS (LIBS actually, naming the variables) are already handled |
| 35 |
by Makefiles automagic, and this binary doesn't really 'need' the nspr |
| 36 |
libraries at all, someone may think about a missing -lpthread or -lnspr4 |
| 37 |
on Linux, I have tested it without linking against NSPR_LIBS and firefox |
| 38 |
starts perfectly fine, those who have --as-needed in their LDFLAGS, may |
| 39 |
check which libraries is firefox-bin linked against and I'm sure they'll |
| 40 |
see a quite reduced number of libraries than me. |
| 41 |
|
| 42 |
Now the questions: |
| 43 |
This makes me wonder if NSPR_LIBS is actually correct in this regard |
| 44 |
(and, perhaps, a fix for nspr is needed and not mozilla?), since, afaik |
| 45 |
on FreeBSD, the *decision* of which threading implementation has to be |
| 46 |
used resides in the final executable, not in their libraries. These |
| 47 |
guys [4] learned it the hard way, and they left nice references to good |
| 48 |
information. |
| 49 |
|
| 50 |
But this can also be just unintended overhead (or some sort of |
| 51 |
preloading stuff?) to the firefox/seamonkey-bin binary? As it works |
| 52 |
perfectly fine without having NSPR_LIBS in the commandline during the |
| 53 |
linkage (even on Linux, again), being the "easy fix" actually correct also. |
| 54 |
|
| 55 |
Or (I'm going all crazy here) it's something weird in the toolchain that |
| 56 |
might be wrong? As far as I can see, and using [5] as a testcase, |
| 57 |
vanilla FreeBSD does exactly the same thing (as we currently do) when |
| 58 |
compiling a program using both -lc_r and -pthread (or '-lthr |
| 59 |
-pthread/-lc_r -lthr'), always both libraries get linked. It also does |
| 60 |
follow the order, as in if -lc_r or -lthr is used with -pthread, the |
| 61 |
specified library (libc_r or libthr) it's the first in the list of |
| 62 |
linked libs in the final binary (and also seems to be the only one used, |
| 63 |
running that testcase on gdb shows that it dies on the function called |
| 64 |
from the first library linked). |
| 65 |
|
| 66 |
Another possibility: upstream forgot about nspr and that one should be |
| 67 |
linked to (or just specify in the --libs output) libc_r.so as well? (I |
| 68 |
haven't tested that yet) |
| 69 |
Or maybe something else? Overall, how do you feel this problem should be |
| 70 |
fixed/approached? |
| 71 |
|
| 72 |
[1]http://www.freebsd.org/cgi/cvsweb.cgi/ports/www/firefox/files/patch-config-rules.mk |
| 73 |
[2]http://www.freebsd.org/cgi/man.cgi?query=libmap.conf |
| 74 |
[3]http://rafb.net/p/O6xRqU15.html |
| 75 |
[4]https://forge.continuent.org/jira/browse/CAROB-117 |
| 76 |
[5]http://autoconf-archive.cryp.to/acx_pthread.html |
| 77 |
|
| 78 |
-- |
| 79 |
Javier. |
| 80 |
-- |
| 81 |
gentoo-dev@g.o mailing list |
Archives