What could cause this SEGV

[Paul Smith]

I have a strange situation and I'm looking for advice as to how to
proceed further.  Or if I should just give up.

I have an encapsulated build toolchain on GNU/Linux which uses GCC
8.1.0, binutils 2.30 (using gold), and a Red Hat Enterprise Linux 6.5
sysroot (libc etc.)  I can successfully compile code with this
toolchain and have it run on all sorts of systems from RHEL 6.5 and
above (which is most every GNU/Linux distribution released in the last
4 years or so).

However, even though this toolchain is completely encapsulated (that
is, when I look at both the preprocessor output and verbose linker
output I don't see any reference to any file outside of the toolchain,
other than the ones I'm compiling of course), when I create a
particular shared object on one system it dumps core when used but when
I create it on another system it does not dump core and works properly.

The problem happens during the link operation (so maybe this isn't the
right list).  If I copy the object files from the "working" system to
the "failing" system, and just re-link, then the resulting .so still
seg faults.  The encapsulation is identical (copied from one system to
the other).  I've run md5sum on all the object files, local libraries,
and system libraries mentioned in the linker verbose output and
compared them and they're identical before linking.

I've compared the output of -Wl,--verbose and aside from addresses the
output is the same: no different flags etc.  The compile and link use
-mtune=generic -march=x86_64.

Also the working .so runs correctly on all the systems, and the failing
.so fails on all the systems (even the one it was created on).

FWIW, the failing .so is a Python 2.7 module which is part of the
Pycrypto package: it's _fastmath.so which links in a static GNU MPIR
3.0.0 library and is dlopen()'d by Python.  When it fails it dumps core
in the __gmpz_init() function.  Unfortunately I have nowhere near
sufficient assembly fu to investigate much more than that.

Is there more I could do to track this down and understand it?  Should
I just proceed with the "working" _fastmath.so and call it good?  It
seems like there's some hole in my encapsulation that I can't see; I
would prefer to find and patch it if possible...