Subj : Re: libjs.a Linux compatiblity
To   : netscape.public.mozilla.jseng
From : "Rob Swindell" <jseng@synchro.net>
Date : Tue Jul 15 2003 09:20 pm

Well here's the current solution for cross-version library compatibility on
RedHat Linux:

You must use libjs.so instead of libjs.a.

And in order for the symbol-versioning to work correctly, you must use gcc
instead of ld to build libjs.so
(as is increasingly the case with Linux, you shouldn't use ld for much of
anything). To use gcc, you must
change the MKSHLIB definition in config/Linux_All.mk to the following:

    MKSHLIB = $(CC) -shared $(XMKSHLIBOPTS)

Of course, if XMKSHLIBOPTS ever contains real linker options, this "fix"
won't work.

Is anyone interested in making this change to the official Linux_All.mk file
(in CVS)?

I'm surprised there hasn't been more discussion or feedback on this topic.
<shrug>

-Rob

"Rob Swindell" <rob@synchro.net> wrote in message
news:bhtOa.123$rQ2.25908520@newssvr13.news.prodigy.com...
> I have a large open source project (http://synchro.net), and distribute
the
> source code along with pre-built libraries for JavaScript and NSPR for the
> various supported Unixes (Linux, FreeBSD, OpenBSD, NetBSD, and QNX) as
well
> as DLLs for a Win32 build. This saves a lot of time and hassle for the
users
> of my project (I don't release any pre-built executable binaries for Unix
at
> this time).
>
> Shortly after the appearance of RedHat Linux 9 I started getting reports
of
> linking errors with the libjs.a and libnspr4.a (undefined reference:
> '__ctype_b'). Apparently an install from the boxed RH9 CDs installs
> glibc-2.3.2-5 which will link fine, but a downloaded install or an updated
> install (with "up2date") uses glibc-2.3.2-11 or 2.3.2-27 which does not
> include this symbol and the link fails.
>
> Likewise, libraries built using this newer glibc don't link on older
systems
> (undefined reference: '__ctype_b_loc').
>
> There are plenty of discussions on this subject on the web and lots of
> work-arounds (including patching glibc or using older revisions), but I'm
> interested in a permanent solution, not a temporary work-around.
>
> Both RedHat and the GNU guys claim this is not a bug, even though these
> libraries link with every other Linux distro and version released in the
> past 3 years. The response from GNU was:
> "Compatibility does not extend to object files, only programs and DSOs.
> Recompile your code."
>
> If by "DSO", he means a shared object (libjs.so) file, I've tried that too
> with no success. I've asked for clarification with no response.
>
> The response for RedHat was:
> "On RHL9 this is not a bug. There is no binary compatibility for .a
> libraries
> or .o files between distribution major releases (glibc only ensures
> binary compatibility for programs and shared libraries using symbol
> versioning,
> for static libraries this cannot work)."Does the libjs.so file built with
> Makefile.ref use "symbol versioning"? If not, how is this done?
>
> I realize this isn't a Spidermonkey-specific problem, but I've just about
> run out of ideas and resources on solving this ridiculous incompatibility
> and have been frustrated with the responses I've received from RedHat and
> GNU.
>
> Many thanks for any helpful input,
>
> -Rob
>
>

.