versioned symbol problem

versioned symbol problem

[Paul Jarc]

I really have no understanding of symbol versioning, which code is
responsible for it, or what purpose it serves.  So I may be posting to
the wrong list, but I hope someone can at least point me to the right
list.

I'm compiling XFree86 on a GNU/Linux system almost entirely built from
scratch, and I get this error:
+ c++ -o ./libGLU.so.1.3~ -shared -Wl,-soname,libGLU.so.1 [long list of object files] -lc
ld: ./libGLU.so.1.3~: undefined versioned symbol name __frame_state_for@@GLIBC_2.0
ld: failed to set dynamic section sizes: Bad value
collect2: ld returned 1 exit status

I've gotten similar errors with Mozilla and ImageMagick and the symbol
__register_frame_info; I was building with RedHat's X packages, so I
had assumed that something in those libraries needed an old versioned
symbol, but now I'm building X and it still happens.  I've compiled my
own glibc 2.2.5 (using gcc 3.1, IIRC), and I've built flex, ncurses,
zlib (which X links with), and gcc 3.1.1 (thus libgcc, where these
symbols reside) using that glibc.  So it seems to me that there
shouldn't be any disagreements about versions.  Do I need to rebuild
glibc with my new gcc?  I got the __register_frame_info problem with
Mozilla using gcc 3.1 and glibc built with that gcc, so that doesn't
seem like it would help.  How can I find out exactly what refers to
this versioned symbol?


paul

Re: versioned symbol problem

[Paul Jarc]

I wrote:
> I'm compiling XFree86 on a GNU/Linux system almost entirely built from
> scratch, and I get this error:
> + c++ -o ./libGLU.so.1.3~ -shared -Wl,-soname,libGLU.so.1 [long list of object files] -lc
> ld: ./libGLU.so.1.3~: undefined versioned symbol name __frame_state_for@@GLIBC_2.0
> ld: failed to set dynamic section sizes: Bad value
> collect2: ld returned 1 exit status

The problem here seems to have been that I had configured gcc with
--disable-shared; a new installation including a shared libgcc makes
the problem go away.  It would be nice if gcc were to detect when a
shared libgcc is needed but not present, and give a more meaningful
error message.

There's also a massive documentation bug in that symbol versioning is
not covered at all.  I had to guess that it is something that applies
only to shared libraries and that these object files were compiled as
if they were going to be linked to the shared libgcc even though none
was present.  I don't know if this belongs in the gcc manual or the
binutils manual (precisly because I have no understanding of symbol
versioning, because it is undocumented), but it should documented
somewhere.


paul

Re: versioned symbol problem

[Bruce Stephens]

prj@po.cwru.edu (Paul Jarc) writes:

[...]

> There's also a massive documentation bug in that symbol versioning
> is not covered at all.  I had to guess that it is something that
> applies only to shared libraries and that these object files were
> compiled as if they were going to be linked to the shared libgcc
> even though none was present.  I don't know if this belongs in the
> gcc manual or the binutils manual (precisly because I have no
> understanding of symbol versioning, because it is undocumented), but
> it should documented somewhere.

It's documented in the ld manual.  The documentation may be
insufficient, but there is some.

Re: versioned symbol problem

[Paul Jarc]

Bruce Stephens <bruce@cenderis.demon.co.uk> wrote:
> prj@po.cwru.edu (Paul Jarc) writes:
>> There's also a massive documentation bug in that symbol versioning
>> is not covered at all.
>
> It's documented in the ld manual.  The documentation may be
> insufficient, but there is some.

Ah, now I see it.  It's rather hard to find without knowing where it
is, but I'll take that off this list.


paul

Re: versioned symbol problem

[Phil Edwards]

On Mon, Aug 12, 2002 at 10:42:13PM +0100, Bruce Stephens wrote:
> prj@po.cwru.edu (Paul Jarc) writes:
> 
> [...]
> 
> > There's also a massive documentation bug in that symbol versioning
> > is not covered at all.
> 
> It's documented in the ld manual.  The documentation may be
> insufficient, but there is some.

Sun's Linker/Libraries Guide also has a good description of symbol
versioning.  The syntax of Sun's versioning scripts was the basis of that
used by GNU ld, so the examples are helpful.  http://docs.sun.com/ to start.

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002