On 06/13/2018 12:54 PM, Paul Smith wrote: > On Wed, 2018-06-13 at 12:11 +0100, Andrew Haley wrote: >>> 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... >> >> It might be related to ordering. There very probably is something >> really wrong, so I think it deserves more investigation. However, >> I think you really have to debug it. gdb is your friend. > > I did make an effort to use GDB, but the code is compiled with a high > level of optimization and stripped and there were no useful debug > symbols. OK, so you should fix that problem. > Because of the nature of the object (python module, etc.) its build > options are buried under several layers and not easy to modify. I > will make more of an effort (recompile by hand etc.) and see where I > get. > > 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. > Or is your concern that it could be an issue in the linker itself? It's always been really difficult to make completely reproducible builds, as you have seen. I suspect that you may have a problem with multiply-defined symbols in libraries, in which case it's a matter of luck which one gets found. It may also be a problem with copy relocs, which are a truly evil hack, but let's not get ahead of ourselves. Right now it's crucial not to make any assumptions about what is going wrong. Keep a clear head and go where the evidence leads. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. <https://www.redhat.com> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
