This is the mail archive of the gcc@gcc.gnu.org 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: A completely different approach to EH runtime


On Feb 21, 2001, "H . J . Lu" <hjl@valinux.com> wrote:

> Are you prepared to deal with 2 shared libgcc visible to ld.so at
> the same time and one of which doesn't come from the system vendor?

I don't know about you, but I am, for as long as libgcc's major
version number doesn't change.

As soon as it does, we'll have major hassles just like in the libc5->6
migration: there will be shared libraries linked with an old and the
new versions of libgcc.  No program should link with two such
libraries.  As usual, I have a feeling that SONAMEs should contain not
only the SONAME of the library itself, but also of all its
dependencies.  Not that it would help with this problem (this one just
can't be helped, I think), but at least it would be easier to maintain
multiple versions of the same library, with its own external version
number, but with different sets of dependencies.

I understand a hack in ld.so helped overcome the difficulties in the
libc5->6 migration, but I think we'd better avoid it completely for
libgcc.  If libgcc's interface *ever* drops a symbol, introducing
binary incompatibility, we'll have major difficulties in dealing with
the situation that will arise.  I believe that's the main problem
you're trying to get us to ponder about, right?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me


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