Gentoo Archives: gentoo-dev

From: Javier Villavicencio <the_paya@g.o>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Mozilla, pthread libs, and Gentoo/FreeBSD.
Date: Wed, 07 Mar 2007 11:51:30
1 Hello,
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].
10 The next issue (having the above one fixed) is that the resulting binary
11 (firefox or seamonkey's -bin) is linked against *and*
12 (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 to 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).
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 to be linked to the
25 final binary.
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.
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.
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.
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.
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).
66 Another possibility: upstream forgot about nspr and that one should be
67 linked to (or just specify in the --libs output) 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?
72 [1]
73 [2]
74 [3]
75 [4]
76 [5]
78 --
79 Javier.
80 --
81 gentoo-dev@g.o mailing list


Subject Author
Re: [gentoo-dev] Mozilla, pthread libs, and Gentoo/FreeBSD. Timothy Redaelli <drizzt@g.o>