And I don't understand why PIC should not be defined on such systems. I don't consider that "it makes the build fail because files which cannot be compiled get picked" is not a good answer in my mind. Doing "if we set PIC, it fails, so lets undefine PIC at some depth so that is works" seems like a workaround, not a proper fix.
You may want PIC code, and it may or may not make sense on different systems. As far as I understand, on the problematic you can produce PIC code, its just that the assembler does not like some instructions that the MPIR build system feeds it with. So you should be able to let PIC be defined and the job of the build system is to pick files without not understandable instructions, not to undefine PIC somewhere in between so that in the problematic files it gets uses the not PIC branches of the tests. Moreover, do these non PIC branches become PIC on the problematic system whereas they are not on other systems? That looks kind of magical (but as I'm not an assembly hacker, far from that, in fact I must admit I know nothing), or would mean there is no need for the tests from the beginning whatever the system is (that seems less magical but senseless)? So in fact undefining PIC at some point and pretending the produced files are PIC might lead to further problems. > -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To view this discussion on the web visit https://groups.google.com/d/msg/mpir-devel/-/_TN-eZoqXOEJ. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
