Re: __register_frame_info & shared library compatibility

[Eric Kidd <eric dot kidd at pobox dot com>]

On Tue, Apr 06, 1999 at 06:51:23PM -0400, Zack Weinberg wrote:
> On Tue, 6 Apr 1999 18:41:17 -0400, Eric Kidd wrote:
> >I help maintain a compiler that's hard to bootstrap. Currently, I must be
> >able to compile glibc-2.0/gcc-2.7 binaries on my system. So my upgrade
> >options are very limited. :-(
> 
> Can you give details?  Maybe I can help disentangle it.

I build glibc2 binaries and RedHat 5.2 RPMS for the Gwydion Dylan compiler:

  http://www.gwydiondylan.org/

It generates ANSI C code, which we then run through a system-dependent
compiler (normally GCC). This works better than you might expect, because
the optimizer is aggressive enough to generate reasonable C code.

The public releases of the compiler link against the C library dynamically,
but use a statically-linked Dylan runtime. So we're pretty well insulated
from many common problems. But I still need to support glibc 2.0 for all
the RedHat 5.x users out there.

> Unfortunately, 2.0 and 2.1 do not coexist well.  You would almost need a
> complete chroot environment to retain the ability to build 2.0 binaries.
> Better use two machines...

I've got diskspace to spare. Is it possible to install a chrooted RedHat or
Debian build environment, given enough patience?

> You will definitely lose if you have any references to stdin/out/err
> inside the library.  If you don't, you might survive, but you might
> not.  Best advice is `try it and see'.

OK, but existing *.a files should be safe, since they haven't been linked
yet? If so, our users are OK--none of our stdio code is in shared
libraries.
 
> > * If you compile glibc with egcs, you can often use egcs-compiled shared
> >   libraries with gcc-compiled applications.
> 
> Yes - and if it doesn't work, that's a bug.

Good. So there's hope. :-) My many thanks for helping me sort through this
problem; I'll pass your advice along to other folks.

Cheers,
Eric