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

Again, I'm surprised there hasn't been more feedback on this subject.

Is no one else distributing libjs.a or libjs.so for Linux?

-Rob

"Rob Swindell" <jseng@synchro.net> wrote in message
news:bf2fr0$eb31@ripley.netscape.com...
> 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
> >
> >
>
>

.