This is the mail archive of the
mailing list for the Cygwin project.
Re: [avail for test] libtool-devel-20030216-1
Max Bowsher wrote:
On cygwin, uname says "cygwin"; it doesn't say "mingw". *By default* the
compiler -- without extra flags -- generates an executable that uses
cygwin. Under MSYS, while the compiler itself is hosted by a posix
layer, *by default* that compiler generates executables that do not need
or use the posix stuff. (Thus, to rebuild MSYS itself, you need to add
special compiler flags. Think -mno-cygwin, only in reverse)
But it does, 99.9% of the time, and I'm very reluctant to install a second
POSIX emulator, when Cygwin works very nicely.
I had the most luck last summer building a cygwin-build, mingw-target
crosstools. [e.g. just like Earnie's kit is an MSYS-build,
mingw-target]. Then, I treated it just like a "real" cross compiler, by
setting build= and target=. I didn't mess with the "regular" cygwin gcc
Accomodating that within the autotools framework -- while ostensibly
possible -- is tricky. "You're a cross compiler, but not really.
BUILD_CC='gcc', HOST_CC='gcc -mno-cygwin'. Ugh.
You can work around this with wrapper scripts (e.g. 'mgcc' contains
'exec gcc -mno-cygwin $*') but that's non standard.
Well, then your configuration is wrong. You should be using the
BUILD_CC to create the first executable, and HOST_CC to create the
second one. Think like a *real* cross compiler...
Since the wrappers are only for running *uninstalled* executables,
this shouldn't be a problem. If it becomes a problem, the answer is
simple: install the executable, and throw both wrappers away.
The exe in question is built, then used to build a .c source file, which is
See, I was afraid you were going here. Good grief but -mno-cygwin is a
royal PITA. However, I *think* you can configure with --build= and
--target= , if you set BUILD_CFLAGS differently from CFLAGS (or somesuch).
Besides, how did you run the SHELL wrapper, which has been a "feature"
of libtool for years? It has "#!/bin/$SHELL" right at the top -- and
I don't think cmd.exe does pound-bang interpretation, and libtool never
sets SHELL=cmd. (or whatever the platform non-compliant shell is).
Of course not - It uses Cygwin bash.
since Chris rearranged the dir structure last summer to be more
xcompiler-like, it might be time now to
(a) start phasing out -mno-cgywin ** as a separate flag **,
(b) provide a wrapper executable or script for the
i*86-pc-mingw-[toolname], instead of symlinks to the "native" tools.
That way, you could simply set CC=' -mingw-gcc' and LD=' -mingw-ld' etc.
And not have to worry about autotools stripping off '-mno-cygwin';
because those "cross compiler" wrappers would add the -mno-cygwin for
you. (if the wrappers are executables, then the -mno-cgywin is
invisible, which might be good in the long run. Of course, we need
-mno-cygwin AS IS for a good long while yet, to support backwards
Don't lie to configure. Tell it that --build=cygwin, and set BUILD_CC
differently from CC. Does that work?
The problem arises from using the trickery of a configure like this:
CC='gcc -mno-cygwin' CXX='g++ -mno-cygwin'
./configure --build=mingw32 --host=mingw32
OK, I'm lying to configure. But it works - or it did.
right. And they shouldn't HAVE to know that; this kind of thing will
never be more than a hack.
Which is why I lie to configure and don't say --build=cygwin --host=mingw32.
For the special case of a cygwin -> mingw cross-compile, the built exes will
run on the building machine, but autotools don't know that.
Again, I think the problem here is that we're all trying to be too
clever. It's a cross-build. It's a native-build -- no, it's BOTH! But
wait (as Ron Popeil would say) there's MORE!
An acceptable kludge occurs to me - I can sed out -mno-cygwin from the line
used to compile the wrapper exe. But I still can't think of any way neat
enough for eventual inclusion in libtool.
What you're basically doing is this:
(1) I want to use different flags for my build environment compared
to the host/target environment
(2) BUT binaries with the host flags will run on the build platform.
Most of the time, but not always: not if (a) there is a pathname
involved, or (b) a posix function is called.
I'm sorry, but I don't think it is or should be
libtool/automake/autoconf's job to keep track of that. It might be nice,
but it would be an AWFUL lot of cruft, to support one single lonely
wacky corner case -- especially when autoconf/automake/libtool already
have a perfectly good mechanism for doing that: the cross-compiler
That corner case can be solved quite nicely in other ways. Build a real
cross environment; utilize the decades of experience we've developed
with that situation. Or, slightly modify the existing cygwin "compiler
structure" to more closely resemble a real cross environment (the
"wrappers within /usr/i686-pc-mingw/" idea). Or, roll your own: make
your own /usr/local/bin/mgcc wrapper, and use
etc. there's wrinkles here, but you're a smart guy, you can figure it out.
One last point: wrappers are only created if the executable is
dynamically linked to a library -- and that shared library is built as
part of the same project tree. If you link statically to your own
internal dependencies -- and why not? It's not like this temporary
executable, built on the build platform to generate code that'll be
turned into the real target exe, will ever be installed anywhere...
And why is a throwaway exe so complicated that it needs a separate
library? And why is that library, built for the build platform, built
as a SHARED lib? It should be a convenience (e.g. not installed) lib,
and those are ALWAYS static.
I think there's a LOT of things "wrong" with the way you're currently
doing stuff; I think you're leveraging too much target-platform code to
build a throwaway build-platform helper program. By streamlining this,
you avoid all of the problems above.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html