This is the mail archive of the
mailing list for the libstdc++ project.
Re: Adding configure flag
- From: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- To: Aurelio Remonda <aurelio dot remonda at tallertechnologies dot com>
- Cc: "libstdc++" <libstdc++ at gcc dot gnu dot org>
- Date: Sat, 31 Oct 2015 12:04:09 +0530
- Subject: Re: Adding configure flag
- Authentication-results: sourceware.org; auth=none
- References: <CANLsssspTRnapDeq7c0gcW+X=qbO9=zTxA5G+vZDzv07akiy9Q at mail dot gmail dot com> <CAH6eHdR+8mN3TB_MRN29nLdbP9JtHBofrpZs2eXYbOo6Q1P-9w at mail dot gmail dot com> <CANLssstC9iM7+h_67fKAm4sv0eG=fxSdM2aqGi3ssYVGTHK01g at mail dot gmail dot com> <CAH6eHdTgW_he096gAK4GpWBO7__OXoQBiTEteYaCiOGDbz6BXQ at mail dot gmail dot com> <CANLsssvSvZygh13CN+nT5XgfbM_JciwBvGDo7ZVXpX=gQBMYLQ at mail dot gmail dot com>
On 30/10/2015, Aurelio Remonda wrote:
>>>> Try using autoreconf, to make sure config.h.in is regenerated
>>>> (although I think autoconf should do that anyway).
> I did make autoreconf work but i had to change the autoconf version to 2.69
> configure.ac:3 AC_PREREQ(2.69)
> override.m4:32 [m4_define([_GCC_AUTOCONF_VERSION], [2.69])])
> They were both 2.64 and autoreconf complains about it.
Don't change the required version (any patch doing that will never be accepted).
You need to install the right version of autoconf and ensure your PATH
will cause it to be used before any other version of autoconf you have
>> When libstdc++ is built you should see it print "checking for enabled
>> if" (and you should be able to search for that in the
>> $target/libstdc++-v3/config.log file)
>> And then you should see you macro in
> It works now :)
>>>> Also, I added the following to libstdc++v3's acinclude.m4:
>>>> AC_DEFUN([GLIBCXX_ENABLE_NEW_OPNT_IF], [
>>>> GLIBCXX_ENABLE(new-opnt-if,$1,,[enable if on new_opnt instead of
>>>> if test $enable_new_opnt_if = yes; then
>>>> AC_DEFINE(_GLIBCXX_NEW_OPNT_IF, 1,
>>>> [Define is new_opnt will be used instead of while.])
>>>> AC_MSG_CHECKING([for enabled if])
>>> This message isn't very helpful.
> Im working on the flag name and the messages, is there any rule for
> this? or any personal suggestion?
Try to describe the change to the semantics of the operator, not how
you modified the implementation.
So maybe --disable-retrying-allocation-after-new-handler would be more
descriptive, although that's very verbose.
[Define if new_opnt should not retry allocation after calling
the new handler.])
AC_MSG_CHECKING([whether no-throw operator new should retry
allocation after calling the new handler])