client.mk HEAD versus FIREFOX_1_0_1

[Matthew Daniel]

Hi, you guys may remember me as the chap that couldn't get HEAD to build
on x86_64. I downloaded firefox-1.0.1-source.tar.bz2 and using the same
.mozconfig as I use on HEAD, it built (and runs) great.

Now, according to the magic instructions, I unpack that same firefox
source, issue 'cvs up -A client.mk' and then ask it to checkout its
friends. Once the 'checkout' target starts, it blows away all my firefox
code that links so well and overwrites it with code that does not link.

One issue is that it seems nsprpub and js code down in the FIREFOX_*
branches are not even remotely similar to those in
NSPRPUB_PRE_4_2_CLIENT_BRANCH (which is what the HEAD version of
client.mk downloads).

Is there some unwritten rule that says "don't build from HEAD"? I would
very much like to follow the progress of firefox as My Favorite Bug(tm)
gets fixed or possibly even contribute to its progress.

Thank you,
-- /v\atthew

[Christian Biesinger]

Matthew Daniel wrote:
> Is there some unwritten rule that says "don't build from HEAD"?

HEAD is very much supposed to work, and that it does is tracked at
http://tinderbox.mozilla.org/SeaMonkey/. I don't know if we have any
tinderbox for x86 64-bit builds, though.. but that's supposed to work as
well.

oh... now that I look at your original posting again:
>/usr/bin/ld: io/./priometh.o: relocation R_X86_64_PC32 against
>> `memcpy@@GLIBC_2.2.5' can not be used when making a shared object;
>> recompile with -fPIC
>> /usr/bin/ld: final link failed: Bad value

Someone else saw that too. I think shaver claimed it was a binutils bug.

[Matthew Daniel]

> HEAD is very much supposed to work, and that it does is tracked at
> http://tinderbox.mozilla.org/SeaMonkey/. I don't know if we have any
> tinderbox for x86 64-bit builds, though.. but that's supposed to work as

I didn't see it when I last checked, and I checked again before posting
and it is not. I figured that I was on my own since mozilla.org doesn't
offer a binary release (or nightly) on amd64/x86_64.

You are partially right, though, as the source releases _do_ build on
x86_64 (I'm running it right now). It's just something about the
particular tag of nsprpub and js that don't agree with my system.

I am posting because I am not experienced enough with the build process
to be able to swap in my own js. When I build nsprpub and give
--with-system-nspr in .mozconfig, that part seems to work fine but
that's cheating. ;-)

I am convinced there is some implied tag knowledge that I, as an
outsider, have not yet learned.

> Someone else saw that too. I think shaver claimed it was a binutils bug.

Did shaver open a bug with them? I didn't see anything in their
bugzilla.

I tried HEAD binutils last night with the same net effect. I have a post
in to their mailing list (and gcc-help, too, but I think that may have
been the wrong place) to see if we can track it down.

In the meantime, is there a way that I can force the build process to
use my working system libjs?

Thanks for your help,
-- /v\atthew

[Matthew Daniel]

> >/usr/bin/ld: io/./priometh.o: relocation R_X86_64_PC32 against
> >> `memcpy@@GLIBC_2.2.5' can not be used when making a shared object;
> >> recompile with -fPIC
> >> /usr/bin/ld: final link failed: Bad value
>
> Someone else saw that too. I think shaver claimed it was a binutils bug.

After working with the enormously helpful folks on the binutils list, it
is in fact a gcc bug, but not with the linker as you might expect.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20297

If you patch the $(topsrc)/configure to stop checking for the pragma
directive, then patch nsprpub's gcc_hidden.h (found below), it builds
great.

The top configure needs to be patched to make libmozjs build and
gcc_hidden seems to alter the fate of nsprpub.

I hope this information shows up in Google and helps someone else.

-- /v\atthew

diff -u -r1.1395 configure
--- configure 2 Mar 2005 16:57:17 -0000 1.1395
+++ configure 3 Mar 2005 17:50:31 -0000
@@ -7042,7 +7042,7 @@

fi

-if test "$GNU_CC"; then
+if /bin/false; then
echo $ac_n "checking for visibility(hidden) attribute""... $ac_c" 1>&6
echo "configure:7048: checking for visibility(hidden) attribute" >&5
if eval "test \"`echo '$''{'ac_cv_visibility_hidden'+set}'`\" = set"; then

diff -u -r1.1.2.1 gcc_hidden.h
--- nsprpub/config/gcc_hidden.h 15 Dec 2004 05:52:39 -0000 1.1.2.1
+++ nsprpub/config/gcc_hidden.h 3 Mar 2005 17:51:06 -0000
@@ -1,2 +1,3 @@
-/* Begin all files as hidden visibility */
+/* Begin all files as hidden visibility
#pragma GCC visibility push(hidden)
+*/

[Christian Biesinger]

Matthew Daniel wrote:
> After working with the enormously helpful folks on the binutils list, it
> is in fact a gcc bug, but not with the linker as you might expect.

(If it were a linker bug, it wouldn't be a GCC bug. it would be a
binutils bug)

Seems the bug is triggered by unbalanced visibility push/pop; I wonder
why mozilla doesn't just use -fvisibility=hidden?

[Brian Ryner]

It's not quite the same thing. -fvisibility=hidden affects only call
sites in the same translation unit as the function definition. To get
optimal code generation at all of the call sites, we have to make sure
the compiler knows that _all_ function declarations are for hidden
functions unless explicitly marked otherwise.

--
-Brian Ryner
bry...@brianryner.com

[Mike Shaver]

It's a something bug, that's for sure. I worked around it, selfishly,
by disabling the hidden-visibility optimization for my local builds.

You want to make change the configure.in test for GNU_CC (search for
"visibility" in configure.in, it's early if not the first hit) to
something that will be false. I just added _NO_THANK_YOU to the end of
the GNU_CC variable that was tested. Then you need to run autoconf-2.13
(important! other versions of autoconf may cause staining or tearing)
and rebuild.

Mike
(hoping this ends up in the newsgroup)