Auto-generated configure script on OS X contains incorrect command that yields unexpected end of file error

[Nate Michael]

This "bug" has been confirmed on two separate OS X systems. After checking out the latest trunk and running "autoreconf -i", the auto-generated configure script contains a line that should be two lines. The script generates (l. 14859 on my systems):

  boost_cv_lib_version=`cat conftest.i`
firm -f conftest*

which should be

  boost_cv_lib_version=`cat conftest.i`
fi
rm -f conftest*

Making this change fixes the script and compilation continues as expected. After which point, the trunk works as expected. It is not clear if this is an issue with the autoconf settings in peekabot or a bug resulting from some other component. Relevant versions follow:

autoconf, autoreconf: 2.64
make: 3.81
aclocal: 1.11
libtoolize: 2.2.6

[Staffan Gimåker (gimaker)]

Do you know when the bug appeared?

Have you updated any of the tools in the autotools toolchain recently
(m4, autoconf, etc)?

It *looks* like it is the boost.m4 (m4/boost.m4) script that's causing
the problem, but it hasn't been touched since March, and the
configure.ac file hasn't been touched since July first.

I updated to the latest version of boost.m4 in trunk -- see if that
makes a difference.

If not, something that might give us more information is to branch an
older revision, known to work, and see if you can still reproduce the
problem there.

On Thu, 2009-08-20 at 12:28 +0000, Nate Michael wrote:
> Public bug reported:
>
> This "bug" has been confirmed on two separate OS X systems. After
> checking out the latest trunk and running "autoreconf -i", the auto-
> generated configure script contains a line that should be two lines. The
> script generates (l. 14859 on my systems):
>
> boost_cv_lib_version=`cat conftest.i`
> firm -f conftest*
>
> which should be
>
> boost_cv_lib_version=`cat conftest.i`
> fi
> rm -f conftest*
>
> Making this change fixes the script and compilation continues as
> expected. After which point, the trunk works as expected. It is not
> clear if this is an issue with the autoconf settings in peekabot or a
> bug resulting from some other component. Relevant versions follow:
>
> autoconf, autoreconf: 2.64
> make: 3.81
> aclocal: 1.11
> libtoolize: 2.2.6
>
> ** Affects: peekabot
> Importance: Undecided
> Status: New
>
> ** Summary changed:
>
> - Auto-generated configure script on OS X contains incorrect command that yields unexpected of file error
> + Auto-generated configure script on OS X contains incorrect command that yields unexpected end of file error
>

[Nate Michael (nate-michael)]

I branched 0.6.x and found the same problem. Downgrading autoconf from
2.64.0 to 2.63.0 is the fix. Using 2.63.0, the trunk configures
without issue.

On Aug 20, 2009, at 9:35 AM, Staffan Gimåker wrote:

