221087 - Build w/ PIC and use the compiler to link

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[timeless]

timeless@predator:~/mozilla/js/src/config$ gcc -v
Reading specs from 
/home/timeless/lib/gcc-lib/alphaev56-unknown-linux-gnu/3.2.3/specs
Configured with: ./configure --prefix=/home/timeless/ : 
(reconfigured) ./configure --prefix=/home/timeless 
--enable-languages=c : (reconfigured) ./configure 
--prefix=/home/timeless --enable-languages=c,c++ Thread model: posix
gcc version 3.2.3

gcc -o Linux_All_DBG.OBJ/jsarray.o -c -Wall -Wno-format -g -DXP_UNIX 
-DSVR4 -DSYSV -D_BSD_SOURCE -DPOSIX_SOURCE -DHAVE_LOCALTIME_R -mieee  
-DDEBUG -DDEBUG_timeless -DEDITLINE -ILinux_All_DBG.OBJ  jsarray.c
...
ld -shared  -o Linux_All_DBG.OBJ/libjs.so ...
ld: Linux_All_DBG.OBJ/jsarray.o: gp-relative relocation against 
dynamic symbol js_ArrayClass (appears a bunch of times)
GNU ld version 2.12.90.0.1 20020307 Debian/GNU Linux

google hit indicates:
>  "gp-relative relocation" means something needs to be compiled
>  with -fPIC (probably kwave's libmad in this case).  Remove and
>  re-extract the source tree, export LDFLAGS="-fPIC", and try the
>  build again.

I changed Linux_All.mk per cls and rebuilt, it worked and ran.
It also worked a lot better than the gcc294 build which can't handle 
numbers.

Comment 1

[timeless]

Attachment: proposed changes for Makefile.ref

Comment 2

[Brendan Eich [:brendan]]

Do all Linuxen have to take the PIC/shared-lib hit?  This is just for the js
shell, true, but lots of embedders imitate it.  Shared libraries cost, and they
shouldn't be used mindlessly.  Is it truly the case that those gp errors can be
avoided only by going to a shared lib?

And how, exactly, except by causing bulkier and different PIC code generation,
does this work around the other Alpha bug 220732?  Have you disassembled and
compared to see what became of the bad addl/cmple pair?

/be

Comment 3

[timeless]

if you follow the links from bug 220732 comment 13 you'll see that
the bug over there is really mostly a duplicate of a bug which andrew
passed to the gcc people who eventually fixed it.

i don't know much about various flavors of gcc but my guess is that
the need for pic is gcc3 related, possibly limited by platform.
(i can check solaris-sparc,solarix-x86,linux-x86 at some point if
people really care.) but Makefile.ref isn't configure/autoconf'd so i 
don't think it could actually detect the difference between a gcc 
that needs it and a gcc that doesn't.

Comment 4

[tenthumbs]

Brendan, if you don't do PIC then there will be relocations in read-only
segments on probably all versions of Linux. The dynamic linker jumps
through hoops to work around this. There's a penalty either way.

BTW, I see Makefile.ref calls ld directly. I'm not sure this is always 
guaranteed to work. Is there a bug on this?

Comment 5

[Brendan Eich [:brendan]]

tenthumbs: there's a penalty either way on Linux with a purely static build? Why
does the dynamic linker come into play there at all?  Or am I a dinosaur from
the 80s in thinking that a purely static build is even possible?

Bug 220854 is the one on linking with gcc, not ld.

/be

Comment 6

[tenthumbs]

Brendan, comment #0 mentions "ld -shared" so I assumed that was the 
issue here, not the static linking of js. Sorry for the confusion.

I'm more of a dinosaur than you are. I'm coming to the position that 
shared libs are a mistake.

Comment 7

[falk]

This file is now built with -fPIC on Alpha Linux, as requested. I recommend
this bug to be closed.

Comment 8

[timeless]

[e-mail]: um, i don't see any changes in the file which would cause it to
work, how often do you build spidermonkey standalone? can you please indicate
what change would have fixed this?

Comment 9

[falk]

(In reply to comment #8)
> [e-mail]: um, i don't see any changes in the file which would cause it to
> work, how often do you build spidermonkey standalone? can you please indicate
> what change would have fixed this?

Actually, I didn't build it standalone, but as part of the mozilla tree. I tried
some recent CVS versions. Unfortunately, I don't have te logs any more, but they
built fine and I think this file was built with -fPIC.

Comment 10

[timeless]

right, which is entirely irrelevant. the seamonkey/firefox codepath uses a
distinct set of makefiles.

Comment 11

[Blake Kaplan (:mrbkap) (inactive)]

Do we still care about this? For what it's worth, from the gcc man page on OS X:

           -fPIC is the default on Darwin and Mac OS X.

So perhaps we should just take this to be consistent across all *nix.

Comment 12

[Blake Kaplan (:mrbkap) (inactive)]

Comment on attachment 132558 [details] [diff] [review]
proposed changes for Makefile.ref

Clearing this request. We have a shiny new build system now that should do the right thing with PIC and the linker.