ns out there is an obvious correct patch for this bug: all the *other*
AC_PROG_compiler_C_O macros do an AC_LANG_PUSH/POP to the appropriate
language, so AC_PROG_CC_C_O should too. Committed as
e544a323845c1bcc33729927137b09c681073ebd.
___
Update of sr#110987 (group autoconf):
Priority: 5 - Unprioritized => 2 - Eventually
___
Follow-up Comment #1:
Low priority as this affects only unusual configure.ac layout, and as all of
the AC_PROG_*_C_O
URL:
<https://savannah.gnu.org/support/?110987>
Summary: AC_PROG_CC_C_O + AC_LANG([C++]) combines C-specific
compiler options with C++ source
Group: Autoconf
Submitter: zackw
Submitted: Thu 21 Dec 2023 07:14:49
(in which case
I'll avoid the duplicated efforts)?
I wasn't planning on doing that, so please go ahead.
Here is my attempt. OK to go in Autoconf 2.70?
Close, but I have some ideas for improvements.
+- AC_PROG_CC_C_O implements saner semantics if the new witness macro
On 01/15/2013 04:16 AM, Paul Eggert wrote:
On 01/14/2013 11:56 AM, Stefano Lattarini wrote:
1. It checks that *both* 'cc' and '$CC' (which might easily be 'gcc'
or 'clang') supports -c -o together. Why? If the user has a
broken base vendor compiler, but has installed a better one
On 01/16/13 04:46, Stefano Lattarini wrote:
Makes sense. Should I try to implement something along these lines (might
take a few days), or are you planning to do that yourself (in which case
I'll avoid the duplicated efforts)?
I wasn't planning on doing that, so please go ahead.
On 01/16/2013 10:48 AM, Paul Eggert wrote:
On 01/16/13 04:46, Stefano Lattarini wrote:
Makes sense. Should I try to implement something along these lines (might
take a few days), or are you planning to do that yourself (in which case
I'll avoid the duplicated efforts)?
I wasn't planning on
might actually be not only the simplest, but also the sanest one.
That said, I believe we'd still have to fix AM_PROG_CC_C_O not to rely on
the broken AC_PROG_CC_C_O semantics of checking *both* '$CC' and 'cc' for
-c -o support. But that is quite orthogonal to your patch, and material
On 01/14/13 02:24, Stefano Lattarini wrote:
Autoconfers, WDYT?
I think I'm lost. http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378
is a long thread.
guess Nick too) have with the current
AC_PROG_CC_C_O semantics:
1. It checks that *both* 'cc' and '$CC' (which might easily be 'gcc'
or 'clang') supports -c -o together. Why? If the user has a
broken base vendor compiler, but has installed a better one (say
GCC), why should he still
On 01/14/2013 11:56 AM, Stefano Lattarini wrote:
1. It checks that *both* 'cc' and '$CC' (which might easily be 'gcc'
or 'clang') supports -c -o together. Why? If the user has a
broken base vendor compiler, but has installed a better one (say
GCC), why should he still be
If the current language is not C, the AC_PROG_CC_C_O macro will never-
theless directly invoke the C compiler, but the file extensions used by
the tests will be appropriate for the current language setting rather
than for the C compiler.
In this case, the test may produce a false negative result
* Bruce Korb wrote on Mon, Apr 30, 2007 at 12:04:53AM CEST:
The index and search of the docs only yields this:
`AM_PROG_CC_C_O'
This is like `AC_PROG_CC_C_O', but it generates its results in the
manner required by automake. You must use this instead of
`AC_PROG_CC_C_O' when
Ralf Wildenhues [EMAIL PROTECTED] writes:
* Bruce Korb wrote on Mon, Apr 30, 2007 at 12:04:53AM CEST:
The index and search of the docs only yields this:
`AM_PROG_CC_C_O'
This is like `AC_PROG_CC_C_O', but it generates its results in the
manner required by automake. You must use
The index and search of the docs only yields this:
`AM_PROG_CC_C_O'
This is like `AC_PROG_CC_C_O', but it generates its results in the
manner required by automake. You must use this instead of
`AC_PROG_CC_C_O' when you need this functionality, that is, when
using per-target
/autoconf/c.m4 (AC_PROG_CC_C_O): Remove the comment about 8+3
filesystems.
Index: lib/autoconf/c.m4
===
RCS file: /cvsroot/autoconf/autoconf/lib/autoconf/c.m4,v
retrieving revision 1.207
diff -u -r1.207 c.m4
--- lib/autoconf
conftest.$ac_objext instead of conftest2.$ac_objext, ./configure
would still think that $CC handles -c -o correctly.
I committed the patch attached to this mail.
Have a nice day,
Stepan Kasal
2005-10-27 Stepan Kasal [EMAIL PROTECTED]
* lib/autoconf/c.m4 (AC_PROG_CC_C_O): conftst2
On Thu, Oct 27, 2005 at 08:16:05AM +0200, Stepan Kasal wrote:
-ac_try='$CC -c conftest.$ac_ext -o conftst2.$ac_objext AS_MESSAGE_LOG_FD'
-rm -f conftst2.*
+# (On an 8+3 filesystem, conftest2.* is not distinguishable from conftest.*,
+# thus the test always passes; but if the ./configure
Noah Misch [EMAIL PROTECTED] writes:
On Thu, Oct 27, 2005 at 08:16:05AM +0200, Stepan Kasal wrote:
-ac_try='$CC -c conftest.$ac_ext -o conftst2.$ac_objext AS_MESSAGE_LOG_FD'
-rm -f conftst2.*
+# (On an 8+3 filesystem, conftest2.* is not distinguishable from conftest.*,
+# thus the test
Keith MARSHALL wrote:
Regarding DJGPP, is the modern version still bound by 8.3 file name
constraints? I understood that it had been upgraded to work with
Win2K, and therefore would have expected LFN support to have been
included.
As far as I recall, there was a MS DOS release somewhere
Cc: autoconf@gnu.org,
[EMAIL PROTECTED],
autoconf-patches@gnu.org
From: Keith MARSHALL [EMAIL PROTECTED]
Date: Tue, 25 Oct 2005 16:29:13 +0100
Regarding DJGPP, is the modern version still bound by 8.3 file name
constraints?
When DJGPP programs run on Windows 95 and later,
Date: Tue, 25 Oct 2005 10:25:25 -0500 (CDT)
From: Bob Friesenhahn [EMAIL PROTECTED]
cc: autoconf@gnu.org
Perhaps MS-DOS will never die, but the requirement to actually build
software under MS-DOS is gone because MS-DOS cross-development tools
are available which run on more capable
Cc: autoconf@gnu.org,
[EMAIL PROTECTED],
autoconf-patches@gnu.org
From: Keith MARSHALL [EMAIL PROTECTED]
Date: Tue, 25 Oct 2005 16:29:13 +0100
Regarding DJGPP, is the modern version still bound by 8.3 file name
constraints?
When DJGPP programs run on Windows 95 and later,
Hello Eli,
On Tue, Oct 25, 2005 at 03:47:58PM +0200, Eli Zaretskii wrote:
From the Autoconf archives of this thread, I understand that the issue
was with conftest2.c vs conftst2.c.
the problem is this: ./configure runs
$CC -c -o conftst2.$ac_objext conftest.c
and then checks whether
Date: Wed, 26 Oct 2005 08:17:52 +0200
From: Stepan Kasal [EMAIL PROTECTED]
Cc: autoconf@gnu.org, autoconf-patches@gnu.org
the problem is this: ./configure runs
$CC -c -o conftst2.$ac_objext conftest.c
and then checks whether the compiler created conftst2.$ac_objext or
to drop the 8.3 support from
generated ./configure.
Have a nice day,
Stepan Kasal
2005-10-25 Stepan Kasal [EMAIL PROTECTED]
* lib/autoconf/c.m4 (AC_PROG_CC_C_O): rm -f conftst2.*, not only
conftst2.$ac_objext.
* lib/autoconf/fortran.m4 (_AC_PROG_FC_C_O): Likewise
Stepan Kasal wrote:
3) There is an MSYS build of bash. Though MinGW/MSYS is not ready
to run Autoconf, you can use it to unpack a tarball and run ./configure
there.
I don't know where you get this idea from. I have been using Autoconf
2.59 in the MSYS environment for at least nine months
Date: Tue, 25 Oct 2005 14:26:23 +0200
From: Stepan Kasal [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Microsoft added long file name support in Win95 -- the first of the 32-bit
Windoze releases. The requirement to support 8.3 file names disappeared
with the demise of MS-DOS, around the same
As for the argument that ``The requirement to support 8.3 file names
disappeared with the demise of MS-DOS'' when Windows 95 was
introduced, it is IMNSHO is ridiculous.
Ok. I accept that `disappeared' and `demise' were probably poorly
chosen words -- what I really meant was `diminished' and
to drop the 8.3 support from
generated ./configure.
Have a nice day,
Stepan Kasal
2005-10-25 Stepan Kasal [EMAIL PROTECTED]
* lib/autoconf/c.m4 (AC_PROG_CC_C_O): rm -f conftst2.*, not only
conftst2.$ac_objext.
* lib/autoconf/fortran.m4 (_AC_PROG_FC_C_O): Likewise
Hello,
[ ccing Eli, a DOS expert ]
On Tue, Oct 25, 2005 at 12:47:10PM +0100, Keith MARSHALL wrote:
Stepan Kasal wrote:
3) There is an MSYS build of bash. Though MinGW/MSYS is not ready
to run Autoconf, you can use it to unpack a tarball and run ./configure
there.
I don't know where
On Tue, 25 Oct 2005, Stepan Kasal wrote:
3) There is an MSYS build of bash. Though MinGW/MSYS is not ready
to run Autoconf, you can use it to unpack a tarball and run ./configure
there.
Is it possible that ./configure will then run in the 8.3 environment?
I don't know and that is why I am
On Tue, 25 Oct 2005, Eli Zaretskii wrote:
As for the argument that ``The requirement to support 8.3 file names
disappeared with the demise of MS-DOS'' when Windows 95 was
introduced, it is IMNSHO is ridiculous. DOS didn't disappear when
Windows 95 was unveiled, it is still out there and is
Dan Manthey wrote:
My Windows environment doesn't have 8.3 issues, so I can't guess
whether there's any need to support 8.3 filenames under MSYS.
There isn't. MSYS requires 32-bit Windoze; *all* 32-bit Windoze
implementations support long file names.
Regards,
Keith.
Date: Tue, 25 Oct 2005 14:26:23 +0200
From: Stepan Kasal [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Microsoft added long file name support in Win95 -- the first of the 32-bit
Windoze releases. The requirement to support 8.3 file names disappeared
with the demise of MS-DOS, around the same
As for the argument that ``The requirement to support 8.3 file names
disappeared with the demise of MS-DOS'' when Windows 95 was
introduced, it is IMNSHO is ridiculous.
Ok. I accept that `disappeared' and `demise' were probably poorly
chosen words -- what I really meant was `diminished' and
Keith MARSHALL wrote:
Regarding DJGPP, is the modern version still bound by 8.3 file name
constraints? I understood that it had been upgraded to work with
Win2K, and therefore would have expected LFN support to have been
included.
As far as I recall, there was a MS DOS release somewhere
Stepan Kasal [EMAIL PROTECTED] writes:
A question: is there any reason to use rm -f conftst2.*
instead of rm -f conftst2.$ac_objext
Is there any C, Fortran, or F77 compiler which could create other
conftst2.* files if it receives -o conftst2.$ac_objext ?
Quite possibly, yes.
But why not
Hi folks,
Stepan Kasal wrote:
the patch attached to this mail (relative to current autoconf CVS)
should fix it.
OK to commit?
It seems that this patch is still not in CVS. And since the
suggested workaround doesn't workaround I am stuck :-(.
Any help would be highly appreciated.
/autoconf/c.m4 (AC_PROG_CC_C_O): Use conftst2.o instead of
conftest.o, to see whether the compiler really obeys; rm the object
file before and after the test and register it with ac_clean_files.
* lib/autoconf/fortran.m4 (_AC_PROG_FC_C_O): Likewise.
Index: lib/autoconf/c.m4
Hi Stepan,
Stepan Kasal wrote:
Hello Harald,
On Mon, Oct 24, 2005 at 10:35:25AM +0200, Harald Dunkel wrote:
It seems that this patch is still not in CVS. And since the
suggested workaround doesn't workaround I am stuck :-(.
I apologize. I have committed a patch which should fix your
Hi Harald,
* Harald Dunkel wrote on Mon, Oct 24, 2005 at 02:19:53PM CEST:
I tried the previous patch you had sent some time ago (the
version with 'conf$[$]'). But this didn't work for Bill's
cl.exe. The generated Makefile still uses -c and -o on the same
command line. I had verified that
Hi folks,
Ralf Wildenhues wrote:
Hi Harald,
* Harald Dunkel wrote on Mon, Oct 24, 2005 at 02:19:53PM CEST:
I tried the previous patch you had sent some time ago (the
version with 'conf$[$]'). But this didn't work for Bill's
cl.exe. The generated Makefile still uses -c and -o on the same
Hello,
[ let's move to automake@gnu.org ]
On Mon, Oct 24, 2005 at 04:20:44PM +0200, Harald Dunkel wrote:
I think I found the problem. The compile script says at the
end
:
if test -f $cofile; then
mv $cofile $ofile
elif test -f ${cofile}bj; then
mv
Stepan Kasal wrote:
I think that the parametr to compile should look like
some/path/main.c
which becomes cfile, and then cofile is assigned as...
Just guessing, but with cl.exe being Bill's C compiler, it
probably doesn't understand `some/path/main.c' as a path name;
(it will
Stepan Kasal [EMAIL PROTECTED] writes:
A question: is there any reason to use rm -f conftst2.*
instead of rm -f conftst2.$ac_objext
Is there any C, Fortran, or F77 compiler which could create other
conftst2.* files if it receives -o conftst2.$ac_objext ?
Quite possibly, yes.
But why not
Hello,
On Mon, Jul 04, 2005 at 11:52:38AM -0700, Paul Eggert wrote:
rm -f -r conftest* confdefs* conf$[$]* $ac_clean_files
How about if you simply remove conf[0-9]* instead? Those file names
are all reserved by Autoconf anyway. And it's more consistent to
always remove all of them,
Stepan Kasal [EMAIL PROTECTED] writes:
But when we got that far, is there any reason why Autoconf tests should
use conf$$*? Isn't conf2.obj or conftest2.obj cleaner?
You could talk me into that, yes, though it's a more global change.
___
Autoconf
Hi,
On Fri, Jul 01, 2005 at 11:34:09AM -0700, Paul Eggert wrote:
* lib/autoconf/c.m4 (AC_PROG_CC_C_O): Use conf$$.o instead of
...
That looks good, except for one thing: the command
OK, I'll fix the patch before committing it.
rm -f conf$$*
might remove a bit too much
work:
AC_PROG_CC_C_O
eval ac_cv_prog_cc_${ac_cc}_c_o=no
AM_PROG_CC_C_O
This did not work. There is still -c and -o on the same
compiler command line.
Regards
Harri
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman
Stepan Kasal [EMAIL PROTECTED] writes:
The main problem is in the trap defined in ./lib/autoconf/general.m4
in _AC_INIT_PREPARE:
rm -f -r conftest* confdefs* conf$[$]* $ac_clean_files
How about if you simply remove conf[0-9]* instead? Those file names
are all reserved by Autoconf
Stepan Kasal [EMAIL PROTECTED] writes:
2005-07-01 Stepan Kasal [EMAIL PROTECTED]
* lib/autoconf/c.m4 (AC_PROG_CC_C_O): Use conf$$.o instead of
conftest.o, to see whether the compiler really obeys; rm the
object file before the test.
* lib/autoconf/fortran.m4
Hi folks,
It seems that AC_PROG_CC_C_O does not work with Microsoft's
Visual C++ 13.10.3077. The compiler accepts command lines
like
cl -c -o conftest.obj conftest.c
but command lines like
cl -c -o somedir/conftest.obj conftest.c
or
cl -c -o xyz.obj conftest.c
do
Hello,
On Fri, Jul 01, 2005 at 10:14:28AM +0200, Harald Dunkel wrote:
It seems that AC_PROG_CC_C_O does not work with Microsoft's
Visual C++ 13.10.3077.
[...]
cl -c -o somedir/conftest.obj conftest.c
or
cl -c -o xyz.obj conftest.c
do not work as expected. cl silently ignores
Hi,
a bug report pointed me to AC_PROG_CC_C_O.
The macro has two uses:
1) in GNU make's configure.in
2) in Automake's AM_PROG_CC_C_O
ad 1) Special needs of a project should be solved in that project.
ad 2) The comments in automake/m4/minuso.m4 explain why Automake is not
happy
Hi Stepan,
* Stepan Kasal wrote on Fri, Jul 01, 2005 at 01:13:09PM CEST:
The macro has two uses:
1) in GNU make's configure.in
2) in Automake's AM_PROG_CC_C_O
How do you know nobody else uses it? It's published.
If yes, shouldn't we introduce a generalized macro, for example
you know nobody else uses it? It's published.
All packages using subdir-objects (Flat Makefiles in deep source trees
support) currently are using it.
Erm, Stepan talks about AC_PROG_CC_C_O, subdir-objects however uses
AM_PROG_CC_C_O, right?
Regards,
Ralf
On Fri, 2005-07-01 at 14:33 +0200, Ralf Wildenhues wrote:
Hi Stepan,
* Stepan Kasal wrote on Fri, Jul 01, 2005 at 01:13:09PM CEST:
The macro has two uses:
1) in GNU make's configure.in
2) in Automake's AM_PROG_CC_C_O
How do you know nobody else uses it? It's published.
All
make's configure.in
2) in Automake's AM_PROG_CC_C_O
How do you know nobody else uses it? It's published.
All packages using subdir-objects (Flat Makefiles in deep source trees
support) currently are using it.
Erm, Stepan talks about AC_PROG_CC_C_O, subdir-objects however uses
Hello,
On Fri, Jul 01, 2005 at 02:33:57PM +0200, Ralf Wildenhues wrote:
The macro has two uses:
1) in GNU make's configure.in
2) in Automake's AM_PROG_CC_C_O
How do you know nobody else uses it? It's published.
Of course I don't know. But it's so poorly designed, that I think it's
Hi,
On Fri, Jul 01, 2005 at 04:08:50PM +0200, Ralf Corsepius wrote:
All packages using subdir-objects (Flat Makefiles in deep source trees
support) currently are using it.
...
Yep, I am referring to AM_PROG_CC_C_O, which according to the comment
above internally uses AC_PROG_CC_C_O
Stepan Kasal [EMAIL PROTECTED] writes:
2005-07-01 Stepan Kasal [EMAIL PROTECTED]
* lib/autoconf/c.m4 (AC_PROG_CC_C_O): Use conf$$.o instead of
conftest.o, to see whether the compiler really obeys; rm the
object file before the test.
* lib/autoconf/fortran.m4
http://subversions.gnu.org/cgi-bin/cvsweb/autoconf/acspecific.m4?annotate=1.1
The macro AC_PROG_CC_C_O (appended below for convenience), according
to the documentation, is expected to check whether the C compiler
supports -c and -o together. But if you read the code, you can see
that it's checking
"Ian" == Ian Lance Taylor [EMAIL PROTECTED] writes:
Ian That's because the macro was intended for use with GNU make, to
Ian decide what the default compilation rule should be.
Ah, OK. Thanks Ian!
Ian On the other hand, changing it breaks backward compatibility for
Ian no real advantage.
64 matches
Mail list logo
