Linux vs. libio

[Jeffrey A Law]

  In message < 19991221155340.P14133@namaste.lokigames-lan.com >you write:
  > > Somehow, I don't quite believe that, no matter how well-meaning the glibc
  > > folks have been, such disasters won't happen again...  
  > 
  > Neither do I. Sure, I'd love for the C++ ABI to settle, but I'm not
  > counting on it.
At some point it really does need to settle.  IMHO, the biggest reason it
hasn't settled is the major vendors have all been targetting their own
cpus (sparc, parisc, mips, powerpc, etc) and as a result there hasn't
been much interest in ABI work to allow code built with one vendor's tools
to interoperate with code built by another vendor's tools.

That's starting to change with ia64.  Suddenly a number of players want to
have some level of binary compatibility with each others tools, so of
course they have start defining an ABI.

It's been a long time coming, but I'm happy to see progress made.

  > > linux folks (like having to upgrade the glibc version number...), will th
  > > Steering Committee take steps to ensure the Right Thing is done ?  
  > 
  > I'm concerned about this, too.
Likewise.

  > I develop binary only software for Linux. It is a pain
  > (__register_frame_info, glibc 2.0 vs 2.1 ABI breakage, etc.).
Yes.  These have all been a major pain in the (*&@#$.  I'm not at all
happy with how these issues have been handled to date.

  > First and foremost, I want a compiler that works. If it's possible to
  > do that within the framework of backwards compatability, so much the
  > better--as long as it isn't a burden on further development.
Certainly we all want a compiler that works.  No doubt.  But if we're
going to be taken seriously we also have to spend a lot more time
dealing with backwards compatibility than we have in the past.   In fact,
IMHO, it was a lack of attention to backwards compatibility and
communication between gcc & glibc that lead to the ongoing 
__register_frame_info problems!

  > then they do. I expected things to break from libc5 to libc6. No
  > pointing whining about it. I did not expect things to break from glibc
  > 2.0 to 2.1. Perhaps that was my misunderstanding.
This is largely out of the control of the GCC project since we do not
control glibc.


jeff