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<javascript:>> > 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<javascript:>. > > >>>>> To unsubscribe from this group, send email to > >>>>> mpir-devel+...@googlegroups.com <javascript:>. > >>>>> 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 view this discussion on the web visit https://groups.google.com/d/msg/mpir-devel/-/DfsmbRKXQ_UJ. 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.
