220854 - libjs.so needs to be linked with gcc (instead of ld) to be version symboled

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Rob Swindell]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
Build Identifier: 

The following line in mozilla/js/src/config/Linux_All.mk:
MKSHLIB = $(LD) -shared $(XMKSHLIBOPTS)

needs to be changed to: 
MKSHLIB = $(CC) -shared $(XMKSHLIBOPTS)

This change builds libjs.so using versioned symbols, which allows the binary to 
be linked on systems with different versions of glibc than the version it was 
originally linked with.

Without this change, building libjs.so on a system with glibc 2.3.2-11 or later 
will reference a symbol '__ctype_b_loc' which doesn't exist in glibc-2.3.2-5 
and earlier. So trying to link with this binary on a system using an older 
glibc will result in the error: undefined reference: '__ctype_b_loc'.

Similarly, if libjs.so is built using LD (instead of GCC) on a system with an 
older glibc and linked on a system with a newer glibc, it will fail with the 
errror: undefined reference: '__ctype_b'.

I mentioned this problem and the solution on the netscape.public.mozilla.jseng 
newsgroup in July, but there was very little response, and apparently no action 
was taken since this problem still exists in the current CVS revision of 
config/Linux_All.mk.

Reproducible: Always

Steps to Reproduce:
1. Build libjs.so on a system using glibc 2.3.2-11 or later (with no special 
distro-specific compatibility patches) - (e.g. up2date Redhat Linux 9).
2. Attempt to link on a system using glibc 2.3.2-5 or earlier (e.g. Redhat 
Linux 8 or earlier).
3. Witness linker error: undefined reference: '__ctype_b_loc'

Actual Results:  
The link fails.

Expected Results:  
The link should success, regardless of Linux distro/version.

This change to to the ctype_b version definition is just an example of the 
problem (not using version symbols). Linking with ld on Linux does not include 
version symbols, you must link with gcc instead.

For more details:

http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=91290

Comment 1

[Rob Swindell]

After additional testing/verification, I've found that this change allows for 
FORWARD compatibility, but not BACKWARD compatibilty.

i.e. A libjs.so linked with GCC on a system using an older glibc can be used 
(linked) on systems with newer glibc versions, but the reverse is not true.

Shared libraries linked with the newer versions of glibc (GLIBC_2.3) with LD or 
GCC using symboled versions or not, are not backwards compatible with systems 
using older versions of glibc.

This change is still needed for proper symbol versioning to allow for proper 
FORWARD symbol compatibility.

-Rob

Comment 2

[Phil Schwartau]

Formally confirming for consideration; cc'ing Mike, Rob -

Comment 3

[tenthumbs]

Linking without gcc means not including the magic initialization and 
termination objects. There's one of each from libc and the compiler. It 
doesn't surprise me at all that things may malfunction without the 
proper support.

Comment 4

[Rob Swindell]

According to RedHat:
It never has been nor will it ever be allowed to link anything
(program or executable) with ld directly.  The gcc driver must always
be used.  Any DSO which is not linked this way is broken anyway.  It
uses the interfaces from the headers but doesn't used versioned
symbols.  This cannot work.

See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=90515 for complete 
details.

-Rob

Comment 5

[Jason Orendorff [:jorendorff]]

Fixed by the new build system, bug 97954.