This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [avail for test] libtool-devel-20030216-1

Max Bowsher wrote:

But it does, 99.9% of the time, and I'm very reluctant to install a second
POSIX emulator, when Cygwin works very nicely.
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)

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 -mno-cygwin thing.

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.

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
then built.
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...

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

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 **,
and instead,
(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 compatibility. Years?

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.
Don't lie to configure. Tell it that --build=cygwin, and set BUILD_CC differently from CC. Does that work?

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.
right. And they shouldn't HAVE to know that; this kind of thing will never be more than a hack.

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

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

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:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]