This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Plans for ABI migration
- To: Andreas Jaeger <aj at suse dot de>, bernie at codewiz dot org
- Subject: Re: Plans for ABI migration
- From: Bernardo Innocenti <bernie at codewiz dot org>
- Date: Wed, 10 Jan 2001 01:36:19 +0100
- Cc: gcc at gcc dot gnu dot org
- Organization: CodeWiz
- References: <01010921385201.28923@beetle> <u8lmske9jf.fsf@gromit.rhein-neckar.de>
- Reply-To: bernie at codewiz dot org
On Tuesday 09 January 2001 21:48, Andreas Jaeger wrote:
> > Following the example of the libc5 -> glibc migration,
> > perhaps it would be possible to let ld.so distingish
> > programs compiled by g++ 3.0 from older versions and use
> > a different library path in this case. Something like this
> > could go in /etc/ld.so.conf:
> >
> > /usr/lib=gcc3
> > /usr/i686-linux-gcc2/lib=gcc3
> > /usr/local/lib
> > ...
>
> That would require changes in the dynamic linker and ldconfig - and
> therefore changes in glibc. And I don't see how the dynamic linker
> could recognize those libraries at all in a secure way (there might be
> some hacks but nothing that works all the time).
Yes, I was thinking that the gcc developers could get in contact with
the glibc guys to discuss a coordinated effort to let ld.so recognize
ELF modules compiled by the new compiler.
A simple (but possibly lame) way that comes to my mind is:
- g++ adds a special asm directive (.stabs?) that contains
information about the C++ ABI version;
- gas preserves it into the ELF object module
- ld collects all them and generates a single ABI version
tag in a way that's convenient for ld.so to check;
- the dynamic linker looks for the ABI version before deciding
what to do.
By the way, ld already supports symbol versioning. It's used by
glibc to enable binary compatiblity for programs compiled with an
older revision. You can tag EACH symbol in a library with a
"@TAG" version that the ld.so tries to match when linking with
a dynamic library. This is _not_ what we need in our case, but
it makes a good example of binary compatibility.
Even if I'm used to compile stuff from source code,
I always disliked the UNIX notorious lack of binary
compatibility between kernel versions (BSD) or library
versions (Linux). There's certainly room for improvement.
I recall that AmigaOS could easily maintain perfect ABI
and API compatibility for over 10 years (OS1.1 to 3.9).
The only mayor drawback was with some BCPL pointers around
in some old subsystems that were originally written in BCPL
instead of C.
--
// Bernardo Innocenti
\X/ http://www.codewiz.org