> Do you know when the bug appeared?
>
> Have you updated any of the tools in the autotools toolchain recently
> (m4, autoconf, etc)?
>
> It *looks* like it is the boost.m4 (m4/boost.m4) script that's causing
> the problem, but it hasn't been touched since March, and the
> configure.ac file hasn't been touched since July first.
>
> I updated to the latest version of boost.m4 in trunk -- see if that
> makes a difference.
>
> If not, something that might give us more information is to branch an
> older revision, known to work, and see if you can still reproduce the
> problem there.
>
> On Thu, 2009-08-20 at 12:28 +0000, Nate Michael wrote:
>> Public bug reported:
>>
>> This "bug" has been confirmed on two separate OS X systems. After
>> checking out the latest trunk and running "autoreconf -i", the auto-
>> generated configure script contains a line that should be two
>> lines. The
>> script generates (l. 14859 on my systems):
>>
>> boost_cv_lib_version=`cat conftest.i`
>> firm -f conftest*
>>
>> which should be
>>
>> boost_cv_lib_version=`cat conftest.i`
>> fi
>> rm -f conftest*
>>
>> Making this change fixes the script and compilation continues as
>> expected. After which point, the trunk works as expected. It is not
>> clear if this is an issue with the autoconf settings in peekabot or a
>> bug resulting from some other component. Relevant versions follow:
>>
>> autoconf, autoreconf: 2.64
>> make: 3.81
>> aclocal: 1.11
>> libtoolize: 2.2.6
>>
>> ** Affects: peekabot
>> Importance: Undecided
>> Status: New
>>
>> ** Summary changed:
>>
>> - Auto-generated configure script on OS X contains incorrect
>> command that yields unexpected of file error
>> + Auto-generated configure script on OS X contains incorrect
>> command that yields unexpected end of file error
>>
>
> --
> Auto-generated configure script on OS X contains incorrect command
> that yields unexpected end of file error
> https://bugs.launchpad.net/bugs/416399
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in peekabot: New
>
> Bug description:
> This "bug" has been confirmed on two separate OS X systems. After
> checking out the latest trunk and running "autoreconf -i", the auto-
> generated configure script contains a line that should be two lines.
> The script generates (l. 14859 on my systems):
>
> boost_cv_lib_version=`cat conftest.i`
> firm -f conftest*
>
> which should be
>
> boost_cv_lib_version=`cat conftest.i`
> fi
> rm -f conftest*
>
> Making this change fixes the script and compilation continues as
> expected. After which point, the trunk works as expected. It is not
> clear if this is an issue with the autoconf settings in peekabot or
> a bug resulting from some other component. Relevant versions follow:
>
> autoconf, autoreconf: 2.64
> make: 3.81
> aclocal: 1.11
> libtoolize: 2.2.6

[Nate Michael (nate-michael)]

The same problem occurs on Debian Linux with version 2.64 of autoconf.

[Staffan Gimåker (gimaker)]

It looks like this is an upstream bug, either in autoconf or in
boost.m4. I'm investigating where to put the blame... :)

Which version of m4 do you use?

On Thu, 2009-08-20 at 15:15 +0000, Nate Michael wrote:
> The same problem occurs on Debian Linux with version 2.64 of autoconf.
>

[Nate Michael (nate-michael)]

> Which version of m4 do you use?

On OS X: 1.4.6
On Debian Linux: 1.4.13

>
> On Thu, 2009-08-20 at 15:15 +0000, Nate Michael wrote:
>> The same problem occurs on Debian Linux with version 2.64 of
>> autoconf.
>>
>
> --
> Auto-generated configure script on OS X contains incorrect command
> that yields unexpected end of file error
> https://bugs.launchpad.net/bugs/416399
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in peekabot: New
>
> Bug description:
> This "bug" has been confirmed on two separate OS X systems. After
> checking out the latest trunk and running "autoreconf -i", the auto-
> generated configure script contains a line that should be two lines.
> The script generates (l. 14859 on my systems):
>
> boost_cv_lib_version=`cat conftest.i`
> firm -f conftest*
>
> which should be
>
> boost_cv_lib_version=`cat conftest.i`
> fi
> rm -f conftest*
>
> Making this change fixes the script and compilation continues as
> expected. After which point, the trunk works as expected. It is not
> clear if this is an issue with the autoconf settings in peekabot or
> a bug resulting from some other component. Relevant versions follow:
>
> autoconf, autoreconf: 2.64
> make: 3.81
> aclocal: 1.11
> libtoolize: 2.2.6

[Staffan Gimåker (gimaker)]

A small update on this matter, in summary:
I contacted the upstream for both autoconf and boost.m4, and the autoconf guys basically said "user error" (on the behalf of the boost.m4 author), that thread is here: http://<email address hidden>/msg02375.html

I took a stab at fixing it myself, but to no avail. I also (finally) got in touch with the author of the boost.m4, which said he'd try to take a look at it when he gets some free time. In the meantime, 2.64 is a no-no...

[Eric Julien (eric-julien)]

Adding a ; between [$4] and dnl (after the AS_IF macro) in _BOOST_SED_CPP does fix the issue.

[Eric Julien (eric-julien)]

Small clarification: the line becomes [$4]);dnl (line 62 in version I have)

Sorry, I forgot the ")".

[Staffan Gimåker (gimaker)]

Thanks for pinpointing the location of the error Eric, I've committed a fix as well as sent it upstream (adding a ; breaks older autoconf, removing the dnl does the trick however).