GNU bug report logs -
#10766
CXX gets the value 'CC' on Cygwin, but CC is in fact cc
Previous Next
Reported by: Peter Rosin <peda <at> lysator.liu.se>
Date: Wed, 8 Feb 2012 21:06:01 UTC
Severity: minor
Tags: patch
Done: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10766 in the body.
You can then email your comments to 10766 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-automake <at> gnu.org:
bug#10766; Package
automake.
(Wed, 08 Feb 2012 21:06:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Peter Rosin <peda <at> lysator.liu.se>:
New bug report received and forwarded. Copy sent to
bug-automake <at> gnu.org.
(Wed, 08 Feb 2012 21:06:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi!
The testsuite on master tries to use lesser compilers, but on Cygwin
this causes some failures due to the fact that /usr/bin/cc{.exe} is
also recognized as /usr/bin/CC{.EXE} (due to the filesystem not being
case sensitive), leading to CXX being set to 'CC'.
But then CXX isn't a C++ compiler and some tests go downhill, namely
silent-many-generic.test and suffix3.tap.
Or something, I didn't look all that much at it. Maybe the failure
in silent-many-generic.test is just a variant of the SunStudio CC
case mentioned in the comment?
Cheers,
Peter
[silent-many-generic.log (text/plain, attachment)]
[suffix3.log (text/plain, attachment)]
Information forwarded
to
bug-automake <at> gnu.org:
bug#10766; Package
automake.
(Wed, 08 Feb 2012 21:33:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 10766 <at> debbugs.gnu.org (full text, mbox):
Reference:
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10766>
[CC:ing the bug-autoconf list]
On 02/08/2012 10:04 PM, Peter Rosin wrote:
> Hi!
>
> The testsuite on master tries to use lesser compilers, but on Cygwin
> this causes some failures due to the fact that /usr/bin/cc{.exe} is
> also recognized as /usr/bin/CC{.EXE} (due to the filesystem not being
> case sensitive), leading to CXX being set to 'CC'.
>
That is bad. But this sounds more like an autoconf bug, since AC_PROG_CXX
isn't rejecting the C compiler as it IMHO should. Or am I missing
something?
> But then CXX isn't a C++ compiler and some tests go downhill, namely
> silent-many-generic.test and suffix3.tap.
>
> Or something, I didn't look all that much at it. Maybe the failure
> in silent-many-generic.test is just a variant of the SunStudio CC
> case mentioned in the comment?
>
Or more likely some bug in our custom wrapper script kicking in. But
let's look into this once we have solved the other, more serious issue.
Thanks,
Stefano
Information forwarded
to
bug-automake <at> gnu.org:
bug#10766; Package
automake.
(Wed, 08 Feb 2012 21:41:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 10766 <at> debbugs.gnu.org (full text, mbox):
Stefano Lattarini skrev 2012-02-08 22:31:
> Reference:
> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10766>
>
> [CC:ing the bug-autoconf list]
>
> On 02/08/2012 10:04 PM, Peter Rosin wrote:
>> Hi!
>>
>> The testsuite on master tries to use lesser compilers, but on Cygwin
>> this causes some failures due to the fact that /usr/bin/cc{.exe} is
>> also recognized as /usr/bin/CC{.EXE} (due to the filesystem not being
>> case sensitive), leading to CXX being set to 'CC'.
>>
> That is bad. But this sounds more like an autoconf bug, since AC_PROG_CXX
> isn't rejecting the C compiler as it IMHO should. Or am I missing
> something?
Well, to be fair the Automake usage of AC_PROG_CXX on master is more
than a little bit special in that it overrides the search order and
puts g++ last in the list. This isn't hitting anything real, not
anything big anyway...
Cheers,
Peter
Information forwarded
to
bug-automake <at> gnu.org:
bug#10766; Package
automake.
(Wed, 11 Jul 2012 12:51:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 10766 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 07/09/2012 07:04 PM, Max Horn wrote:
> Hi there,
>
Hi Max.
> I am currently looking into packaging automake 1.12.1 for
> Fink <http://www.finkproject.org/> on Mac OS X 10.7.
> Doing that, several test suite failures popped up, which
> I am now working through to resolve.
>
In the meantime, could you please post the 'test-suite.log' file,
for reference? Thanks.
> The first one is t/silentcxx-gcc.sh failing.
> Note that t/silentcxx.sh incorrectly (!) succeeds.
>
> There are two problems here:
>
> 1) The C++ compiler from Sun Studio is named "CC". This caused
> t/silentcxx.sh to fail, which was fixed with commit ad5d0be02d
> in the autonconf
>
s/autoconf/automake/ I guess.
BTW, the problem you are reporting is similar to the one reported
in bug#10766 by Peter Rosin (which I'm thus CC:ing):
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10766>
> git repository. The same fix also needs to be applied to
> t/silentcxx-gcc.sh.
>
See if the attached patch solves the issue for you. Ideally, it
should also fix bug#10766; Peter, could you give it a try?
> 2) But actually I am happy this was there, because otherwise
> I wouldn't have detected this second, more serious bug: On
> Mac OS X, automake 1.12.1 incorrectly thinks the C++ compiler
> is named CC (when really it should be clang++, c++ or g++).
> This is because (a( OS X by default uses a case in-sensitive
> file system, and so "CC" is equivalent to "cc", and (b) the
> automake 1.12.1 code for some reason duplicate some autoconf
> code for detecting the C++ compiler, but changed this code,
> breaking it.
>
It's not actually broken, it's just that, while Autoconf-generated
configure scripts prefer GCC over other compilers, the Automake
configure script does the other way round, to try to enhance coverage
in its testsuite. Note that this inverted logic is only applied to
the configure of Automake itself, and *not* to those of the packages
using configure (this is very important!).
> To quote automake's configure.ac:
>
> <BEGIN QUOTE>
> # The list of C++ compilers here has been copied, pasted and edited
> # from 'lib/autoconf/c.m4:AC_PROG_CXX' in the Autoconf distribution.
> # Keep it in sync, or better again, find out a way to avoid this code
> # duplication.
> _AM_COMPILER_CAN_FAIL([AC_PROG_CXX(dnl
> [aCC CC FCC KCC RCC xlC_r xlC c++ cxx cc++ gpp g++])],
> [CXX=false; _AM_SKIP_COMP_TESTS([C++])])
> <END QUOTE>
>
> But this is what my version of c.m4 contains:
> <BEGIN QUOTE>
> AC_CHECK_TOOLS(CXX,
> [m4_default([$1],
> [g++ c++ gpp aCC CC cxx cc++ cl.exe FCC KCC RCC xlC_r xlC])],
> g++)
> <END QUOTE>
> i.e. the order of the compilers has been changed, and this causes the breakage above.
>
> I wonder whether this different order of compilers is intentional --
>
Yes, see above.
> and why this is duplicated in automake in the first place?
> The comment in configure.ac just says that the list was duplicated,
> not *why*.
>
Because we need to have the entries of the list sorted in a different
order than the one they are in Autoconf.
> It would be nice if it could be extended to explain just that by somebody
> who knows :).
>
The explanation is already given in the comments above:
# Prefer generic compilers to GNU ones when possible. This will ensure
# more testsuite coverage "in the wild".
# Note that we don't look for the MSVC C/C++ compiler here. This is
# deliberate; for more discussion and rationale, see:
# <http://lists.gnu.org/archive/html/automake-patches/2012-01/msg00130.html>
Thanks,
Stefano
[0001-tests-don-t-use-C-instead-of-C-compiler-on-case-inse.patch (text/x-diff, attachment)]
Information forwarded
to
bug-automake <at> gnu.org:
bug#10766; Package
automake.
(Wed, 11 Jul 2012 21:27:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 10766 <at> debbugs.gnu.org (full text, mbox):
On 2012-07-11 14:44, Stefano Lattarini wrote:
> On 07/09/2012 07:04 PM, Max Horn wrote:
>> Hi there,
>>
> Hi Max.
>
>> I am currently looking into packaging automake 1.12.1 for
>> Fink <http://www.finkproject.org/> on Mac OS X 10.7.
>> Doing that, several test suite failures popped up, which
>> I am now working through to resolve.
>>
> In the meantime, could you please post the 'test-suite.log' file,
> for reference? Thanks.
>
>> The first one is t/silentcxx-gcc.sh failing.
>> Note that t/silentcxx.sh incorrectly (!) succeeds.
>>
>> There are two problems here:
>>
>> 1) The C++ compiler from Sun Studio is named "CC". This caused
>> t/silentcxx.sh to fail, which was fixed with commit ad5d0be02d
>> in the autonconf
>>
> s/autoconf/automake/ I guess.
>
> BTW, the problem you are reporting is similar to the one reported
> in bug#10766 by Peter Rosin (which I'm thus CC:ing):
> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10766>
>
>> git repository. The same fix also needs to be applied to
>> t/silentcxx-gcc.sh.
>>
> See if the attached patch solves the issue for you. Ideally, it
> should also fix bug#10766; Peter, could you give it a try?
Hi Stefano!
I updated for the first time in a long time but stumbled on the
autoconf 2.69 requirement, it's not available as a package for
Cygwin yet. I don't feel like rolling my own autoconf. So, no,
I will not test this one until 2.69 is readily available. Sorry.
So, reading the patch instead, I think the method for querying case
insensitivity seems a bit fragile. /usr/bin/gcc is a symlink on
Cygwin and I could easily imagine someone creating a /usr/bin/GCC
wrapper script. Not that anybody will die or anything, but still...
From the nit-picking department, I would not specifically mention
Cygwin when talking about case insensitivity, I would refer to
Windows as a whole instead (since you can make Cygwin case
sensitive).
BTW, thanks for tackling this!
Cheers,
Peter
Information forwarded
to
bug-automake <at> gnu.org:
bug#10766; Package
automake.
(Thu, 12 Jul 2012 08:58:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 10766 <at> debbugs.gnu.org (full text, mbox):
Hi Peter.
On 07/11/2012 11:21 PM, Peter Rosin wrote:
> On 2012-07-11 14:44, Stefano Lattarini wrote:
>> On 07/09/2012 07:04 PM, Max Horn wrote:
>>
>>> I am currently looking into packaging automake 1.12.1 for
>>> Fink <http://www.finkproject.org/> on Mac OS X 10.7.
>>> Doing that, several test suite failures popped up, which
>>> I am now working through to resolve.
>>>
>> In the meantime, could you please post the 'test-suite.log' file,
>> for reference? Thanks.
>>
>>> The first one is t/silentcxx-gcc.sh failing.
>>> Note that t/silentcxx.sh incorrectly (!) succeeds.
>>>
>>> There are two problems here:
>>>
>>> 1) The C++ compiler from Sun Studio is named "CC". This caused
>>> t/silentcxx.sh to fail, which was fixed with commit ad5d0be02d
>>> in the autonconf
>>>
>> s/autoconf/automake/ I guess.
>>
>> BTW, the problem you are reporting is similar to the one reported
>> in bug#10766 by Peter Rosin (which I'm thus CC:ing):
>> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10766>
>>
>>> git repository. The same fix also needs to be applied to
>>> t/silentcxx-gcc.sh.
>>>
>> See if the attached patch solves the issue for you. Ideally, it
>> should also fix bug#10766; Peter, could you give it a try?
>
> Hi Stefano!
>
> I updated for the first time in a long time but stumbled on the
> autoconf 2.69 requirement,
>
Since that requirement is only needed for bootstrapping, I could send
you a (patched) tarball to test (so that you'll only require an
autoconf >= 2.62). Would that be more acceptable?
> it's not available as a package for
> Cygwin yet. I don't feel like rolling my own autoconf. So, no,
> I will not test this one until 2.69 is readily available. Sorry.
>
> So, reading the patch instead, I think the method for querying case
> insensitivity seems a bit fragile
>
Agreed (albeit it does its dirty work for now). Any suggestion on
how to make it more reliable?
> /usr/bin/gcc is a symlink on
> Cygwin and I could easily imagine someone creating a /usr/bin/GCC
> wrapper script. Not that anybody will die or anything, but still...
>
> From the nit-picking department, I would not specifically mention
> Cygwin when talking about case insensitivity, I would refer to
> Windows as a whole instead (since you can make Cygwin case
> sensitive).
>
OK, will do.
> BTW, thanks for tackling this!
>
> Cheers,
> Peter
Thanks,
Stefano
Information forwarded
to
bug-automake <at> gnu.org:
bug#10766; Package
automake.
(Thu, 12 Jul 2012 14:06:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 10766 <at> debbugs.gnu.org (full text, mbox):
On 2012-07-12 10:51, Stefano Lattarini wrote:
> Hi Peter.
>
> On 07/11/2012 11:21 PM, Peter Rosin wrote:
>> On 2012-07-11 14:44, Stefano Lattarini wrote:
>>> On 07/09/2012 07:04 PM, Max Horn wrote:
>>>
>>>> I am currently looking into packaging automake 1.12.1 for
>>>> Fink <http://www.finkproject.org/> on Mac OS X 10.7.
>>>> Doing that, several test suite failures popped up, which
>>>> I am now working through to resolve.
>>>>
>>> In the meantime, could you please post the 'test-suite.log' file,
>>> for reference? Thanks.
>>>
>>>> The first one is t/silentcxx-gcc.sh failing.
>>>> Note that t/silentcxx.sh incorrectly (!) succeeds.
>>>>
>>>> There are two problems here:
>>>>
>>>> 1) The C++ compiler from Sun Studio is named "CC". This caused
>>>> t/silentcxx.sh to fail, which was fixed with commit ad5d0be02d
>>>> in the autonconf
>>>>
>>> s/autoconf/automake/ I guess.
>>>
>>> BTW, the problem you are reporting is similar to the one reported
>>> in bug#10766 by Peter Rosin (which I'm thus CC:ing):
>>> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10766>
>>>
>>>> git repository. The same fix also needs to be applied to
>>>> t/silentcxx-gcc.sh.
>>>>
>>> See if the attached patch solves the issue for you. Ideally, it
>>> should also fix bug#10766; Peter, could you give it a try?
>>
>> Hi Stefano!
>>
>> I updated for the first time in a long time but stumbled on the
>> autoconf 2.69 requirement,
>>
> Since that requirement is only needed for bootstrapping, I could send
> you a (patched) tarball to test (so that you'll only require an
> autoconf >= 2.62). Would that be more acceptable?
Shoot!
>> it's not available as a package for
>> Cygwin yet. I don't feel like rolling my own autoconf. So, no,
>> I will not test this one until 2.69 is readily available. Sorry.
>>
>> So, reading the patch instead, I think the method for querying case
>> insensitivity seems a bit fragile
>>
> Agreed (albeit it does its dirty work for now). Any suggestion on
> how to make it more reliable?
Is test /usr/bin/CC -ef /usr/bin/cc portable enough? Does it work at
all? Just an idea...
Cheers,
Peter
Information forwarded
to
bug-automake <at> gnu.org:
bug#10766; Package
automake.
(Thu, 12 Jul 2012 14:44:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 10766 <at> debbugs.gnu.org (full text, mbox):
On 07/12/2012 04:00 PM, Peter Rosin wrote:
>
> Stefano Lattarini wrote:
>>
>> Since that requirement is only needed for bootstrapping, I could send
>> you a (patched) tarball to test (so that you'll only require an
>> autoconf >= 2.62). Would that be more acceptable?
>
> Shoot!
>
Sent in private.
>>> So, reading the patch instead, I think the method for querying case
>>> insensitivity seems a bit fragile
>>>
>> Agreed (albeit it does its dirty work for now). Any suggestion on
>> how to make it more reliable?
>
> Is test /usr/bin/CC -ef /usr/bin/cc portable enough?
>
I have no idea ... it seems to work on Cygwin 1.5 though.
Anyway, I think that testing for "test /bin/RMDIR -ef /bin/rmdir" might
even be more portable. That's what I'll do if there is no further
objection (and I'll sent you an updated tarball to test, before pushing
out the patch).
> Does it work at all? Just an idea...
>
> Cheers,
> Peter
Regards,
Stefano
Information forwarded
to
bug-automake <at> gnu.org:
bug#10766; Package
automake.
(Thu, 12 Jul 2012 15:55:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 10766 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 07/12/2012 08:37 AM, Stefano Lattarini wrote:
>>> Agreed (albeit it does its dirty work for now). Any suggestion on
>>> how to make it more reliable?
>>
>> Is test /usr/bin/CC -ef /usr/bin/cc portable enough?
>>
> I have no idea ... it seems to work on Cygwin 1.5 though.
In general, 'test a -ef b' is not portable - it is not required by POSIX
2008 (although it has been proposed for a future version of POSIX). But
on Cygwin, /bin/sh happens to support it. If you can guarantee that you
are already on cygwin before using -ef, then this would work; or maybe
if you pre-filter with 'test . -ef .' to ensure that -ef is understood,
before then trying -ef to check for case insensitivity.
Other than that, the only supported method in existing POSIX for
checking for equal files is by parsing 'ls -i' output; but I don't know
if 'ls -i' is portable to ancient hosts.
--
Eric Blake eblake <at> redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-automake <at> gnu.org:
bug#10766; Package
automake.
(Thu, 12 Jul 2012 16:30:03 GMT)
Full text and
rfc822 format available.
Message #32 received at 10766 <at> debbugs.gnu.org (full text, mbox):
Hi Eric.
On 07/12/2012 05:48 PM, Eric Blake wrote:
> On 07/12/2012 08:37 AM, Stefano Lattarini wrote:
>
>>>> Agreed (albeit it does its dirty work for now). Any suggestion on
>>>> how to make it more reliable?
>>>
>>> Is test /usr/bin/CC -ef /usr/bin/cc portable enough?
>>>
>> I have no idea ... it seems to work on Cygwin 1.5 though.
>
> In general, 'test a -ef b' is not portable - it is not required by POSIX
> 2008 (although it has been proposed for a future version of POSIX). But
> on Cygwin, /bin/sh happens to support it. If you can guarantee that you
> are already on cygwin before using -ef, then this would work; or maybe
> if you pre-filter with 'test . -ef .' to ensure that -ef is understood,
> before then trying -ef to check for case insensitivity.
>
> Other than that, the only supported method in existing POSIX for
> checking for equal files is by parsing 'ls -i' output; but I don't know
> if 'ls -i' is portable to ancient hosts.
>
I was fearing this would have got quickly complex and messy ...
So I think I'll stick to my dumber and safer "test -f /bin/RMDIR" as a
way to detect case-insensible filesystems.
Thanks,
Stefano
Information forwarded
to
bug-automake <at> gnu.org:
bug#10766; Package
automake.
(Thu, 12 Jul 2012 17:12:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 10766 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 07/12/2012 10:23 AM, Stefano Lattarini wrote:
>> Other than that, the only supported method in existing POSIX for
>> checking for equal files is by parsing 'ls -i' output; but I don't know
>> if 'ls -i' is portable to ancient hosts.
>>
> I was fearing this would have got quickly complex and messy ...
>
> So I think I'll stick to my dumber and safer "test -f /bin/RMDIR" as a
> way to detect case-insensible filesystems.
Assuming it was intentional, I like your re-wording of
"case-insensible", as an apt description of the pain case-insensitive
systems cause on portability :)
That said, /bin/RMDIR is probably completely portable, but seems like it
would be reliable in practice. POSIX doesn't reqiure /bin/rmdir to
exist (about the only files that you can guarantee with POSIX are /tmp,
/dev/null, /dev/tty, and /dev/console). Since /dev/ generally doesn't
exist on mingw, that almost limits you to just testing if /tmp and /TMP
are the same directory to detect a case-insensitive system. But I don't
know of any systems that lack /bin/rmdir on a default installation, nor
do I suspect many users intentionally create /bin/RMDIR (or even better,
/bIn/rMdIr), so using it as a hueristic seems okay for a first cut at
the problem at hand. Or, maybe you should just create a file in /tmp
under one spelling and check existence of the file by another spelling.
--
Eric Blake eblake <at> redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-automake <at> gnu.org:
bug#10766; Package
automake.
(Thu, 12 Jul 2012 17:18:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 10766 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 07/12/2012 11:06 AM, Eric Blake wrote:
Minor correction:
>
> That said, /bin/RMDIR is probably completely portable, but seems like it
^ not
> would be reliable in practice.
--
Eric Blake eblake <at> redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-automake <at> gnu.org:
bug#10766; Package
automake.
(Thu, 12 Jul 2012 18:46:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 10766 <at> debbugs.gnu.org (full text, mbox):
On 2012-07-12 17:48, Eric Blake wrote:
> On 07/12/2012 08:37 AM, Stefano Lattarini wrote:
>
>>>> Agreed (albeit it does its dirty work for now). Any suggestion on
>>>> how to make it more reliable?
>>>
>>> Is test /usr/bin/CC -ef /usr/bin/cc portable enough?
>>>
>> I have no idea ... it seems to work on Cygwin 1.5 though.
>
> In general, 'test a -ef b' is not portable - it is not required by POSIX
> 2008 (although it has been proposed for a future version of POSIX). But
> on Cygwin, /bin/sh happens to support it. If you can guarantee that you
> are already on cygwin before using -ef, then this would work; or maybe
> if you pre-filter with 'test . -ef .' to ensure that -ef is understood,
> before then trying -ef to check for case insensitivity.
> Other than that, the only supported method in existing POSIX for
> checking for equal files is by parsing 'ls -i' output; but I don't know
> if 'ls -i' is portable to ancient hosts.
if test -z `ls -i /usr/bin/cc /usr/bin/CC | sed 'N; /^\( *[^ ]* \).*\n\1/!s/.*//; s/..*/same/'`; then
echo "sensible aka sensitive"
fi
But that of course relies on a working ls -i, as well as its formatting...
Cheers,
Peter
Information forwarded
to
bug-automake <at> gnu.org:
bug#10766; Package
automake.
(Thu, 12 Jul 2012 18:49:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 10766 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 07/12/2012 07:06 PM, Eric Blake wrote:
> On 07/12/2012 10:23 AM, Stefano Lattarini wrote:
>
>>> Other than that, the only supported method in existing POSIX for
>>> checking for equal files is by parsing 'ls -i' output; but I don't know
>>> if 'ls -i' is portable to ancient hosts.
>>>
>> I was fearing this would have got quickly complex and messy ...
>>
>> So I think I'll stick to my dumber and safer "test -f /bin/RMDIR" as a
>> way to detect case-insensible filesystems.
>
> Assuming it was intentional, I like your re-wording of
> "case-insensible", as an apt description of the pain case-insensitive
> systems cause on portability :)
>
Sorry, no deliberate pun, just a lexical error. But I can keep it if
you like it :-)
> That said, /bin/RMDIR is probably not completely portable, but seems
> like it would be reliable in practice.
>
That is my impression. And anyway, there aren't too many people running
the Automake testsuite on Mac OS X or Cygwin, so if the patch manages to
fix Peter's and Max's issue, it is good enough for me (at least until
somebody else reports a similar issue). Finally, consider that the
result of a botch-up of this new configure check would simple be one or
two spurious testsuite failures -- so just a small annoyance, nothing to
really worry about.
> POSIX doesn't reqiure /bin/rmdir to
> exist (about the only files that you can guarantee with POSIX are /tmp,
> /dev/null, /dev/tty, and /dev/console). Since /dev/ generally doesn't
> exist on mingw, that almost limits you to just testing if /tmp and /TMP
> are the same directory to detect a case-insensitive system. But I don't
> know of any systems that lack /bin/rmdir on a default installation, nor
> do I suspect many users intentionally create /bin/RMDIR (or even better,
> /bIn/rMdIr),
>
Good idea for an improved test; I've implemented it in my patch.
> so using it as a hueristic seems okay for a first cut at
> the problem at hand. Or, maybe you should just create a file in /tmp
> under one spelling and check existence of the file by another spelling.
>
In the light of our discussion, attached is the patch I'd finally like
to push. WDYT?
Thanks,
Stefano
[0001-tests-don-t-use-C-instead-of-C-compiler-on-case-inse.patch (text/x-diff, attachment)]
Information forwarded
to
bug-automake <at> gnu.org:
bug#10766; Package
automake.
(Thu, 12 Jul 2012 18:53:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 10766 <at> debbugs.gnu.org (full text, mbox):
On 2012-07-12 16:37, Stefano Lattarini wrote:
> On 07/12/2012 04:00 PM, Peter Rosin wrote:
>>
>> Stefano Lattarini wrote:
>>>
>>> Since that requirement is only needed for bootstrapping, I could send
>>> you a (patched) tarball to test (so that you'll only require an
>>> autoconf >= 2.62). Would that be more acceptable?
>>
>> Shoot!
>>
> Sent in private.
From a fairly recent Cygwin (this May perhaps?)
...
PASS: t/silent-many-generic.sh
...
PASS: t/suffix3.tap 1 - aclocal
PASS: t/suffix3.tap 2 - automake
PASS: t/suffix3.tap 3 - intermediate files not mentioned
PASS: t/suffix3.tap 4 - final object file figured out
PASS: t/suffix3.tap 5 - autoconf
PASS: t/suffix3.tap 6 - configure
PASS: t/suffix3.tap 7 - make all
PASS: t/suffix3.tap 8 - make distcheck
PASS: t/suffix3.tap 9 - make distdir
PASS: t/suffix3.tap 10 - intermediate file not distributed
...
============================================================================
Testsuite summary for GNU Automake 1.12.2a
============================================================================
# TOTAL: 2906
# PASS: 2782
# SKIP: 83
# XFAIL: 41
# FAIL: 0
# XPASS: 0
# ERROR: 0
============================================================================
Works, I'd say.
Cheers,
Peter
Information forwarded
to
bug-automake <at> gnu.org:
bug#10766; Package
automake.
(Thu, 12 Jul 2012 19:42:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 10766 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 07/12/2012 12:42 PM, Stefano Lattarini wrote:
>
> In the light of our discussion, attached is the patch I'd finally like
> to push. WDYT?
Looks fine to me (although I have not actually tested it).
--
Eric Blake eblake <at> redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-automake <at> gnu.org:
bug#10766; Package
automake.
(Fri, 13 Jul 2012 12:55:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 10766 <at> debbugs.gnu.org (full text, mbox):
On 07/12/2012 09:36 PM, Eric Blake wrote:
> On 07/12/2012 12:42 PM, Stefano Lattarini wrote:
>
>>
>> In the light of our discussion, attached is the patch I'd finally like
>> to push. WDYT?
>
> Looks fine to me (although I have not actually tested it).
>
Pushed now.
Thanks,
Stefano
Added tag(s) patch.
Request was from
Stefano Lattarini <stefano.lattarini <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Fri, 13 Jul 2012 12:57:02 GMT)
Full text and
rfc822 format available.
Severity set to 'minor' from 'normal'
Request was from
Stefano Lattarini <stefano.lattarini <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Fri, 13 Jul 2012 12:57:02 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
10766 <at> debbugs.gnu.org and Peter Rosin <peda <at> lysator.liu.se>
Request was from
Stefano Lattarini <stefano.lattarini <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Fri, 13 Jul 2012 12:57:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sat, 11 Aug 2012 11:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 13 years and 9 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.