autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AC_OBJEXT again


From: Akim Demaille
Subject: Re: AC_OBJEXT again
Date: 12 Dec 2000 10:20:29 +0100
User-agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands)

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 more precisely:

OBJEXT is a feature of the host-compiler running on the build-system
EXEEXT is a host-system feature

The whole problem with the AC_EXEEXT macro is that when build==host==cygwin,
the compiler GENERATES a conftest.exe file, but "ls conftest" or "test -f
conftest" will find "conftest.exe" (and ls will report "conftest.exe"'s name
as "conftest") but, as Earnie said, "rm conftest" will FAIL...

** Eric Christopher

They are (IMHO, of course) related to the output of the compiler on the
platform that is being built for in one case and the host building for
the other.  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.  On a cygwin box, compiling natively EXEEXT would still be .exe,
however, OBJEXT would be .obj since the object files are residing on the
cygwin box.  Similarly a cygwin cross solaris toolchain (a weird, but
possible thing) would have EXEEXT be blank, and OBJEXT would be defined
as .obj since we're compiling on windows as the host.

** Ralf

1) cross (cross-tools)
configure --build=`config.guess` --host=i386-cygwin

2) target-native (`config.guess` := yyy, target-tools/libs)
CC=i386-cygwin-gcc configure --build=i386-cygwin --host=i386-cygwin

Further issues arise when installing *.[o|obj] files: i.e. a compiler's
chain's startup files or customized startup files (a very common case for
embedded systems).

** Alexandre answers

I suppose a compiler that targets Cygwin will create .obj object files
regardless of its host platform.  I.e., when using a Cygwin compiler (such
that --host=cygwin), you'd get OBJEXT=.obj, regardless of the build
platform, on which the compiler runs.

** Mo answers

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++.

** Christopher Faylor answers

Correct.  To the best of my knowledge, Cygwin has never produced objects
with a .obj extension.  Since it is supposed to be emulating a UNIX
environment, there is no need to do this.

The .exe extension on executable files is a requirement of the "OS", however,
so we can't avoid using that, unfortunately.

** Ralf answers to Alexandre

> I suppose a compiler that targets Cygwin will create .obj object files
> regardless of its host platform.  I.e., when using a Cygwin compiler
> (such that --host=cygwin), you'd get OBJEXT=.obj, regardless of the
> build platform, on which the compiler runs.

Hmm, I don't think so.

# uname
Linux

# /opt/cygwin/bin/i386-pc-cygwin-gcc -c hello.c
# ls
hello.c hello.o

# /opt/cygwin/bin/i386-pc-cygwin-gcc hello.c
# ls
a.exe hello.c

# /opt/cygwin/bin/i386-pc-cygwin-gcc --version
2.95.2-5

** Mo

I always assumed that EXEEXT and OBJEXT were based on
the host. After all, they should depend on the
output of the compiler, right? If CC_FOR_BUILD
support was recently added, perhaps we need something
like EXEEXT_FOR_BUILD and OBJEXT_FOR_BUILD.

VC++ (native)
EXEEXT=.exe
OBJEXT=.obj

gcc (cross mingw or cygwin)
EXEEXT=.exe
OBJEXT=.o


* Problems to solve

** Mo

At any rate, my real problem is that I have a configure.in that needs
to check the ac_cv_mingw32 and ac_cv_cygwin variables in order to work
properly. These variables are never getting set because the _AC_CYGWIN
macro is not getting run.

** Akim

Mo> I have to admit that I am a bit confused about what is going on
Mo> with the _AC_CYGWIN and _AC_MINGW32 macros. I was under the
Mo> impression that they were required for _AC_EXEEXT or _AC_OBJEXT,
Mo> but it seems like the addition of these new patches will mean the
Mo> obj and exe extension will not need to depend on _AC_CYGWIN or
Mo> _AC_MINGW32. I am wondering if the code that checks for $CYGWIN in
Mo> this macro can just be removed?

These lines are my main grief against these macros: they are causing
many problems.  But in addition they are the sources of the bizarre
status of OBJEXT and EXEEXT: these lines clearly defines them as
*host* characteristics, while the next lines are *build*
characteristics.

** Earnie

For those using the Cygwin compiler toolset for MinGW, yes the distinction
between Cygwin and MinGW isn't necessary, the environment is Cygwin even if the
compiler set is the MinGW set.

There a those, me included, using Amol's port of zsh to WinNT with a native
build of fileutils, textutils and the like, this is where the MinGW distinction
is going to matter.

IMO, treat detecting Cygwin and MinGW as you would for "normal" unix.  The
result will need to set special variables such as ac_exeext.


* Alternative detection

** Using uname

*** Earnie

Cygwin comes with uname which reports:
CYGWIN_NT-4.0 DU147636 1.1.0(0.17/3/2) 2000-03-01 00:15:19 i686 unknown

For MinGW I have a uname hack which reports:
MINGW_WinNT DU147636 3 0 i686 unknown

*** Eli answers

Sounds a bit dangerous to me: what if someone uses Mingw, but uname is
from Cygwin?  I understand that many Mingw developers use Cygwin
toolchain (except the compiler and Binutils).

How about running "gcc -v --version" and looking at the output?

*** Earnie answers

There is full email support for MinGW users, see my .sig.  Also, most MinGW
users are using it for Win32 native developement and aren't really doing
./configure.  Some are, and those that are know how to make it work.  Also,
the http://www.mingw.org page has a nice FAQ which can be modified as
needed.

The current version of config.guess/sub without modification return
i686-pc-mingw32 for my configuration and returns i686-pc-cygwin for my
Cygwin configuration.

BTW, gcc --version only return 2.95.2 and gcc -v does contain the characters
mingw when returning the name of the specs file; but I don't like this.


** Using pwd

*** Alexandre

if (cd c:\\ && cd .. && test `pwd` = "C:\\") 2> /dev/null

*** Felix Lee answers

there doesn't have to be a c:.  I've seen a system where the only disk is a
hard drive named a:.

*** Earnie

Yes, C: isn't guaranteed to be a valid device.  It's not specific to djgpp,
cygwin or mingw.

*** Eli answers

This should work with any DOS/Windows environment, it's not specific to any
of the three (DJGPP, Mingw, or Cygwin).  So it cannot reliably distinguish
between these three.

In addition, `pwd' will report "c:/", at least with the DJGPP port of
Bash.

*** Earnie

NO!!  That is shell dependent.  Yuck, yuck, yuck.


* TODO

** Earnie

BTW, since your supporting MinGW, the IFS value when searching the PATH needs
to be ';' instead of ':'.



Local Variables:
mode: outline
fill-column: 76
End:



reply via email to

[Prev in Thread] Current Thread [Next in Thread]