Re: [patch] Fix failure of g++.dg/other/first-global.C

[Mark Mitchell <mark at codesourcery dot com>]

John David Anglin wrote:
> The enclosed patch fixes the failure of g++.dg/other/first-global.C
> on 32-bit hppa-hpux targets.  This is a regression introduced by the
> reworking of cdtor priorities to support init priority.
> 
> cgraph_build_static_cdtor() always encodes the priority into the
> constructor name.  Before the rework for init priority, we didn't
> have the priority encoded in the name of global cdtors.
> 
> I believe that it's important to maintain symbol name compatibility
> for constructors.  The way libtool links applications against shared
> libraries will cause the application to fail at startup if the shared
> library is replaced and it contains a different exported global symbol.

As with the other patch, I'd appreciate knowing more about what's going
on here.  Is libtool generating code to link into the main application
that calls the global constructors for each of the shared libraries?
Does that happen only on non-ELF systems?  (I'd think that on ELF
systems, shared-library initialization is handled by an initialization
function for the library, run by the dynamic loader.)

> In this patch, I introduce a new function cgraph_build_static_cdtor_1
> which only encodes the priority if its fourth argument ENC_P is true.

Should cgraph_build_static_cdtor just never encode the priority for
things with the DEFAULT_INIT_PRIORITY?

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713