This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: libgcc_s.so.1 exception handling behaviour depending on glibc version
- From: Jonathan Wakely <cow at compsoc dot man dot ac dot uk>
- To: Mike Hearn <mike at navi dot cx>
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 18 May 2005 16:28:06 +0100
- Subject: Re: libgcc_s.so.1 exception handling behaviour depending on glibc version
- References: <428B0C62.4000603@sun.com> <pan.2005.05.18.12.36.08.21252@navi.cx>
On Wed, May 18, 2005 at 01:36:08PM +0100, Mike Hearn wrote:
> On Wed, 18 May 2005 11:35:30 +0200, Stephan Bergmann wrote:
> > If I build main with C1, and libf.so with C2, and execute the program so
> > that it uses C2's libgcc_s.so.1, it works.
>
> Out of interest, what happens if you build main with C2 and libf with C1?
> That would seem to be a more common situation for distributors of Linux
> binaries than the other way around.
>
> This policy of not supporting "build on newer, run on older" is a massive
> pain for developers who distribute Linux binaries even though it's very
> common: developers often use very new distributions but users often don't.
> It requires all kinds of stupid hacks to work around.
Such as compiling on an older system?
That's not a stupid hack, it's responsible library development IMHO.
Develop on your sexy new system, build releases on the old one
(which as Jakub points out, could be a chroot'd part of the same system)
> Could there please at some point be serious discussion of making this a
> supported way of working? In this case dl_iterate_phdr is weak so could
> the decision about whether to use it or not could be made at runtime, not
> build time?
How do you propose to make existing, installed libraries compatible with
all future versions that might exist at some point? :)
My favourite solution is to ship source, so users can compile it
themselves. Problem "solved" ;)
jon
--
"This Statement is False"
(Courtesy of POEE)