"Alexandre" == Alexandre Oliva [EMAIL PROTECTED] writes:
Alexandre On Dec 14, 2000, Akim Demaille [EMAIL PROTECTED] wrote:
I plan to have the two tests: the a.exe one (in a conftestdir as
was to be suggested by Alexandre), and the -o conftest$ac_exeext
one.
Alexandre To be sincere, I hadn't
"Alexandre" == Alexandre Oliva [EMAIL PROTECTED] writes:
Alexandre But saving and restoring doesn't sound bad either...
OK, I'll go for this.
On 14 Dec 2000, Alexandre Oliva wrote:
On Dec 14, 2000, Mo DeJong [EMAIL PROTECTED] wrote:
I am at a loss to explain that one. I would think that a
Linux cross mingw compiler would need to output a .exe
file, but it does not.
Well, then I think it's a bug in the cross compiler.
"Mo" == Mo DeJong [EMAIL PROTECTED] writes:
Mo Boy, the problems with these macros just don't stop. I have now
Mo re-discovered that when you do not include a call to AC_OBJEXT or
Mo AC_EXEEXT, automake acts differently.
Right. Do not remove them until Automake is fixed. They are defined
to
| % ./i386-mingw32msvc-gcc -o run tmp.c
What happens if you don't -o? And are there any problems with run
instead of run.exe? Why is it wrong?
On 14 Dec 2000, Akim Demaille wrote:
"Mo" == Mo DeJong [EMAIL PROTECTED] writes:
Mo Boy, the problems with these macros just don't stop. I have now
Mo re-discovered that when you do not include a call to AC_OBJEXT or
Mo AC_EXEEXT, automake acts differently.
Right. Do not remove them
On 14 Dec 2000, Akim Demaille wrote:
| % ./i386-mingw32msvc-gcc -o run tmp.c
What happens if you don't -o? And are there any problems with run
instead of run.exe? Why is it wrong?
Drum roll please ...
% rm *.exe
% ./i386-mingw32msvc-gcc tmp.c
mo(~/project/install/Xmingwin/bin)% ls *.exe
"Mo" == Mo DeJong [EMAIL PROTECTED] writes:
Mo Well, what if we did this? It kind of puts the hack back in but it
Mo does it without keeping the AC_CYGWIN macros and without compiling
Mo anything.
The problem is that you require AC_CANONICAL_HOST, hence you require
config.guess and config.sub.
On 14 Dec 2000, Akim Demaille wrote:
| On 14 Dec 2000, Akim Demaille wrote:
| | % ./i386-mingw32msvc-gcc -o run tmp.c
|
| What happens if you don't -o? And are there any problems with run
| instead of run.exe? Why is it wrong?
|
| Drum roll please ...
|
| % rm *.exe
| %
-Original Message-
From: Alexandre Oliva [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 14, 2000 4:40 AM
To: Mo DeJong
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: AC_CYGWIN etc. (Was: AC_OBJEXT again)
On Dec 14, 2000, Mo DeJong [EMAIL PROTECTED] wrote:
I am
--- Bernard Dautrevaux [EMAIL PROTECTED] wrote:
-Original Message-
From: Alexandre Oliva [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 14, 2000 4:40 AM
To: Mo DeJong
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: AC_CYGWIN etc. (Was: AC_OBJEXT again
On Dec 14, 2000, Akim Demaille [EMAIL PROTECTED] wrote:
I plan to have the two tests: the a.exe one (in a conftestdir as was
to be suggested by Alexandre), and the -o conftest$ac_exeext one.
To be sincere, I hadn't thought of this option. But, now that you
mentioned, I see it may introduce
On Dec 14, 2000, Akim Demaille [EMAIL PROTECTED] wrote:
| % i586-cygwin32-gcc tmp.c
| % ls *.exe
| a.exe
Yip| Hey Alexandre, did you see that!?!
Yep. I knew about it. I even mentioned this fact a few days ago:
GCC on MS-Windows will generate a.exe instead of a.out. The problem
On Thu, Dec 14, 2000 at 03:26:51PM -0200, Alexandre Oliva wrote:
: Maybe we should just rule the user shouldn't have a program named `a'
: and be done with it?
I want to have a program called `a'. I just want to issue the command
`a coke', and then a gorgeous delivery girl should enter with
On Dec 14, 2000, "Lars J. Aas" [EMAIL PROTECTED] wrote:
On Thu, Dec 14, 2000 at 03:26:51PM -0200, Alexandre Oliva wrote:
: Maybe we should just rule the user shouldn't have a program named `a'
: and be done with it?
I want to have a program called `a'.
Well, then you must not place it in
| On Dec 12, 2000, [EMAIL PROTECTED] wrote:
| EXEEXT and OBJEXT don't need to know $CYGWIN etc.
|
| Ok, but I'd rather have the macros renamed to either _AC_HOST_???EXT
| or _AC_CC_???EXT (and only test with the C compiler).
I'm applying the patch as a starting point, these points
--- Akim Demaille [EMAIL PROTECTED] wrote:
So the real question is, what happens when you use -o conftest? Will
the cross-compiler and native Win compilers produce conftest, or/and
conftest.exe? As long as conftest.exe is created when one `-o
conftest', we're doing good.
AFAIKT, we're
--- Alexandre Oliva [EMAIL PROTECTED] wrote:
On Dec 12, 2000, Earnie Boyd [EMAIL PROTECTED] wrote:
--- Alexandre Oliva [EMAIL PROTECTED] wrote:
On Dec 12, 2000, Mo DeJong [EMAIL PROTECTED] wrote:
I guess the question is, should we try to compile something and the
set the $host if
-Original Message-
From: Akim Demaille [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, December 13, 2000 1:43 PM
To: Mo DeJong
Cc: [EMAIL PROTECTED]
Subject: Re: OBJ and EXE and cross-compilation (Was: AC_OBJEXT again)
"Mo" == Mo DeJong [EMAIL PROTECTED] writes:
Mo
--- Akim Demaille [EMAIL PROTECTED] wrote:
Here is my proposal.
-8-
I have a problem with
-8-
@defmac AC_CYGWIN
@maindex CYGWIN
-Checked for the Cygwin environment in which case the shell variable
-@code{CYGWIN} is set to @samp{yes}. @code{AC_EXEEXT} now handles this
-task.
Here is my proposal.
Index: ChangeLog
from Akim Demaille [EMAIL PROTECTED]
Put back AC_CYGWIN etc. under the responsibility of the
configure.in maintainer, but discourage its use.
* acspecific.m4 (_AC_CYGWIN, _AC_MINGW32, _AC_EMXOS2): Rename as...
On Dec 14, 2000, Mo DeJong [EMAIL PROTECTED] wrote:
I am at a loss to explain that one. I would think that a
Linux cross mingw compiler would need to output a .exe
file, but it does not.
Well, then I think it's a bug in the cross compiler. Incidentally, I
do have a patch for GCC that fixed
Here are the most relevant messages I have from earlier threads.
--
* host or build characteristic?
** Earnie
OBJEXT is only a build feature while EXEEXT is both a build feature
and a host feature.
** Bernard answers
Even
| On Dec 7, 2000, Akim Demaille [EMAIL PROTECTED] wrote:
| "Morten" == Morten Eriksen [EMAIL PROTECTED] writes:
| Morten Akim Demaille [EMAIL PROTECTED] writes:
| OBJEXT and EXEEXT [...] define precisely what they are (build, or
| host?), [...]
|
| Morten Just wanted to add my 0.02 Kroner:
Maybe we should just make the difference between cross-compilation or
not? Here is what I propose.
1. AC_INIT uses uname to compute CYGWIN32, MINGW32 and EMXOS2,
hence OBJEXT and EXEEXT.
2. AC_LANG_COMPILER if cross-compiling runs the old Cygwin32 etc.
tests which involve a compilation
Akim Demaille writes:
* host or build characteristic?
It's neither, nor should it matter. It's a feature of the compiler. If
there's an alternative Cygwin compiler that generates .com files, then
that's what EXEEXT is. If there's a regular Unix compiler that generates
a file 'foo.bazoo'
On Dec 12, 2000, Peter Eisentraut [EMAIL PROTECTED] wrote:
Akim Demaille writes:
* host or build characteristic?
It's neither, nor should it matter. It's a feature of the compiler.
I wholeheartedly agree.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat
"Peter" == Peter Eisentraut [EMAIL PROTECTED] writes:
Peter Akim Demaille writes:
* host or build characteristic?
Peter It's neither, nor should it matter. It's a feature of the
Peter compiler. If there's an alternative Cygwin compiler that
Peter generates .com files, then that's what
On Dec 12, 2000, Akim Demaille [EMAIL PROTECTED] wrote:
What you describe is precisely what I meant by `build': there is not a
single reference to the host in what you describe.
Nope, the output of the compiler follows conventions of the host
machine, so it's a characteristic of the host.
"Alexandre" == Alexandre Oliva [EMAIL PROTECTED] writes:
Alexandre On Dec 12, 2000, Akim Demaille [EMAIL PROTECTED] wrote:
What you describe is precisely what I meant by `build': there is
not a single reference to the host in what you describe.
Alexandre Nope, the output of the compiler
On Tue, Dec 12, 2000 at 07:30:05PM +0100, Akim Demaille wrote:
Alexandre Such a cross-compiler would be a broken compiler. I don't
Alexandre know of any such cross-compilers, so this point is moot.
Ah!!! Then you are telling me we just don't care about __CYGWIN32__
etc. Then that's
On Dec 12, 2000, Akim Demaille [EMAIL PROTECTED] wrote:
If the cross-compiler bar running under Unix still produces non .exe
by default, then we have to over ride its preference.
Please find one such cross-compiler before speculating on their
existence. All compilers I know of that generate
On Dec 12, 2000, [EMAIL PROTECTED] wrote:
EXEEXT and OBJEXT don't need to know $CYGWIN etc.
Ok, but I'd rather have the macros renamed to either _AC_HOST_???EXT
or _AC_CC_???EXT (and only test with the C compiler).
But I'm also a bit unsure as to whether we should use
--- Mo DeJong [EMAIL PROTECTED] wrote:
But would this still work if I wanted to compile with
the mingw compiler under Cygwin? The mingw native
compiler is also named gcc, so what --host triple
would I need to pass to the configure script? It
seems like I would need to pass something for
On Tue, 12 Dec 2000, Earnie Boyd wrote:
--- Mo DeJong [EMAIL PROTECTED] wrote:
But would this still work if I wanted to compile with
the mingw compiler under Cygwin? The mingw native
compiler is also named gcc, so what --host triple
would I need to pass to the configure script? It
--- Mo DeJong [EMAIL PROTECTED] wrote:
On Tue, 12 Dec 2000, Earnie Boyd wrote:
--- Mo DeJong [EMAIL PROTECTED] wrote:
But would this still work if I wanted to compile with
the mingw compiler under Cygwin? The mingw native
compiler is also named gcc, so what --host triple
On Dec 12, 2000, Mo DeJong [EMAIL PROTECTED] wrote:
I guess the question is, should we try to compile something and the
set the $host if the user did not, or do we just expect that the
user is going to pass the correct --host?
Methinks config.guess should do it. Can't it tell cygwin from
--- Alexandre Oliva [EMAIL PROTECTED] wrote:
On Dec 12, 2000, Mo DeJong [EMAIL PROTECTED] wrote:
I guess the question is, should we try to compile something and the
set the $host if the user did not, or do we just expect that the
user is going to pass the correct --host?
Methinks
On Dec 12, 2000, Earnie Boyd [EMAIL PROTECTED] wrote:
--- Alexandre Oliva [EMAIL PROTECTED] wrote:
On Dec 12, 2000, Mo DeJong [EMAIL PROTECTED] wrote:
I guess the question is, should we try to compile something and the
set the $host if the user did not, or do we just expect that the
On Dec 7, 2000, Akim Demaille [EMAIL PROTECTED] wrote:
"Morten" == Morten Eriksen [EMAIL PROTECTED] writes:
Morten Akim Demaille [EMAIL PROTECTED] writes:
OBJEXT and EXEEXT [...] define precisely what they are (build, or
host?), [...]
Morten Just wanted to add my 0.02 Kroner: after
Akim Demaille [EMAIL PROTECTED] writes:
OBJEXT and EXEEXT [...] define precisely what they are (build, or
host?), [...]
Just wanted to add my 0.02 Kroner: after pondering this issue for a
while, I tend to believe we should first and foremost view them as
characteristics of the _compiler_ --
"Morten" == Morten Eriksen [EMAIL PROTECTED] writes:
Morten Akim Demaille [EMAIL PROTECTED] writes:
OBJEXT and EXEEXT [...] define precisely what they are (build, or
host?), [...]
Morten Just wanted to add my 0.02 Kroner: after pondering this issue
Morten for a while, I tend to believe we
| On Wed, Nov 29, 2000 at 07:59:57PM +0100, Akim Demaille wrote:
| : Err, I think I should stop working on Autoconf right now:
| :
| : | for ac_file in `ls conftest.o conftest.obj conftest.* 2/dev/null`; do
| : | case $ac_file in
| : | *.o | *.obj ) ac_cv_objext=`expr
| How about doing something along the same lines for exeext:
|
| for ac_file in `ls conftest.exe conftest conftest.* 2/dev/null`; do
| case $ac_file in
| conftest )ac_cv_exeext=;;
| *.$ac_cv_object ... ) ;;
| *)ac_cv_exeext=`expr
"Earnie" == Earnie Boyd [EMAIL PROTECTED] writes:
Earnie HTH,
It does, thanks. But then, you are referring to EXEEXT as a *build*
feature, not a host feature.
Frankly, I think we will never end having problems until we introduce
the two sets. I can't see why EXEEXT and OBJEXT should be both
I've applied what Lars suggested.
Akim Demaille writes:
there is one side effect to this change: configure no longer says
checking for executable suffix... no
it says
checking for executable suffix...
Maybe you could put quotes around the result, otherwise it looks like
something is broken, IMHO.
--
Peter Eisentraut
-Original Message-
From: Earnie Boyd [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 30, 2000 5:22 PM
To: Akim Demaille
Cc: Lars J. Aas; [EMAIL PROTECTED]; APatche
Subject: Re: AC_OBJEXT again
--- Akim Demaille [EMAIL PROTECTED] wrote:
"Earnie" == Earnie B
On Thu, Nov 30, 2000 at 05:50:54PM +0100, Bernard Dautrevaux wrote:
: Perhaps in fact we can write the test as:
:
: for ac_file in `ls conftest conftest.exe conftest.* 2/dev/null`; do
: case $ac_file in
: *.$ac_ext | *.o | *.obj | *.xcoff | *.tds) ;;
: conftest)
:
I have to admit that I am a bit confused about
what is going on with the _AC_CYGWIN and
_AC_MINGW32 macros. I was under the
impression that they were required
for _AC_EXEEXT or _AC_OBJEXT, but
it seems like the addition of these
new patches will mean the obj and
exe extension will not need to
On Wed, Nov 29, 2000 at 07:59:57PM +0100, Akim Demaille wrote:
: Err, I think I should stop working on Autoconf right now:
:
: | for ac_file in `ls conftest.o conftest.obj conftest.* 2/dev/null`; do
: | case $ac_file in
: | *.o | *.obj ) ac_cv_objext=`expr "$ac_file" :
When the w32 free Borland C++ command line compiler links a program
(conftest.exe), it also produces a file named `conftest.tds' in
addition to `conftest.obj'. In AC_OBJEXT, conftest.* is globbed to
`... conftest.obj conftest.tds', and the for loop ends up deciding
that $ac_objext should be
52 matches
Mail list logo
