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

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

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

  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?


Problem reports:
Unsubscribe info:

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