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: Plans for ABI migration


On Thursday 11 January 2001 05:15, Alexandre Oliva wrote:

 > On Jan 10, 2001, Bernardo Innocenti <bernie@codewiz.org> wrote:
 > >  That's right. Break it whatever you want. Break it again in the
 > > future if you need to. But please plan a small kludge for ld.so to
 > > make the transition a little easier.
 >
 > We don't make any kludges in ld.so.  That's not in the scope of the
 > GCC project.

 Of course it isn't. I said that we should just _plan_ something.
And coordinate with the glibc guys to make it happen when it will
be needed by the distribution makers.


 > But note that the kludge that was used for the transition from libc5
 > to libc6 was unnecessary, and people who did it are already aware of
 > their mistake.  The correct way to deal with the problem was to give
 > libraries different SONAMEs depending on the ABIs they were bound to,
 > so that they wouldn't be linked into programs that used a different
 > ABI.
 >
 > I agree, it's not like every package out there that creates shared
 > libraries comes with an option to insert a certain string in the
 > SONAMEs of libraries it creates, but there are programs that may help
 > mitigate this problem, by modifying SONAMEs in already-compiled
 > libraries and programs.  That's probably the way to go.

 Hmmm... I dislike both solutions, but we must choose the poison that we
find least unappealing. What's the worst scenario? Two lib/ directories
with copies of the same libraries, or one big lib/ directory with two
copies of each library?

 In the beginning, you had "libfoo.so" for shared libraries. Then
someone come up with major/minor versions to address the problem of
api changes, so libraries looks like "libfoo.so.1.42", which ld.so
will automatically match with the plain name because it knows about
revisions. Then someone else wanted to bypass the ld.so smartness and
encoded version numbers in the library name like this: "libfoo-1.1.so.1.42".
Now we suggest to extend this mess even further to include the C++
ABI version into the name. What will we get? "libfoo-1.1-gcc3.so.1.42"?
Yes, it really sucks; expecially when everybody will need to fix their
Makefiles according to the ABI version of the compiler. Who is supposed
to replace -lfoo-1.1-gcc3 with -lfoo-1.1-gcc4 when the ABI will change
again in the future? It will probably require yet another autoconf test
and perhaps some trick in libtool.

 Is this acceptable?



 > >  By the way, what's the rationale behind setting up libstdc++ as
 > > a shared library by default?
 >
 > It used to be built as a static library by default, in the past.  But
 > most (all?) GNU/Linux distributors would configure GCC with
 > --enable-shared so as to get a shared libstdc++.

 :-(

 > > It contains only small routines
 >
 > When did you last check that? :-)

 Oops... I've looked around in libstdc++-v3 and you're right.
BUT, the source files are organized to group together all members
of the same class. This is what everybody usually does in C++
programs to split them in managable modules. But when you are
planning to put this code into an archive library, it's best to
split each function (or each atomic group of functions) in its
own source file. This is because the linker brings in
the whole object module when it needs a symbol inside it.

 I've looked at the object modules. locale.o is over 700KB here,
probably because it contains template instantiations for all sort
of parameters. That's *why* people don't want to link statically!

-- 
  // Bernardo Innocenti
\X/  http://www.codewiz.org

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