Re: FW: Problem with libraries...

[Ian Peters <itp gnu org>]

On Wed, Mar 10, 1999 at 05:18:53PM -1000, Torben Noerup Nielsen wrote:
> All,
> 
> Irrespective of what it is caused by, it does cause me a lot of problems. I
> cannot run wmakerconf because of it. And I can't even recompile it. I guess
> I'll just have to put glib10 and gtk+10 in and see if that solves it all. It
> would be really nice to have a solution to this since it is largely
> preventing me from running things. I cannot run linuxconf either :-(
> 
> Does anyone know of an easy way out of this problem?
> 
> Also, when might the glibc-2.1 sources be put back on the GNU sites? Having
> them ``temporarily removed" doesn't help.
> 
> Thanks, Torben

Taking Ulrich's advice, I have turned to the glibc FAQ.

---------------------------------------------------------------------------
2.8.    When I run an executable on one system which I compiled on
        another, I get dynamic linker errors.  Both systems have the same
        version of glibc installed.  What's wrong?

{ZW} Glibc on one of these systems was compiled with gcc 2.7 or 2.8, the
other with egcs (any version).  Egcs has functions in its internal
`libgcc.a' to support exception handling with C++.  They are linked into
any program or dynamic library compiled with egcs, whether it needs them or
not.  Dynamic libraries then turn around and export those functions again
unless special steps are taken to prevent them.

When you link your program, it resolves its references to the exception
functions to the ones exported accidentally by libc.so.  That works fine as
long as libc has those functions.  On the other system, libc doesn't have
those functions because it was compiled by gcc 2.8, and you get undefined
symbol errors.  The symbols in question are named things like
`__register_frame_info'.

For glibc 2.0, the workaround is to not compile libc with egcs.  We've also
incorporated a patch which should prevent the EH functions sneaking into
libc.  It doesn't matter what compiler you use to compile your program.

For glibc 2.1, we've chosen to do it the other way around: libc.so
explicitly provides the EH functions.  This is to prevent other shared
libraries from doing it.  You must therefore compile glibc 2.1 with EGCS.
Again, it doesn't matter what compiler you use for your programs.
---------------------------------------------------------------------------

Implication?  You are using a new glibc (2.1 or a snapshot) and have
compiled it with gcc 2.7 or 2.8.  You should compile 2.1 and snapshots
with EGCS.  I believe, in fact, that this is the reason glibc 2.1 was
removed - unhappiness on some people's part that glibc 2.1 required
EGCS.  (Someone correct me if I am wrong.)

-- 
Ian Peters		"The farther you go, the less you know."
itp@gnu.org				-- Lao Tsu, "Tao Te Ching"