This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: libgcc_s.so.1 exception handling behaviour depending on glibc version


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)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]