From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Kidd To: egcs@egcs.cygnus.com Subject: Re: __register_frame_info & shared library compatibility Date: Tue, 06 Apr 1999 16:14:00 -0000 Message-id: <19990406191555.C23443@moebius.dartmouth.edu> References: <19990406184117.A23443@moebius.dartmouth.edu> <199904062251.SAA16043@blastula.phys.columbia.edu> <199904062251.SAA16043@blastula.phys.columbia.edu> X-SW-Source: 1999-04/msg00191.html 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Kidd To: egcs@egcs.cygnus.com Subject: Re: __register_frame_info & shared library compatibility Date: Fri, 30 Apr 1999 23:15:00 -0000 Message-ID: <19990406191555.C23443@moebius.dartmouth.edu> References: <19990406184117.A23443@moebius.dartmouth.edu> <199904062251.SAA16043@blastula.phys.columbia.edu> X-SW-Source: 1999-04n/msg00193.html Message-ID: <19990430231500.MJn0SmGLW_xP5qBawJvKmXYteoiIUfu982R6TQMODb8@z> 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