Ah, bingo, well done.
I had completely ignored this because according to the autotools manual
that script just checks for a C++ compiler and lets you specify an order to
search for them. But I had forgotten about the fact that it sets CXXFLAGS
with a preliminary value.
Oddly enough, when I reran autoconf -fiv and configure, this did not fix
the problem.
So I deleted configure and tried again. This time success.
Don't ask me. Yet another bug in my opinion.
Bill.
On 29 March 2014 01:06, leif <not.rea...@online.de> wrote:
> On 29.03.2014 00:09, Bill Hart wrote:
>
>> Hmm, autoconf 2.69 doesn't fix this problem either. Screwed if I know
>> how CXXFLAGS gets populated.
>>
>
> I *think* this is pretty unrelated to the autotools version; you simply
> moved AC_PROG_CXX up (in configure.ac), but not the prior test which is
> supposed to record whether CXXFLAGS had been set (by the user!):
>
> test_CXXFLAGS=${CXXFLAGS+set}
>
> AC_PROG_CXX of course modifies / sets CXXFLAGS, such that test_CXXFLAGS
> now always equals "set", so MPIR assumes *the user* had set them, and hence
> never tries to modify them.
>
> So it should be sufficient to either move AC_PROG_CXX back down, the test
> for user-set CXXFLAGS up (right /before/ AC_PROG_CXX), or -- presumably
> less robust -- to use one of the autoconf-saved values, ac_test_CXXFLAGS
> (instead of test_CXXFLAGS), or ac_save_CXXFLAGS (instead of CXXFLAGS).
>
>
> -leif
>
>
> On 28 March 2014 22:46, Bill Hart <goodwillh...@googlemail.com
>> <mailto:goodwillh...@googlemail.com>> wrote:
>>
>> I think it's a new autotools bug. It certainly should set CXXFLAGS
>> appropriately, but doesn't. And we've not changed that part of
>> configure.ac <http://configure.ac>. It also happens to be the same
>>
>> as in GMP, which does get the right CXXFLAGS.
>>
>> Fortunately I have to issue the release with a different version of
>> autotools anyway, as the Ubuntu version doesn't support Windows, etc.
>>
>> So perhaps you can check again when I do that.
>>
>> Bill.
>>
>>
>> On 28 March 2014 21:43, leif <not.rea...@online.de
>> <mailto:not.rea...@online.de>> wrote:
>>
>> On 28.03.2014 19:36, Bill Hart wrote:
>>
>> I've added it to the list.
>>
>> I'm puzzled as to how this bug has lasted until now to be
>> reported. It
>> must surely have broken things on a lot of C++ platforms,
>> and it almost
>> certainly has never been right.
>>
>>
>> With MPIR 2.6.0 (and presumably [m]any earlier version[s]) this
>> worked for me (although I usally set CXXFLAGS manually, so
>> wouldn't notice unless I'm explicitly testing or compiling the
>> C++ interface for a non-default ABI):
>>
>> ...
>> checking ABI=64
>> checking whether gcc-4.7.0 is gcc... yes
>> checking compiler gcc-4.7.0 -m64 ... yes
>> checking compiler gcc-4.7.0 -m64 -O2... yes
>> checking compiler gcc-4.7.0 -m64 -O2 -march=btver1... yes
>> checking compiler gcc-4.7.0 -m64 -O2 -march=btver1
>> -mtune=btver1... yes
>> checking for gcc... gcc-4.7.0
>> checking whether the C compiler works... yes
>> checking for C compiler default output file name... a.out
>> checking for suffix of executables...
>> checking whether we are cross compiling... no
>> checking for suffix of object files... o
>> checking whether we are using the GNU C compiler... yes
>> checking whether gcc-4.7.0 accepts -g... yes
>> checking for gcc-4.7.0 option to accept ISO C89... none needed
>> ...
>> checking for gcc... (cached) gcc-4.7.0
>> checking whether we are using the GNU C compiler... (cached) yes
>> checking whether gcc-4.7.0 accepts -g... (cached) yes
>> checking for gcc-4.7.0 option to accept ISO C89... (cached) none
>> needed
>> checking for gcc-4.7.0 option to accept ISO C99... -std=gnu99
>> checking for gcc-4.7.0 -std=gnu99 option to accept ISO Standard
>> C... (cached) -std=gnu99
>> checking how to run the C preprocessor... cpp-4.7.0
>> checking build system compiler gcc-4.7.0 -std=gnu99... yes
>> checking for build system preprocessor... gcc-4.7.0 -std=gnu99 -E
>> checking for build system executable suffix...
>> checking whether build system compiler is ANSI... yes
>> checking for build system compiler math library... -lm
>> checking whether we are using the GNU C++ compiler... yes
>> checking whether g++-4.7.0 accepts -g... yes
>> checking C++ compiler g++-4.7.0 -m64 -O2 -march=btver1
>> -mtune=btver1... yes
>> checking how to run the C++ preprocessor... g++-4.7.0 -E
>> using ABI="64"
>> CC="gcc-4.7.0 -std=gnu99"
>> CFLAGS="-m64 -O2 -march=btver1 -mtune=btver1"
>> CPPFLAGS=""
>> CXX="g++-4.7.0"
>> CXXFLAGS="-m64 -O2 -march=btver1 -mtune=btver1"
>> MPN_PATH=" x86_64/bobcat x86_64 generic"
>> ...
>>
>>
>> -leif
>>
>>
>> On 28 March 2014 18:42, leif <not.rea...@online.de
>> <mailto:not.rea...@online.de>
>> <mailto:not.rea...@online.de <mailto:not.rea...@online.de>>>
>>
>> wrote:
>>
>>
>> On 24.03.2014 17 <tel:24.03.2014%2017>
>> <tel:24.03.2014%2017>:17, Bill Hart wrote:
>>
>> I have now assigned 36 open tickets to the 2.7
>> release. I'm sure
>> more
>> will be added, but at least we now have some
>> measure of how far
>> we are
>> from a release.
>>
>>
>> Just in case that's not yet on the todo list:
>>
>> While --enable-cxx (and 'make check' with that)
>> meanwhile works,
>> apparently the checks for the C++ compiler's
>> capabilities are
>> currently missing, such that CXXFLAGS lack the ABI- and
>> machine-specific flags (-m32/-m64,
>> -march=.../-mtune=...).
>>
>
> --
> () 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 unsubscribe from this group and stop receiving emails from it, send an email
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.
