This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: What could cause this SEGV
On Wed, 2018-06-13 at 13:03 +0100, Andrew Haley wrote:
> > If it is an ordering problem that implies to me that it's a bug in
> > the _fastmath code, which is not properly accounting for ordering
> > issues during static initialization, no?
>
> It certainly could be that. Any writable static data in a shared
> library is potentially problematic, especially if it is exported.
I believe I've discovered the problem.
Through the layers of the build system somehow my setting for the strip
program was being lost and instead of running my encapsulated strip,
the build was running /usr/bin/strip.
On the non-working system, which is older and using binutils 2.25.1,
the result of stripping the MPIR library gives this coredump behavior.
On the working system, which is newer and using binutils 2.29.1, the
result of stripping the MPIR library gives correct behavior.
If I force my encapsulated strip to be used everywhere then the
resulting .so works properly regardless of where it's built.
So, it was a problem with my encapsulation just not the way I expected
it!