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.
