This is the mail archive of the cygwin 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: 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
category error.

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

<grudging acquiescence>

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;

See below.

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:
Unsubscribe info:

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