Hello,
On Thu, Oct 27, 2005 at 12:09:22PM -0700, Paul Eggert wrote:
> If memory serves the name change from conftst2.c to conftest2.c means
> we don't have to worry about cleaning the files up separately, since
> the already-existing "rm -f conftest*" will clean them up.
yes, the previous patch h
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 th
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 s
Hello.
On Wed, Oct 26, 2005 at 09:11:09PM +0200, Eli Zaretskii wrote:
> > 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
> > conftest$ac_objext
> >
> > If it were "conftest2.$ac_objext"
> 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
> conft
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 t
> 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 l
> 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 capab
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
> 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
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 bein
> 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, arou
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
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 n
Hello,
On Mon, Oct 24, 2005 at 01:41:27PM -0700, Paul Eggert wrote:
> > Is there any C, Fortran, or F77 compiler which could create other
> > conftst2.* files if it receives -o conftst2.$ac_objext ?
>
> Quite possibly, yes.
OK, so I committed the patch attached below.
> But why not name these
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
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
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 tha
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
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 problem.
(Attached.)
A question: is th
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.
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.
___
Autoco
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 th
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 wrote:
> Hello,
>
> On Fri, Jul 01, 2005 at 10:14:28AM +0200, Harald Dunkel wrote:
>
>>How can I tell autoconf to not use -c and -o together,
>>regardless what the test said?
>
>
> Do I guess correctly that you in fact use AM_PROG_CC_C?
AM_PROG_CC_C_O. Yup.
> Then the following h
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. For e
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.
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 ign
28 matches
Mail list logo
