The assembler here is gas, not yasm, and it doesn't allow GOT addressing. Thus, I would say the system is not PIC capable.
It is possible to write the assembly files in another style which doesn't require jumping into the middle of a loop, and that obviates the need to use the GOT. But I wouldn't say that makes the system PIC capable. Bill. On 3 December 2012 16:48, Jean-Pierre Flori <jpfl...@gmail.com> wrote: > > > 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+unsubscr...@googlegroups.com. >>>>> For more options, visit this group at >>>>> 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 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.
