Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Jeffrey A Law <law at cygnus dot com>]

  In message <m366qdl2ar.fsf@otr.mynet.cygnus.com>you write:
  > I don't really know what to do, I haven't spend much time thinking
  > about it.  Your comment above is exactly amplifying my fear: gcc
  > people cannot spend so many thoughts on one platform.  Naturally, I
  > don't blame you.
  > 
  > This is exactly why HJ suggested to leve the generation of the
  > libgcc.so to glibc or some additional new package.
This seems totally backwards to me.  GCC knows about things like it's
install directory, what version # to use for libgcc, what libraries have
been built (do you really want to spread multilib knowledge any further
than it's already spread)?

We should handle this like we do any other problem in GCC by designing a
system that is relatively generic and which can be easily tweaked to deal
with system specific dependencies.

I do not see what we gain by moving the creation of libgcc.so to another
package other than unnecessary complexity.  I do not see that it simplifies
things.

  > simply the libgcc with the interface(s) it currently supports the
  > creation of libgcc.so outside gcc (which therefore can have many more
  > demands on the environment like a ld which understands versioning) can
But that can be done in gcc too -- ie, we have code which knows that 
ld understands versioning and some backup plan where ld does not understand
versioning.

We have autoconf see what version of ld you've got and the appropriate code
is automatically enabled.

  > - add more legacy interface which are needed but are not supported
  >   anymore by gcc or which do some data rewriting before calling the
  >   actual libgcc functions
Agreed, if you're going to do this then I'd like to see it happen completely
outside gcc.  I'm not sure how wise it is, but if we provide both libgcc.a
and libgcc.so, you'll still have this capability.

  > - create and install the actual libgcc.so with the appropriate soname
What about moving this into a different package makes it easier than having
it in gcc?  I'm thinking about install paths, multilibs and the like -- GCC
knows about that stuff, and I'm not keen on expanding the number of packages
that need to know about such braindamage.


  > The alternative is to find somebody (or a group) for each of the
  > arch/OS combinations which care about compatibility at this level and
  > have them maintain the data inside gcc and to significantly extend the
  > build infrastructure to handle the soname and versioning requirements.
Yup.  That's how things have always been done in gcc-land.  

  > Everybody who just dismissed HJ's proposal should stop and think about
  > this for a moment.  Will you be willing to do what I described inside
  > gcc?
Yes.

  > How this actually should be implemented is unclear to me.  It might be
  > that the solution is a small shell script and possibly a few more .c
  > files and create from the installed libgcc.a a .so file.  It's also
  > possible to pass a lot more information inside the libgcc.a file
  > (remember: this is an archive and not at all limited to .o files).  So
  > it would be possible to put into libgcc.a all the sources and some
  > kind of interface description.
Yup.  You can hide all kinds of interesting things in .a files.  But is
that really a good idea?  Presumably you're looking at this as a way to
pass information from gcc to some external package which builds the
shared library.  However, if we build the shared library within gcc itself
I'm not sure if we need to squirrel away random information in libgcc.a.

jeff