Vincent Lefevre writes:
> So, in case of 32-bit x86 mode in the compiler, shouldn't $host be
> seen as matching X86_PATTERN instead of X86_64_PATTERN?
Interestingly, it seems config.guess checks $CC (but not $CFLAGS):
$ ./config.guess
haswell-pc-linux-gnu
$ CC='gcc -m32' ./config.guess
On 2018-02-12 12:52:49 +0100, Torbjorn Granlund wrote:
> It is less common that people set CC/CFLAGS to bad values (or at least
> we don't hear about that very often). I don't think we should try to
> accomodate that since it would result in lots of fragile complexity.
> (If you don't agree, pleas
t...@gmplib.org (Torbjörn Granlund) writes:
> It is not easy to find anything better than what we have today.
>
> The current strategy was chosen to work best for most users, and work
> best here means to give optimal GMP performance. If the optimal "ABI"
> does not work, the next best "ABI" is t
Vincent Lefevre writes:
So, if I understand correctly, this means that if the user chooses
to set -m32 in CFLAGS, he might have to try different ABI values
before finding one that works (because -m32 does not necessarily
imply 32-bit limbs). This is not nice.
It is not easy to find anyth
On 2018-02-12 10:31:23 +0100, Torbjorn Granlund wrote:
> Vincent Lefevre writes:
>
> As written above, this is for C compilers. But GMP also has assembler
> code. So, you need to provide an option that will affect the assembler
> code. This is what ABI is for.
>
> That said, perhaps GM
Vincent Lefevre writes:
> That said, perhaps GMP might be improved to detect the ABI by a
> simple parsing of $CFLAGS when provided by the user (in case values
> like -m32 or -m64 are standard).
In Nettle, I try to detect the ABI used by the configured C compiler,
with a configure test like
c
Vincent Lefevre writes:
As written above, this is for C compilers. But GMP also has assembler
code. So, you need to provide an option that will affect the assembler
code. This is what ABI is for.
That said, perhaps GMP might be improved to detect the ABI by a
simple parsing of $CFLAG
On 2018-02-11 19:21:33 -0500, Jeffrey Walton wrote:
> That's not true. In fact, Stallman specifically tells the project to
> adds the flags it needs. Below is from Section 7.2.3 of
> https://www.gnu.org/prep/standards/standards.html. This would fix the
> ARM compile problem, too:
>
>
>
> If ther
On Sun, Feb 11, 2018 at 4:40 PM, Niels Möller wrote:
> Jeffrey Walton writes:
>
>> But please see -m32 -march=native, which was provided to configure to
>> configure with.
>
> Setting CFLAGS simply specifies what flags to be passed to the C
> compiler, totally overriding configure's automatic sel
Jeffrey Walton writes:
>
>
> If there are C compiler options that must be used for proper
> compilation of certain files, do not include them in CFLAGS. Users
> expect to be able to specify CFLAGS freely themselves.
This is getting silly. ./configure gets conflicting options. Adding its
own opt
Jeffrey Walton writes:
> But please see -m32 -march=native, which was provided to configure to
> configure with.
Setting CFLAGS simply specifies what flags to be passed to the C
compiler, totally overriding configure's automatic selection of compiler
flags. But CFLAGS is *not* interpreted by con
On Sun, Feb 11, 2018 at 4:52 AM, Torbjörn Granlund wrote:
> Jeffrey Walton writes:
>
> Configure seems to be misdetecting this 32-bit platform. The machine
> is CentOS 6, i686 .
>
> The environment is:
>
> PKG_CONFIG+PATH: /usr/local/lib/pkgconfig
>CPPFLAGS: -I/usr/local/inclu
Jeffrey Walton writes:
Configure seems to be misdetecting this 32-bit platform. The machine
is CentOS 6, i686 .
The environment is:
PKG_CONFIG+PATH: /usr/local/lib/pkgconfig
CPPFLAGS: -I/usr/local/include -DNDEBUG
CFLAGS: -g2 -O2 -m32 -march=native -fPIC
C
13 matches
Mail list logo
