Alexandre Oliva wrote:
On Nov 17, 2000, Eric Christopher [EMAIL PROTECTED] wrote:
So a solaris cross cygwin compiler would define EXEEXT to be .exe,
however, OBJEXT would be .o because it was compiled on a solaris
box.
I suppose a compiler that targets Cygwin will create .obj object
On Nov 20, 2000, Ralf Corsepius [EMAIL PROTECTED] wrote:
I suppose a compiler that targets Cygwin will create .obj object files
regardless of its host platform.
Hmm, I don't think so.
I stand corrected. Anyone can tell I keep off MS-Windows as much as
possible :-)
--
Alexandre Oliva
On Mon, Nov 20, 2000 at 02:51:47AM -0200, Alexandre Oliva wrote:
On Nov 20, 2000, Ralf Corsepius [EMAIL PROTECTED] wrote:
I suppose a compiler that targets Cygwin will create .obj object files
regardless of its host platform.
Hmm, I don't think so.
I stand corrected. Anyone can tell I keep
Hi,
I'm working on a project with a pretty large (and increasing)
number of configure parameters, so I look for ways to store sets
of parameters externally, such that they be used much like config.cache,
if desired. Since all possible arguments could be known from the macros
used in
Even after setting /cygdrive to binary mode, the problem with
fopen(file, "w") persists (since I had fixed my own autoconf
repository to use "wb" I didn't notice it until I tried to configure
glib which has it's own set of macros like that.
I suspect that it is related to the fact that I'm using
--- Mo DeJong [EMAIL PROTECTED] wrote:
No, it depends in what your compiler outputs.
% cat tmp.c
int i;
% i386-mingw32msvc-gcc -c tmp.c
% ls tmp.*
tmp.c tmp.o
% ./i586-cygwin32-gcc -c tmp.c
% ls tmp.*
tmp.c tmp.o
You would only get a .obj file if you were using VC++.
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
I've searched Google and the mailing list for help on this to no avail.
Perhaps someone can help me. (I'm using Autoconf 2.13 with Cygwin.)
How can I add a define to a Makefile such as this:
... -DCONFIG_DIR=$(sysconfdir)
The thing I thought would work in configure.in:
AC_DEFINE(CONFIG_DIR,
* Mo DeJong
I was under the impression that autoconf would just try to compile
conftest.c and then find the obj extension by looking for files
named conftest.*, filtering out conftest.c and then using whatever
was left (either conftest.o or conftest.obj). That might have
changed, but it
--- Mo DeJong [EMAIL PROTECTED] wrote:
Why would this depend on uname? I was under the impression that
autoconf would just try to compile conftest.c and then find
the obj extension by looking for files named conftest.*,
filtering out conftest.c and then using whatever was left
(either
On Wed, 22 Nov 2000, Earnie Boyd wrote:
--- Mo DeJong [EMAIL PROTECTED] wrote:
Why would this depend on uname? I was under the impression that
autoconf would just try to compile conftest.c and then find
the obj extension by looking for files named conftest.*,
filtering out conftest.c
Akim Demaille [EMAIL PROTECTED] writes:
Could you try to see what happened? Rerun the corresponding debug.sh,
and run `../autoupdate -A .. -configure.in; echo $?'. It should end
with `77'.
$ ./debug-111.sh
==
./debug-111.sh: Testing autoupdate
--- "Lars J. Aas" [EMAIL PROTECTED] wrote:
Even after setting /cygdrive to binary mode, the problem with
fopen(file, "w") persists (since I had fixed my own autoconf
repository to use "wb" I didn't notice it until I tried to configure
glib which has it's own set of macros like that.
I
Mo DeJong wrote:
On Mon, 20 Nov 2000, Earnie Boyd wrote:
--- Mo DeJong [EMAIL PROTECTED] wrote:
No, it depends in what your compiler outputs.
% cat tmp.c
int i;
% i386-mingw32msvc-gcc -c tmp.c
% ls tmp.*
tmp.c tmp.o
% ./i586-cygwin32-gcc -c tmp.c
%
On Wed, Nov 22, 2000 at 03:50:58PM -0500, Paul Berrevoets wrote:
: This is ok for AC_OBJEXT, but for AC_EXEEXT please take into consideration that on
: UWIN (which uses a cc wrapper for MSVC), the compiler also generates a .pdb file,
: which if you don't filter it out along with .obj, would be
But you and I were both talking about files that get generated at link time. AC_OBJEXT
does not link, and therefore should be no problem. The problem lies in AC_EXEEXT. Your
technique needs to be modified somewhat because you are not using file globbing for
'conftest.o' and 'conftest.obj'. How
--- "Lars J. Aas" [EMAIL PROTECTED] wrote:
On Wed, Nov 22, 2000 at 11:13:15AM -0800, Earnie Boyd wrote:
: Oh, I get it,
: it's cl that's creating the program that outputs the lines that contains
the
: \r\n. This means that your "wb" would cause the cl created program to
output
: only \n
On Wed, Nov 22, 2000 at 04:45:40PM -0500, Paul Berrevoets wrote:
: But you and I were both talking about files that get generated at link time.
:AC_OBJEXT
: does not link, and therefore should be no problem.
Yes, ideally. However, the Borland C++ compiler wrapper we're using doesn't
detect
"Lars J. Aas" wrote:
: Your technique needs to be modified somewhat because you are not using file
: globbing for 'conftest.o' and 'conftest.obj'.
That is because I tested for the existence of the file in the loop.
Clearly ... my bad :-(
--
Paul
19 matches
Mail list logo
