On Monday, December 3, 2012 5:06:43 PM UTC+1, Bill Hart wrote: > > Just to clarify, MPIR can pick up files from x86 even on Apple 32. But > these all have alternative code paths depending whether -DPIC is passed or > not. So -DPIC must not be passed on this system. > Ok now I'm confused. What's the point of the applenopic directory? The files it contains are all exact copies of the one from x86, except for some tuning parameters in headers, and for the fact that files which contains things depending on PIC are not present? It's true as well for the core2 subdirs.
I though that the applenopic was then meant to completely replace the x86 one. If the x86 one is looked at as fallback, the applenopic seems quite useless. > The only correct fix here is to fix aclocal.m4 to not add -DPIC to the > list of options on this system. > > Bill. > > On Monday, 3 December 2012, leif wrote: > >> Jean-Pierre Flori wrote: >> >>> >>> >>> On Monday, December 3, 2012 3:55:50 PM UTC+1, Bill Hart wrote: >>> >>> I assume you mean divexact_1.asm. >>> >>> I don't think we set -DPIC anywhere, so I think this is an autotools >>> bug. How recent is the report? It might have been fixed by the latest >>> autotools upgrade that we did. >>> >>> It's quite recent, from a few days ago, been tested with MPIR 2.6.0 (and >>> 2.4.x with similar results). >>> >>> To make things clear : >>> - this is with mac os 10.4 and 5 running in 32 bits mode on 64 bit intel >>> hardware, so there is no PPC involved here, >>> - we do not set PIC in the sage spkg, nor does MPIR itself, so it seems >>> that some autotools magic decide to add it by default, >>> >> >> Presumably. The problem is (at least) that it gets passed to m4 as well. >> [Not sure whether divexact_1 is incidentally just the *first* file (of >> probably a couple) Apple's as bails out.] >> >> - the problem is that MPIR then wants to use the corresponding asm files >>> with PIC defined and these files use the @GOT construction that Apple's >>> AS in this Mac OSes does not understand >>> >> >> Not sure. Did you see his full log (i.e., the setting of MPN_PATH)? >> >> Note that there's no version of divexact_1 in the mpn/applenopic path, so >> [either mpn/x86/core2/divexact_1.asm or] mpn/x86/divexact_1.asm is chosen, >> no matter what. >> >> Both files contain conditional code, depending on the setting of the (m4) >> PIC macro. The error is apparently caused by autotools passing -DPIC[=1] >> to *m4*. >> >> Here is how we dealt with that before: delete all the problematic asm >>> files, so that there is no @GOT anywhere and that did the trick. >>> According to Bill, and if I understood correctly, that should not be >>> necessary because autotools should detect its building MPIR on Mac OS on >>> intel hardware and should choose the x86/applenopic subdirectory rather >>> than the files from the x86 toplevel or say from the x86/core2 >>> subdirectory which contain the @GOT construction. >>> But that does not seem to be the case, files from other directories than >>> the applenopic one are picked up here. >>> >> >> See above. MPN_PATH (almost) always contains multiple directories, the >> files/implementations from the first which contains a file/implementation >> get chosen. >> >> Not sure what to think of the PIC thing. >>> I guess it's quite natural that autotools tries to build PIC code by >>> default if the system should be capable. >>> The problem here is really that it also chooses files in a wrong >>> directory and in the case of PIC code, the assembly files in this >>> directory contain instructions that the assembler does not understand. >>> >> >> Nope, I don't think so. (That's at least not the case for divexact_1.) >> >> >> As a temporary hack for the spkg, we could just patch out the conditional >> "manually" (as if PIC was set to zero) when building on that platform. Or >> invalidate -DPIC for m4 by other means... (m4-ccas script?) >> >> As mentioned, not sure whether it's just the *first* error Apple's as >> raises, but my guess is no. [Passing -DPIC to GCC doesn't hurt I think, as >> it knows how to properly handle that.] >> >> >> -leif >> >> -- >> () The ASCII Ribbon Campaign >> /\ Help Cure HTML E-Mail >> >> -- >> You received this message because you are subscribed to the Google Groups >> "mpir-devel" group. >> 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 <http://groups.google.com/group/mpir-devel?hl=en>. >> >> -- 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/-/a9WyOel9EuQJ. 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.
