Yes, I guess it is Apples version of as. Bill.
On 3 December 2012 16:59, Jean-Pierre Flori <jpfl...@gmail.com> wrote: > > > On Monday, December 3, 2012 5:55:38 PM UTC+1, Bill Hart wrote: >> >> The assembler here is gas, not yasm, and it doesn't allow GOT >> addressing. Thus, I would say the system is not PIC capable. >> > You mean GNU as? > I though all the GOT problem was that it understood @GOT but the Apple as > (surely derivated from the previous one) did not. > >> 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 <jpf...@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-...@googlegroups.com. >> >>>>> To unsubscribe from this group, send email to >> >>>>> mpir-devel+...@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.
