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 06/14/2018 06:37 AM, Paul Smith wrote:
> 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!
Excellent, glad you found it.
By the way, we solve this problem at Red Hat by using mock, which creates
an empty container and fills it with the dependencies of each package.
That way, we know we have no missing dependencies.
https://github.com/rpm-software-management/mock/wiki
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671