On Monday, December 3, 2012 5:38:17 PM UTC+1, Bill Hart wrote: > > Well that certainly reveals one possible way around the problem, namely to > preprocess the other needed files so they only follow the nopic path then > put them in the applenopic directory.
> I'm not sure why they aren't all there in the first place. If as you say, > the files that are there are just preprocessed versions of the other files, > then that doesn't make sense. But then, the applenopic directory also makes > no sense in that case to me. Why not just fix the -DPIC thing in aclocal.m4? > > Maybe the idea was to create a directory without the bad files and only use this directory instead of the x86 one. I still insists but for me the PIC flag should only be used to decide wether we want PIC or not PIC flag, and that's a choice the user made. It should not be undefed by the build system to rule out the inclusion of files which will kill the assembler. And once again the problem is not the ability of producing PIC code, its really the ability of understanding a macro used by MPIR in a PIC branch: so I don't think that because in some PIC branch we don't understand some isntruction, then the solution is not to try at all. In that sense, what I feel the original purpose of the new applenopic directory was makes more sense. > Bill. > > On Monday, 3 December 2012, Jean-Pierre Flori wrote: > >> >> >> 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+unsubscribe@** >>>> 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/-/cuETosbb8wIJ. 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.
