This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Plans for ABI migration

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 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/
 >  >
 >  >    /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 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 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 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]