This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Of libgcc -pic and -shared and openbsd config
On Wed, Sep 27, 2000 at 12:39:56AM +0200, Marc Espie wrote:
> > 1. If you ever implement elf symbol versioning, linking against the
> > implementing library is critical to getting the .o symbols bound
> > to the correct version. Not an issue for you now, but maybe later.
>
> Could you explain (briefly) how this is supposed to work ?
Symbol versions are applied to shared library (foo) initially by
use of a symbol version script. This data is stored in a couple
of special sections:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 4] .gnu.version VERSYM 000000000001803e 0001803e
0000000000000e28 0000000000000002 A 2 0 2
[ 5] .gnu.version_d VERDEF 0000000000018e68 00018e68
0000000000000080 0000000000000000 A 3 4 8
[ 6] .gnu.version_r VERNEED 0000000000018ee8 00018ee8
0000000000000030 0000000000000000 A 3 1 8
or
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 4] .SUNW_version VERNEED 00012368 012368 000020 00 A 3 1 4
[ 5] .SUNW_version VERDEF 00012388 012388 0003fc 00 A 3 1d 4
[ 6] .SUNW_versym VERSYM 00012784 012784 00109c 02 A 2 0 4
Whenever you link an executable or another shared library (bar)
against foo, the symbol version information will be copied over.
Note that raw .o files do not contain symbol version information,
only linked entities.
If you have an ld.so that knows about symbol versioning, it will
now not resolve the symbol name alone, but the tuple of symbol
name and version. This allows the library maintainer to rev each
symbol individually while maintaining backward compatibility.
No change is needed to foo's soname at all.
We've used this feature a couple of times between glibc 2.0 and 2.2
to fix small standards compatibility problems. E.g.
Num: Value Size Type Bind Ot Ndx Name
182: 000000000009d498 0 FUNC GLOBAL 0 15 setitimer@@GLIBC_2.1
1785: 00000000000cd558 0 FUNC GLOBAL 0 15 setitimer@GLIBC_2.0
SUS requires timeval.tv_sec to be a time_t whereas Linux had defined
it to be an int, which means the field was too small on 64-bit systems.
So we fixed the structure and added backward compatibility entry points
that frob the data appropriately.
Hmm, not very brief...
> 1/ Using gcc -shared to build libc makes stuff break in a big way,
> as you end up with libc depending on itself, and ld barfing all over
> the place.
See --nodefaultlibs.
> 2/ Depends where you're placing the barrier... if you build a portable,
> system independent compiler, this is fine.
I have no idea what your point is here.
> 3/ We don't have weak symbols on all platforms yet. Hence, our pthread
> implementation is done through a separate libc_r right now.
In which case you're not talking about ELF, and all my discussions
of ELF go out the window.
On the other hand, IMO this is not a good excuse for treating ELF
like a.out on those systems in which you are using ELF. And frankly,
anyone still using a.out in this day and age gets what they deserve.
r~