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
Hello, Bernard and Akim!
But anyway the documentation patch should be enhanced as it was not
clear enough.
Well, it was unclear enough to confuse at least two people :-/
Let me explain in more words (but this can be too verbose for the
documentation).
It's portable to use suffix rules. It
Hello, Akim!
The problem is a missing space before the ; IMHO. Could you try if it
fixes the problem and adjust Autoconf?
It doesn't help. Both bash 1.14.7 and bash 2.03 don't like stray
semicolons, either preceded by spaces or not. Ash 0.2 and zsh 3.0.7 don't
notice them.
A colon would
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 Dec 14, 2000, Pavel Roskin [EMAIL PROTECTED] wrote:
You cannot make the target of the suffix rule depend on anything else
other then the "corresponding implicit prerequisite".
Do you have an example of something that breaks with this? I've heard
about this before, but all I know of is a
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
While building the current autoconf with gnu-make 3.75 I've had
problems in `man', since $* did get expanded to the complete path of
the dependency and not just the file name. I've seen similar
behaviour from other instances of make, and while not knowing what is
the correct way for making to
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
%% Assar Westerlund [EMAIL PROTECTED] writes:
aw While building the current autoconf with gnu-make 3.75 I've had
aw problems in `man', since $* did get expanded to the complete path of
aw the dependency and not just the file name. I've seen similar
aw behaviour from other instances of
%% Assar Westerlund [EMAIL PROTECTED] writes:
The $* variable always expands to the entire part of the target filename
which _doesn't_ match the suffix.
aw Weird. I had the following case (hopefully these parts of the
aw Makefile are enough), from autoconf's man/Makefile.am:
aw
19 matches
Mail list logo
