dynamic library version crashes but static version works

dynamic library version crashes but static version works

[Ted Sung]

>
>
>Hi,
>
>I build a dynamic library with gcc 3.2 (glibc 2.3.2-4.80.8) running Red 
>Hat Linux 8.0 3.2-7).
>I copy this library over to another machine running Red Hat Enterprise 
>Linux ES release 3 (Taroon)
>2,  gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-20) , glibc-2.3.2-95.3 
>and rebuild my executable.
>
>My program crashes in a very strange place in my library code.  Linking to 
>the static version of my library
>works.
>
>Is this a known bug?  It seems it has to do with the dynamic loading of my 
>dynamic library but
>I'm not sure how to proceed to figure this out.
>
>Ted

Re: dynamic library version crashes but static version works

[James E Wilson]

Ted Sung wrote:
>> I build a dynamic library with gcc 3.2 (glibc 2.3.2-4.80.8) running 
>> Red Hat Linux 8.0 3.2-7).
>> I copy this library over to another machine running Red Hat Enterprise 
>> Linux ES release 3 (Taroon)
>> My program crashes in a very strange place in my library code.  

This is almost certainly not a gcc problem.  There probably isn't much 
we can do to help, without duplicating your situation, and it wouldn't 
be worthwhile for us to try.

In general, you shouldn't expect any portability of compiled libraries 
between two different linux systems.  RHL8 and RHES3 are rather 
different linux systems, even though they have similar gcc/glibc 
versions, and you should not expect compiled libraries to be portable 
between them.  Generally, statically linked code can be moved between 
similar linux systems though, as you have already found.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: dynamic library version crashes but static version works

[Ted Sung]

I have a few more questions regarding the compatibility of dynamic (and 
static libraries).

Does the compatibility of the libraries depend solely on the version of 
Linux?  For example,
will libraries be compatible if they are built on the same machine but with 
different versions of the GNU compiler ?

Aside from versions of Linux, what else (gcc version, glibc version, ld 
version etc.) determines whether a dynamic (and static)
library are compatible?

Why do the static libraries tend to work more frequently than the dynamic 
libraries?

As a provider of such libraries to clients, I'd like to try to minimize the 
# of machines and builds that need to be done.

Thanks for your help.

Ted


At 08:36 PM 01/19/2005, James E Wilson wrote:
>Ted Sung wrote:
>>>I build a dynamic library with gcc 3.2 (glibc 2.3.2-4.80.8) running Red 
>>>Hat Linux 8.0 3.2-7).
>>>I copy this library over to another machine running Red Hat Enterprise 
>>>Linux ES release 3 (Taroon)
>>>My program crashes in a very strange place in my library code.
>
>This is almost certainly not a gcc problem.  There probably isn't much we 
>can do to help, without duplicating your situation, and it wouldn't be 
>worthwhile for us to try.
>
>In general, you shouldn't expect any portability of compiled libraries 
>between two different linux systems.  RHL8 and RHES3 are rather different 
>linux systems, even though they have similar gcc/glibc versions, and you 
>should not expect compiled libraries to be portable between 
>them.  Generally, statically linked code can be moved between similar 
>linux systems though, as you have already found.
>--
>Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Ted Sung
Intex Solutions, Inc.
110 A Street Needham, MA 02494
tel (781)449-6222 fax (781)444-2318
teds@intex.com
www.intex.com

Re: dynamic library version crashes but static version works

[Nix]

On 20 Jan 2005, Ted Sung asked:
> I have a few more questions regarding the compatibility of dynamic
> (and static libraries).

(This is probably off-topic on the GCC list, but I'm not aware of a list
where it would be on-topic, really.)

> Does the compatibility of the libraries depend solely on the version
> of Linux?

Not exactly.

>            For example, will libraries be compatible if they are built
> on the same machine but with different versions of the GNU compiler ?

Not exactly.

> Aside from versions of Linux, what else (gcc version, glibc version,
> ld version etc.) determines whether a dynamic (and static) library are
> compatible?

The library and its caller have to agree on some things. The API (that
the library provides, and that the caller expects it to provide) has to
match, any shared data structures have to match, and the ABI has to
match.

The former, the library's direct API, is pretty much handled for you
on ELF shared library systems like Linux: a combination of SONAMEs
(roughly corresponding to shared library major version numbers) and
symbol versioning (which lets shared libraries expect several
symbols with the `same name' for old and new binaries) keeps things
pretty much in shape.

The shared data structure matching stuff was, for instance, why you had
to rebuild the world when going from libc5 to libc6. The data structures
maintained by things like malloc() drastically changed, and because
libc5 didn't use symbol versioning it was impossible to hide this from
the user; a malloc() in a library linked against libc5 followed by a
free() in its caller linked against libc6 would have led to a corrupted
heap arena and a crash.

The ABI matching stuff is why you had to rebuild all C++ programs when
going from, say, GCC 2.95.x to GCC 3; the data structures used to
represent things like C++ classes in memory changed. (This is really a
special case of the previous case, except that ABIs are shared data
structures that every single program in some language has an implicit
dependency on, because they're compiler-generated.)


In addition, there's the issue that in older GCCs, libgcc.a contained
exception-handling code that was linked directly to your binary: this
code maintained global structures which there must be only one copy of
per process --- yet shared libraries often had their own copies of this
code, and they sometimes made multiple copies of those data structures,
or disagreed on their layout... nowadays, C++ programs are linked
against a shared version of this library, ensuring that there's only one
copy of the exception-stack-walking code per process.

(But this is *another* reason why old and new C++ code won't work
together.)

> Why do the static libraries tend to work more frequently than the
> dynamic libraries?

Because they get actually linked in to the binary, and so don't change
from underneath it. (However, static libraries may sitll get broken by C
library upgrades, among other things, and are accordingly deprecated or
outright unavailable on some systems, like Solaris 10 and recent Linux
distros.)

> As a provider of such libraries to clients, I'd like to try to
> minimize the # of machines and builds that need to be done.

If you stick to the oldest (still compatible) versions of libraries that
you can find or that are used in major distributions, you should be
safe; important libraries like the X libraries or glibc are either
insanely compatible (libX11), or state that programs linked against some
library version X are guaranteed to work with higher versions until the
major version number changes (which of course signals broken
compatibility, as usual). Less visible libraries sometimes break this
guarantee, but it's pretty much an assumed thing these days: it's not
very common to find binary compatibility being broken without major
version number bounces.

(Note that this doesn't mean that you can link against, say,
libtiff.so.3.7.1 and expect people to be necessarily able to use your
program with libtiff.so.3.6.0; the guarantee only works
*upwards*. Library maintainers can introduce new stuff at any time, but
can only break old stuff when they bump the major version number.)

(In some situations, different distributors provide different major
versions of some libraries, or provide shared libraries in development
that don't guarantee a stable ABI: in that situation, your only choices
are to ship a copy yourself, or to mandate a particular version of the
library.)

-- 
`Blish is clearly in love with language. Unfortunately,
 language dislikes him intensely.' --- Russ Allbery

Re: dynamic library version crashes but static version works

[Ben Elliston]

Nix <nix@esperi.org.uk> writes:

> > I have a few more questions regarding the compatibility of dynamic
> > (and static libraries).
> 
> (This is probably off-topic on the GCC list, but I'm not aware of a list
> where it would be on-topic, really.)

gcc-help would be a much better place.

Ben