This is the mail archive of the
mailing list for the Cygwin project.
Re: cygport patch: suppress libtool fixup step
Since I appear to be alone in the "where should the compiler's runtime
DLLs go, when packaged for cygwin distribution" question, I'll bow to
the list consensus. I still think, tho, that using
like fedora-mingw does, as the $prefix for components compiled *using*
the cross compiler (and maybe also as the --sysroot/--build-sysroot for
the compiler itself?), makes sense even if we go ahead with using
$toolexeclibdir for the compiler's language runtime DLLs.
However, a pro forma response (including some libtool notes)...
On 7/8/2010 8:59 PM, Dave Korn wrote:
On 08/07/2010 21:52, Charles Wilson wrote:
3) Now, if we want to have a *single* consolidated location for the $target
DLLs -- so that you can actually RUN the stuff you build,
Ah, that's your mistake, right there. It is only an accident that the
binaries we compile with this particular cross-compiler happen to be
executable on the same box that the cross-compiler runs on, but that doesn't
make it not cross-compilation (it's the same host, but not the same $host),
And it's only an accident that cygwin itself ships certain tools that
run on that other Host, but not $host: like strace, cygcheck,...?
This Host/$host thing is an intrinsic element of our $host, and
pretending otherwise is just willful blindness for the sake of...what?
consistency with linux?
Let me quote cgf: "cygwin is not linux".
and I don't think we should do special anything just in order to make them
immediately or easily executable. We offer an i686-pc-cygwin environment in
which there is a cross-compiler to (one or more of) *-pc-mingw*; but that's a
different host, and if someone wants to then *run* the cross-targeted binaries
they've just compiled, they need to *install* them into a mingw installation
(which also may happen to be on the same physical machine, but could just as
well be on another).
Hm. I guess. If you're targeting mingw* for your product, you'll
probably have some sort of installer anyway. I suppose you can always
point to the various DLLs in their various toolchain locations on the
developer's machine within your (innosetup? wise?) installer script, and
specify exactly how they should be installed on the end user's machine.
This does, however, have a significant impact to one of our existing
libtool patches -- the cross-compiler support I was intending to
re-introduce upstream next week.
More below on how the consensus paradigm here "breaks" mingw libtool on
cygwin. (Okay, it doesn't actually "break" it, but it might impact the
end user's perception of it significantly).
There's no reason to try and arrange things that any of
the generated DLLs end up somewhere we can execute them from, I think that's a
I disagree, because it's not an "accident" that cygwin runs on win32
(native), and mingw MEANS gcc on win32 (native). The Host/$host are
intimately involved (ewww...) together.
Well, yes...I agree with Doug Semler that by default, the -bindir argument
should be $(toolexeclibdir) and not $(bindir) for cross builds.
Yes, he's right, that's definitely the way to go. And so any cross-compiler
we offer on cygwin should probably also leave the binaries there in the gcc
private dir, just as a convenience for those who want to *package* - not in
order to make anything directly *executable*.
I'm just arguing that for the *specific* case where $host=cygwin and
$target=mingw* (e.g. we know that the underlying platform ALSO supports
running the "target" executables and DLLs),
I see where you're coming from, but I'm not sure how much it really buys us;
and if we simply write that off - just declare that all mingw flavours are
cross-hosts and you need to package and install stuff that you've
cross-compiled before it will necessarily work (and of course, 32-bit mingw
folks tend to prefer to have everything statically linked in monolithic
executables exactly to avoid having to distribute dlls with their apps) - I
think we can just skate round the issue and say that you can't necessarily run
a cross-compiled *-pc-*mingw* app straight out of its build dir any more than
you could a cross-compiled *-*linux* or a mips*-*-* app.
No, not out of its build dir. Out of its "installed in the sysroot (*)
on the $host" dir.
(*) where I use the term "sysroot" loosely
OTOH, with libtool wrappers, I do indeed mean in the build dir. See below.
I don't suppose that the mingw cross-compilers in standard linux distros try
to install their runtimes into /usr/bin just because you might maybe have wine
available, do they?
No, but the relationship between linux and wine is more distant (and
backwards: the cygwin $host runs within a "mingw" win32 native Host that
is the $target; with wine, the $target itself runs as a NOT-AN-EMULATOR
within the Host linux that is the $host.)
okay, switching away from compiler land, where $host=cygwin and
$target=mingw, to application land USING the cross compiler, where we
configure with $host=mingw and $build=cygwin:
Remember that on cygwin and mingw, libtool will create a wrapper
executable for the $host. There was a bug reported for $host=win32ish,
where if $host != $build libtool tried to execute the cwrapper as part
of the build process. Obviously, for most cross environments, that
failed, and so the build failed.
That has since been fixed; libtool no longer tries, itself, to execute
the wrapper. However, for a number of reasons, cygwin/mingw libtool
includes a lot of code to try to ensure that the wrapper COULD be
executed on $host, IF sufficient OS support exists: e.g. a compatible
$host/$build combo like mingw/cygwin, or even mingw/linux+wine. (Short
version: the path to the real executable is hardcoded. Since the
cwrapper is a $host app, the path must be converted from $build format
to $host format if possible, when emitting the source code for the
target apps' cwrapper).
However...if we deliberately squirrel the cross compiler's runtime DLLs
down in $toolexeclibdir, then all of that is for naught [*] (unless we
specifically add --static-libgcc when compiling the cwrapper) -- while
the cwrapper now is coded correctly by libtool to DTRT on $host, it
can't actually execute because the libgcc DLL is "missing".
[*] OK, it's not "for naught". It's just that the developer using the
cross environment has to set a really weird $PATH to be able to run the
cwrapper, and hence the target executable. Or manually copy the DLLs
somewhere convenient. I guess that's okay, if we document all that somehow.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple