RE: [RFC] Simplify MinGW canadian crosses

RE: [RFC] Simplify MinGW canadian crosses

[Danny Smith]

>[RFC] Simplify MinGW canadian crosses
> From: Corinna Vinschen <vinschen at redhat dot com> 
> To: gcc-patches at gcc dot gnu dot org, gdb-patches at sourceware dot
org, binutils at sourceware dot org, mingw-patches at lists dot
sourceforge dot net, cygwin-patches at cygwin dot com 
> Date: Tue, 29 Aug 2006 13:41:07 +0200 
> Subject: [RFC] Simplify MinGW canadian crosses 
> 
>
------------------------------------------------------------------------
--------
> 
> Hi,
> 
> 
> I created the below patchset to allow to build canadian crosses with
> MinGW as host machine.  It allowed me to build a
linux-x-mingw-x-powerpc
> canadian cross, using the in-tree winsup directory, and so,
> consequentially, without the need to have any externally installed
MinGW
> headers and/or libraries.
> 
> Unfortunately, this requires changes in top-level, in libiberty, in
> winsup, in winsup/mingw, and in winsup/w32api.
> 
> A few details:
> 
> - The top-level configury mistakenly treated MinGW as a newlib sort of
>   host/target.  My patch drops newlib from the directories to build
for
>   MinGW.
> 
> - The top-level configury tests for the winsup directory to figure out
>   whether newlib for Cygwin can be built.  This test is questionable,
>   since the winsup dir could only contain a mingw and a w32api
directory
>   to build MinGW.  I changed this so that the existence of
winsup/cygwin
>   is tested instead.
> 
> - If MinGW is the target, the appropriate winsup/mingw and
winsup/w32api
>   directories are added to FLAGS_FOR_TARGET so that the canadian build
>   works with mingw and w32api in-tree, same way as if it's a cygwin
>   target.
> 
> - The libiberty configury doesn't work for mingw correctly.  If it
>   works, it only works accidentally because MinGW has been build with
>   --with-newlib.  Since that's wrong and has been changed in
top-level,
>   MinGW must be handled explicitely now.
> 
> - In the winsup configury, I decoupled MinGW from Cygwin, so that it's
>   possible to build one without relying on the other.  The only
>   directory necessary for both of them is w32api.
> 
> - A major problem when building canadian crosses are tests which check
>   for the compiler being able to create executables (AC_PROG_CC) and
>   tests for availability of functions.  To workaround this problem, I
>   added GCC_NO_EXECUTABLES to winsup/acinclude.m4 and rebuilt the
>   subsequent aclocal.m4 files (but I left out the aclocal.m4 files in
>   the below patch set).
> 
> - The winsup Makefile fails to install if the CYGWIN_LICENSE file is
>   missing.  This doesn't make sense for MinGW, so I have changed this
to
>   be configurable, and is configured depending on the target in
>   winsup/configure.in.
> 
> - Everything else are minor changes to install files into the right
>   spot, etc.
> 
> Are the changes ok with everybody?
> 

With removal of GCC_NO_EXECUTABLES duplication from winsup/acinclude.m4
(that Corinna has already mentioned) these changes are fine by me.  In
fact, they fix a cross-compilation issue that is currently being
discussed on mingw list.

Thanks for doing this, Corinna.

Danny

Re: [RFC] Simplify MinGW canadian crosses

[Corinna Vinschen]

On Aug 31 08:32, Danny Smith wrote:
> > 
> > I applied these patches to the sourceware repository.  I have 
> > no checkin privileges to gcc and mingw, so, could somebody 
> > having these rights apply the appropriate patches there?
> > 
> Thank you.  The mingw sources are in the sourceware repository so really
> you do have checkin privileges.
> Danny

Thanks for the reminder.  I wrongly assumed that mingw's main
repository is on sourceforge.


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

RE: [RFC] Simplify MinGW canadian crosses

[Danny Smith]

> 
> I applied these patches to the sourceware repository.  I have 
> no checkin privileges to gcc and mingw, so, could somebody 
> having these rights apply the appropriate patches there?
> 
Thank you.  The mingw sources are in the sourceware repository so really
you do have checkin privileges.
Danny
> 
> Thanks,
> Corinna

Re: [RFC] Simplify MinGW canadian crosses

[Corinna Vinschen]

On Aug 29 13:41, Corinna Vinschen wrote:
> ChangeLogs:
> ===========
> 
> Top-Level:
> 
>         * configure.in: Never build newlib for a Mingw host.
>         Never build newlib as Mingw target library.
>         Test the existence of winsup/cygwin for building a Cygwin newlib,
>         rather than just winsup.
>         Add winsup/mingw and winsup/w32api paths to FLAGS_FOR_TARGET if
>         building a Mingw target.
>         * configure: Regenerate.
> 
> libiberty:
> 
>         * configure.ac: Add case for Mingw as host.
>         * configure: Regenerate.
> 
> winsup:
> 
>         * Makefile.in: Make installation of CYGWIN_LICENSE configurable.
>         * acinclude.m4: Add GCC_NO_EXECUTABLES from config/no-executables.m4.
>         * aclocal.m4: Regenerate.
>         * configure.in: Add GCC_NO_EXECUTABLES call. Add configuration for
>         INSTALL_LICENSE.  Make cygwin subdirectory optional.  Add sanity
>         check for cygwin resp. mingw subdirectories dependent of the target.
>         * configure: Regenerate.
> 
> winsup/mingw:
> 
>         * Makefile.in: Add with_cross_host to allow more granular checks.
>         Set installation directories accordingly.  Override CC setting only
>         if building a Cygwin target.
>         * aclocal.m4: Regenerate from ../acinclude.m4.
>         * configure.in: Move AC_CANONICAL_SYSTEM check up.  Add
>         GCC_NO_EXECUTABLES.  Substitute with_cross_host in depending files.
>         Test AC_ALLOCA only if building on a native system.
>         * configure: Regenerate.
> 
> winsup/w32api:
> 
>         * configure.in: Substitute with_cross_host in depending files.
>         * configure: Regenerate.
>         * lib/Makefile.in: Add with_cross_host to allow more granular checks.
>         Set installation directories accordingly.
>         * lib/ddk/Makefile.in: Ditto.
>         * lib/directx/Makefile.in: Ditto.

I applied these patches to the sourceware repository.  I have no
checkin privileges to gcc and mingw, so, could somebody having
these rights apply the appropriate patches there?


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

Re: [RFC] Simplify MinGW canadian crosses

[Corinna Vinschen]

On Aug 29 18:49, Corinna Vinschen wrote:
> On Aug 29 12:09, Daniel Jacobowitz wrote:
> > On Tue, Aug 29, 2006 at 06:04:06PM +0200, Corinna Vinschen wrote:
> > > On Aug 29 11:47, Christopher Faylor wrote:
> > > > Btw, I agree with Daniel's suggestion of using
> > > > ../config/no-executables.m4 if that's possible.
> > > 
> > > I did that first, but the argument against this is that the
> > > mingw-runtime package, does not contain a top-level config directory.
> > > The source tree is supposed to be built stand-alone.  Therefore it's
> > > required to have a stand-alone aclocal.m4 file.
> > > 
> > > [time passes]
> > > 
> > > Or do you mean I should just add an include(../config/no-executables.m4)
> > > to winsup/acinclude.m4 and create the aclocal.m4 files from there?
> > 
> > If you do that it'll just emit a sinclude into aclocal.m4 anyway, won't
> > it?
> 
> Hm, yes, I guess so.
> 
> But the problem is clear I hope.  If we refer to ../config/foo, the
> mingw/aclocal.m4 file isn't self-sufficient anymore.  That's actually
> the only reason I didn't refer to ../config/no-executables.m4, but
> copied it instead.

Oh well, it seems I suffered an autotools confusion.  The patch to
winsup/acinclude.m4 is completely unnecessary.  Calling aclocal with the
correct include paths creates apparently correct aclocal.m4 files.  So,
just scratch the winsup/acinclude.m4 patch.  Regenerating the aclocal.m4
files is sufficient.


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

Re: [RFC] Simplify MinGW canadian crosses

[Christopher Faylor]

Grr.  My mailer added a Reply-To to the previous message.  Apologies
to all who were impacted!

cgf

Re: [RFC] Simplify MinGW canadian crosses

[Christopher Faylor]

On Tue, Aug 29, 2006 at 06:49:06PM +0200, Corinna Vinschen wrote:
>On Aug 29 12:09, Daniel Jacobowitz wrote:
>> On Tue, Aug 29, 2006 at 06:04:06PM +0200, Corinna Vinschen wrote:
>> > On Aug 29 11:47, Christopher Faylor wrote:
>> > > Btw, I agree with Daniel's suggestion of using
>> > > ../config/no-executables.m4 if that's possible.
>> > 
>> > I did that first, but the argument against this is that the
>> > mingw-runtime package, does not contain a top-level config directory.
>> > The source tree is supposed to be built stand-alone.  Therefore it's
>> > required to have a stand-alone aclocal.m4 file.
>> > 
>> > [time passes]
>> > 
>> > Or do you mean I should just add an include(../config/no-executables.m4)
>> > to winsup/acinclude.m4 and create the aclocal.m4 files from there?
>> 
>> If you do that it'll just emit a sinclude into aclocal.m4 anyway, won't
>> it?
>
>Hm, yes, I guess so.
>
>But the problem is clear I hope.  If we refer to ../config/foo, the
>mingw/aclocal.m4 file isn't self-sufficient anymore.  That's actually
>the only reason I didn't refer to ../config/no-executables.m4, but
>copied it instead.

As long as there's a valid aclocal.m4 in the mingw directory, I wouldn't
think it would matter but that's a decision for the mingw folks, I think.

The mingw-patches and cygwin-patches mailing lists are in the To: above.
I apologize for posting to a closed list but I thought that this was also
something that needed to be seen there.

Daniel, FWIW, I added you to the allow list in cygwin-patches so your
email shouldn't bounce there anymore.

cgf

Re: [RFC] Simplify MinGW canadian crosses

[Corinna Vinschen]

On Aug 29 12:08, Daniel Jacobowitz wrote:
> On Tue, Aug 29, 2006 at 06:00:45PM +0200, Corinna Vinschen wrote:
> > It does.  I don't quite understand your objections.  You seem to
> > imply that my patches try to do something mysterious, but they don't.
> 
> There's a lesson here for both of us, I think :-)
> 
> Your patches do things which are to me _quite_ mysterious, as in I
> stared at them and couldn't work out what they were for.  I think this
> is because you described your goal, but not how you were getting there.

Uh, sorry about that.

> As I described, CodeSourcery already builds this way regularly:
> 
> > You build a standard canadian, three staged, as usual:
> > 
> >   configure/make/install linux-linux-mingw
> >   configure/make/install linux-linux-arm
> >   configure/make/install linux-mingw-arm
> 
> So since we didn't encounter any of these bugs you've described, I
> assumed you were doing something different.  I apologize.
> 
> I'm not familiar with our linux-linux-mingw process, but I don't see
> any reason it should be fundamentally different from this.  Except,
> doh, it appears we only build the compiler and not the runtime from
> scratch :-(  No wonder I was confused.
> 
> Sorry again!

No worries :)


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

Re: [RFC] Simplify MinGW canadian crosses

[Corinna Vinschen]

On Aug 29 12:09, Daniel Jacobowitz wrote:
> On Tue, Aug 29, 2006 at 06:04:06PM +0200, Corinna Vinschen wrote:
> > On Aug 29 11:47, Christopher Faylor wrote:
> > > Btw, I agree with Daniel's suggestion of using
> > > ../config/no-executables.m4 if that's possible.
> > 
> > I did that first, but the argument against this is that the
> > mingw-runtime package, does not contain a top-level config directory.
> > The source tree is supposed to be built stand-alone.  Therefore it's
> > required to have a stand-alone aclocal.m4 file.
> > 
> > [time passes]
> > 
> > Or do you mean I should just add an include(../config/no-executables.m4)
> > to winsup/acinclude.m4 and create the aclocal.m4 files from there?
> 
> If you do that it'll just emit a sinclude into aclocal.m4 anyway, won't
> it?

Hm, yes, I guess so.

But the problem is clear I hope.  If we refer to ../config/foo, the
mingw/aclocal.m4 file isn't self-sufficient anymore.  That's actually
the only reason I didn't refer to ../config/no-executables.m4, but
copied it instead.


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

Re: [RFC] Simplify MinGW canadian crosses

[Daniel Jacobowitz]

On Tue, Aug 29, 2006 at 06:04:06PM +0200, Corinna Vinschen wrote:
> On Aug 29 11:47, Christopher Faylor wrote:
> > Btw, I agree with Daniel's suggestion of using
> > ../config/no-executables.m4 if that's possible.
> 
> I did that first, but the argument against this is that the
> mingw-runtime package, does not contain a top-level config directory.
> The source tree is supposed to be built stand-alone.  Therefore it's
> required to have a stand-alone aclocal.m4 file.
> 
> [time passes]
> 
> Or do you mean I should just add an include(../config/no-executables.m4)
> to winsup/acinclude.m4 and create the aclocal.m4 files from there?

If you do that it'll just emit a sinclude into aclocal.m4 anyway, won't
it?

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Simplify MinGW canadian crosses

[Daniel Jacobowitz]

On Tue, Aug 29, 2006 at 06:00:45PM +0200, Corinna Vinschen wrote:
> It does.  I don't quite understand your objections.  You seem to
> imply that my patches try to do something mysterious, but they don't.

There's a lesson here for both of us, I think :-)

Your patches do things which are to me _quite_ mysterious, as in I
stared at them and couldn't work out what they were for.  I think this
is because you described your goal, but not how you were getting there.

As I described, CodeSourcery already builds this way regularly:

> You build a standard canadian, three staged, as usual:
> 
>   configure/make/install linux-linux-mingw
>   configure/make/install linux-linux-arm
>   configure/make/install linux-mingw-arm

So since we didn't encounter any of these bugs you've described, I
assumed you were doing something different.  I apologize.

I'm not familiar with our linux-linux-mingw process, but I don't see
any reason it should be fundamentally different from this.  Except,
doh, it appears we only build the compiler and not the runtime from
scratch :-(  No wonder I was confused.

Sorry again!

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Simplify MinGW canadian crosses

[Corinna Vinschen]

On Aug 29 11:47, Christopher Faylor wrote:
> Btw, I agree with Daniel's suggestion of using
> ../config/no-executables.m4 if that's possible.

I did that first, but the argument against this is that the
mingw-runtime package, does not contain a top-level config directory.
The source tree is supposed to be built stand-alone.  Therefore it's
required to have a stand-alone aclocal.m4 file.

[time passes]

Or do you mean I should just add an include(../config/no-executables.m4)
to winsup/acinclude.m4 and create the aclocal.m4 files from there?


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

Re: [RFC] Simplify MinGW canadian crosses

[Corinna Vinschen]

[Also dropped the lists cygwin-patches and mingw-patches here]

On Aug 29 11:44, Daniel Jacobowitz wrote:
> On Tue, Aug 29, 2006 at 05:35:40PM +0200, Corinna Vinschen wrote:
> > Sorry, but that's not the deal.  Using my patches, you can install a
> > standard source tree, including gcc, gdb, binutils, [...], and last but
> > not least the winsup directory on, say, a Linux machine, and then build
> > a complete three stage canadian cross on *Linux*, which generates a
> > i686-pc-mingw32-x-arm-elf toolchain.  You don't have to install the MinGW
> > libraries and header files somewhere on the Linux machine and tweak the
> > build process to find them.  Everything comes out of the same source
> > tree.  From my point of view this simplifies stuff, it doesn't make it
> > more complicated.
> 
> Are your changes affecting the i686-pc-mingw32 targeted compiler built
> in the middle?  Your description suggested that it affected the build
> process of the final canadian cross compiler.  If you're changing that
> second one, then none of my objections are relevant.
> 
> I guess what I'm asking is: why doesn't "make install" when you've
> built the i686-pc-mingw32 compiler install everything you need to use
> that compiler to build i686-pc-mingw32 hosted applications?

It does.  I don't quite understand your objections.  You seem to
imply that my patches try to do something mysterious, but they don't.
You build a standard canadian, three staged, as usual:

  configure/make/install linux-linux-mingw
  configure/make/install linux-linux-arm
  configure/make/install linux-mingw-arm

None of my patches is actually complicated or adds any new feature.
They only fix bugs which hinder to build canadian crosses the right
way (TM).


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

Re: [RFC] Simplify MinGW canadian crosses

[Christopher Faylor]

On Tue, Aug 29, 2006 at 05:35:40PM +0200, Corinna Vinschen wrote:
>On Aug 29 11:09, Daniel Jacobowitz wrote:
>> On Tue, Aug 29, 2006 at 10:59:27AM -0400, DJ Delorie wrote:
>> > 
>> > > If you want to build some code that runs on mingw, I don't think
>> > > that having mingw tools installed is an unreasonable requirement.
>> > 
>> > This is how you *get* mingw tools installed.  The same logic that
>> > gives you a canadian (worst case) also gives you host-x-host.
>> 
>> Not so, unless I'm vastly confused.
>> 
>> Corinna is trying to generate --host=i686-mingw32 tools, with a
>> different --target.  This requires at least a --target=i686-mingw32
>> compiler coming from elsewhere.  That compiler can build the
>> --host=i686-mingw32 libraries, and usually should.
>> 
>> This is more like adding support for using the in tree newlib with an
>> arm-linux compiler so that you could build GCC to run on arm-linux,
>> without having to install an arm-linux C library first.  That's why
>> I'm dubious about the value.  But maybe Corinna has some good example
>> of when you want to do this?
>
>Sorry, but that's not the deal.  Using my patches, you can install a
>standard source tree, including gcc, gdb, binutils, [...], and last but
>not least the winsup directory on, say, a Linux machine, and then build
>a complete three stage canadian cross on *Linux*, which generates a
>i686-pc-mingw32-x-arm-elf toolchain.  You don't have to install the MinGW
>libraries and header files somewhere on the Linux machine and tweak the
>build process to find them.  Everything comes out of the same source
>tree.  From my point of view this simplifies stuff, it doesn't make it
>more complicated.

To be devil's advocate - I think the question is "Why should MinGW be
treated specially?"

I know that Cygwin is already treated specially in this regard (i.e.,
you can do an in-tree build to generate a cygwin cross-compiler without
necessarily having cygwin installed), and I believe that it is possible
to build newlib versions of gcc, but it apparently hasn't been a goal to
build MinGW without first installing a MinGW toolchain.

I think the answer is - since we already handle Cygwin and gcc's
configure already understands the winsup directory, why not just extend
configure to handle MinGW as well as Cygwin?  I don't think this
suggestion would make sense if we were talking about accommodating a
*new* directory in the build tree but since the MinGW directory is
almost handled now, I don't see any harm.

Btw, I agree with Daniel's suggestion of using
../config/no-executables.m4 if that's possible.

cgf

Re: [RFC] Simplify MinGW canadian crosses

[Daniel Jacobowitz]

On Tue, Aug 29, 2006 at 05:35:40PM +0200, Corinna Vinschen wrote:
> Sorry, but that's not the deal.  Using my patches, you can install a
> standard source tree, including gcc, gdb, binutils, [...], and last but
> not least the winsup directory on, say, a Linux machine, and then build
> a complete three stage canadian cross on *Linux*, which generates a
> i686-pc-mingw32-x-arm-elf toolchain.  You don't have to install the MinGW
> libraries and header files somewhere on the Linux machine and tweak the
> build process to find them.  Everything comes out of the same source
> tree.  From my point of view this simplifies stuff, it doesn't make it
> more complicated.

Are your changes affecting the i686-pc-mingw32 targeted compiler built
in the middle?  Your description suggested that it affected the build
process of the final canadian cross compiler.  If you're changing that
second one, then none of my objections are relevant.

I guess what I'm asking is: why doesn't "make install" when you've
built the i686-pc-mingw32 compiler install everything you need to use
that compiler to build i686-pc-mingw32 hosted applications?

CodeSourcery does something not much different every day, by the way.
We configure a mingw32 compiler with its own prefix, build it, make
install, and then everything works - no "tweaking the build process"
to find anything.

I'm sure making these scripts more complicated simplifies whatever
outside scripts you're using to build the whole three stage deal; but
everyone has to carry the cost of the complexity in these central
scripts, not just the people using your build process.

You cross posted to two closed lists, by the way.  I have dropped them,
because I'm tired of getting the bounces.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Simplify MinGW canadian crosses

[DJ Delorie]

I'll let Corinna answer herself, but I don't think we're trying to do
anything differently than what we already do for Cygwin.

Re: [RFC] Simplify MinGW canadian crosses

[Corinna Vinschen]

On Aug 29 11:09, Daniel Jacobowitz wrote:
> On Tue, Aug 29, 2006 at 10:59:27AM -0400, DJ Delorie wrote:
> > 
> > > If you want to build some code that runs on mingw, I don't think
> > > that having mingw tools installed is an unreasonable requirement.
> > 
> > This is how you *get* mingw tools installed.  The same logic that
> > gives you a canadian (worst case) also gives you host-x-host.
> 
> Not so, unless I'm vastly confused.
> 
> Corinna is trying to generate --host=i686-mingw32 tools, with a
> different --target.  This requires at least a --target=i686-mingw32
> compiler coming from elsewhere.  That compiler can build the
> --host=i686-mingw32 libraries, and usually should.
> 
> This is more like adding support for using the in tree newlib with an
> arm-linux compiler so that you could build GCC to run on arm-linux,
> without having to install an arm-linux C library first.  That's why
> I'm dubious about the value.  But maybe Corinna has some good example
> of when you want to do this?

Sorry, but that's not the deal.  Using my patches, you can install a
standard source tree, including gcc, gdb, binutils, [...], and last but
not least the winsup directory on, say, a Linux machine, and then build
a complete three stage canadian cross on *Linux*, which generates a
i686-pc-mingw32-x-arm-elf toolchain.  You don't have to install the MinGW
libraries and header files somewhere on the Linux machine and tweak the
build process to find them.  Everything comes out of the same source
tree.  From my point of view this simplifies stuff, it doesn't make it
more complicated.


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

Re: [RFC] Simplify MinGW canadian crosses

[Daniel Jacobowitz]

On Tue, Aug 29, 2006 at 11:23:30AM -0400, DJ Delorie wrote:
> 
> > Corinna is trying to generate --host=i686-mingw32 tools, with a
> > different --target.  This requires at least a --target=i686-mingw32
> > compiler coming from elsewhere.  That compiler can build the
> > --host=i686-mingw32 libraries, and usually should.
> 
> Yes.  So?  We build that compiler from the same tree (as a simple
> cross), so it's still the same problem.  We still have to build those
> libraries somehow, we still need to have them in source control, etc.
> Our build farm likes to see a monolithic source tree, and we already
> support building cygwin out of that tree, building mingw out of it is
> a minor change.
> 
> (actually, we build four compilers out of that tree:
> 	linux-linux-linux
> 	linux-linux-mingw
> 	linux-linux-arm
> 	linux-mingw-arm)

I really feel like I'm not communicating here; you're not answering
what I'm asking.  Do you disagree with any of these points?

- To build linux-linux-mingw you already had to have a working compiler
targeting linux.

- To build linux-mingw-arm you must have already built
linux-linux-mingw.  And you must have installed it somewhere that
you could run it later.

- When you build linux-linux-mingw from the combined tree, it
is capable of building the mingw libraries.  That's even the normal
time to do it.

When it comes time to build linux-mingw-arm, you're trying to build
mingw at the same time.  I think that's silly; you should have built
it an iteration earlier.  When you were building a compiler, and
libgcc, for mingw.

Now maybe there's some clever reason why this is better, that you
can explain to me.  I'm not violently opposed.  But I don't see why
we should pick up complexity to build it the way Corinna described
it, unless there's some reason - this stuff is way overcomplex already.

Or maybe the description was wrong, or I misunderstood it?  It doesn't
fit with the tests added to configure.in, which check ${target} for
being mingw.

On a minor note, unless there's some reason otherwise, you may want to
use sinclude(../config/no-executables.m4) instead of copying
GCC_NO_EXECUTABLES.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Simplify MinGW canadian crosses

[DJ Delorie]

> Corinna is trying to generate --host=i686-mingw32 tools, with a
> different --target.  This requires at least a --target=i686-mingw32
> compiler coming from elsewhere.  That compiler can build the
> --host=i686-mingw32 libraries, and usually should.

Yes.  So?  We build that compiler from the same tree (as a simple
cross), so it's still the same problem.  We still have to build those
libraries somehow, we still need to have them in source control, etc.
Our build farm likes to see a monolithic source tree, and we already
support building cygwin out of that tree, building mingw out of it is
a minor change.

(actually, we build four compilers out of that tree:
	linux-linux-linux
	linux-linux-mingw
	linux-linux-arm
	linux-mingw-arm)

Re: [RFC] Simplify MinGW canadian crosses

[Daniel Jacobowitz]

On Tue, Aug 29, 2006 at 10:59:27AM -0400, DJ Delorie wrote:
> 
> > If you want to build some code that runs on mingw, I don't think
> > that having mingw tools installed is an unreasonable requirement.
> 
> This is how you *get* mingw tools installed.  The same logic that
> gives you a canadian (worst case) also gives you host-x-host.

Not so, unless I'm vastly confused.

Corinna is trying to generate --host=i686-mingw32 tools, with a
different --target.  This requires at least a --target=i686-mingw32
compiler coming from elsewhere.  That compiler can build the
--host=i686-mingw32 libraries, and usually should.

This is more like adding support for using the in tree newlib with an
arm-linux compiler so that you could build GCC to run on arm-linux,
without having to install an arm-linux C library first.  That's why
I'm dubious about the value.  But maybe Corinna has some good example
of when you want to do this?

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Simplify MinGW canadian crosses

[DJ Delorie]

> If you want to build some code that runs on mingw, I don't think
> that having mingw tools installed is an unreasonable requirement.

This is how you *get* mingw tools installed.  The same logic that
gives you a canadian (worst case) also gives you host-x-host.

Re: [RFC] Simplify MinGW canadian crosses

[DJ Delorie]

The libiberty and toplevel changes are OK with me, if the mingw
maintainer agrees.

Re: [RFC] Simplify MinGW canadian crosses

[Daniel Jacobowitz]

On Tue, Aug 29, 2006 at 01:41:07PM +0200, Corinna Vinschen wrote:
> Hi,
> 
> 
> I created the below patchset to allow to build canadian crosses with
> MinGW as host machine.  It allowed me to build a linux-x-mingw-x-powerpc
> canadian cross, using the in-tree winsup directory, and so,
> consequentially, without the need to have any externally installed MinGW
> headers and/or libraries.
> 
> Unfortunately, this requires changes in top-level, in libiberty, in
> winsup, in winsup/mingw, and in winsup/w32api.

Some of these patches may be good on their own.  But, why go to this
much effort to support doing this complicated setup in a single tree? I
really don't think it's a good idea.  If you want to build some code
that runs on mingw, I don't think that having mingw tools installed
is an unreasonable requirement.

We have to pick and choose where to invest in making our build system
even more complex.

-- 
Daniel Jacobowitz
CodeSourcery

[RFC] Simplify MinGW canadian crosses

[Corinna Vinschen]

Hi,


I created the below patchset to allow to build canadian crosses with
MinGW as host machine.  It allowed me to build a linux-x-mingw-x-powerpc
canadian cross, using the in-tree winsup directory, and so,
consequentially, without the need to have any externally installed MinGW
headers and/or libraries.

Unfortunately, this requires changes in top-level, in libiberty, in
winsup, in winsup/mingw, and in winsup/w32api.

A few details:

- The top-level configury mistakenly treated MinGW as a newlib sort of
  host/target.  My patch drops newlib from the directories to build for
  MinGW.

- The top-level configury tests for the winsup directory to figure out
  whether newlib for Cygwin can be built.  This test is questionable,
  since the winsup dir could only contain a mingw and a w32api directory
  to build MinGW.  I changed this so that the existence of winsup/cygwin
  is tested instead.

- If MinGW is the target, the appropriate winsup/mingw and winsup/w32api
  directories are added to FLAGS_FOR_TARGET so that the canadian build
  works with mingw and w32api in-tree, same way as if it's a cygwin
  target.

- The libiberty configury doesn't work for mingw correctly.  If it
  works, it only works accidentally because MinGW has been build with
  --with-newlib.  Since that's wrong and has been changed in top-level,
  MinGW must be handled explicitely now.

- In the winsup configury, I decoupled MinGW from Cygwin, so that it's
  possible to build one without relying on the other.  The only
  directory necessary for both of them is w32api.

- A major problem when building canadian crosses are tests which check
  for the compiler being able to create executables (AC_PROG_CC) and
  tests for availability of functions.  To workaround this problem, I
  added GCC_NO_EXECUTABLES to winsup/acinclude.m4 and rebuilt the
  subsequent aclocal.m4 files (but I left out the aclocal.m4 files in
  the below patch set).

- The winsup Makefile fails to install if the CYGWIN_LICENSE file is
  missing.  This doesn't make sense for MinGW, so I have changed this to
  be configurable, and is configured depending on the target in
  winsup/configure.in.

- Everything else are minor changes to install files into the right
  spot, etc.

Are the changes ok with everybody?


Corinna


ChangeLogs:
===========

Top-Level:

        * configure.in: Never build newlib for a Mingw host.
        Never build newlib as Mingw target library.
        Test the existence of winsup/cygwin for building a Cygwin newlib,
        rather than just winsup.
        Add winsup/mingw and winsup/w32api paths to FLAGS_FOR_TARGET if
        building a Mingw target.
        * configure: Regenerate.

libiberty:

        * configure.ac: Add case for Mingw as host.
        * configure: Regenerate.

winsup:

        * Makefile.in: Make installation of CYGWIN_LICENSE configurable.
        * acinclude.m4: Add GCC_NO_EXECUTABLES from config/no-executables.m4.
        * aclocal.m4: Regenerate.
        * configure.in: Add GCC_NO_EXECUTABLES call. Add configuration for
        INSTALL_LICENSE.  Make cygwin subdirectory optional.  Add sanity
        check for cygwin resp. mingw subdirectories dependent of the target.
        * configure: Regenerate.

winsup/mingw:

        * Makefile.in: Add with_cross_host to allow more granular checks.
        Set installation directories accordingly.  Override CC setting only
        if building a Cygwin target.
        * aclocal.m4: Regenerate from ../acinclude.m4.
        * configure.in: Move AC_CANONICAL_SYSTEM check up.  Add
        GCC_NO_EXECUTABLES.  Substitute with_cross_host in depending files.
        Test AC_ALLOCA only if building on a native system.
        * configure: Regenerate.

winsup/w32api:

        * configure.in: Substitute with_cross_host in depending files.
        * configure: Regenerate.
        * lib/Makefile.in: Add with_cross_host to allow more granular checks.
        Set installation directories accordingly.
        * lib/ddk/Makefile.in: Ditto.
        * lib/directx/Makefile.in: Ditto.

Index: configure.in
===================================================================
RCS file: /cvs/src/src/configure.in,v
retrieving revision 1.315
diff -u -p -r1.315 configure.in
--- configure.in	25 Jul 2006 08:39:57 -0000	1.315
+++ configure.in	29 Aug 2006 09:45:12 -0000
@@ -279,7 +279,7 @@ case "${host}" in
     ;;
   i[[3456789]]86-*-mingw32*)
     # noconfigdirs="tcl tk expect dejagnu make texinfo bison patch flex byacc send-pr uudecode dejagnu diff guile perl itcl gnuserv"
-    noconfigdirs="$noconfigdirs expect dejagnu autoconf automake send-pr rcs guile perl texinfo libtool"
+    noconfigdirs="$noconfigdirs expect dejagnu autoconf automake send-pr rcs guile perl texinfo libtool newlib"
     ;;
   i[[3456789]]86-*-beos*)
     noconfigdirs="$noconfigdirs tk itcl libgui gdb"
@@ -615,17 +615,17 @@ case "${target}" in
     # 'target-newlib' will appear in skipdirs.
     ;;
   i[[3456789]]86-*-mingw32*)
-    target_configdirs="$target_configdirs target-mingw"
-    noconfigdirs="$noconfigdirs expect target-libgloss ${libgcj}"
+    target_configdirs="$target_configdirs target-winsup"
+    noconfigdirs="$noconfigdirs expect target-libgloss target-newlib ${libgcj}"
     ;;    
   *-*-cygwin*)
     target_configdirs="$target_configdirs target-libtermcap target-winsup"
     noconfigdirs="$noconfigdirs target-gperf target-libgloss ${libgcj}"
     # always build newlib if winsup directory is present.
-    if test -d "$srcdir/winsup"; then
+    if test -d "$srcdir/winsup/cygwin"; then
       skipdirs=`echo " ${skipdirs} " | sed -e 's/ target-newlib / /'`
     elif test -d "$srcdir/newlib"; then
-      echo "Warning: winsup is missing so newlib can't be built."
+      echo "Warning: winsup/cygwin is missing so newlib can't be built."
     fi
     ;;    
   i[[3456789]]86-moss-msdos | i[[3456789]]86-*-moss* | \
@@ -2121,6 +2121,11 @@ case " $target_configdirs " in
   esac
   ;;
 esac
+case "$target" in
+*-mingw*)
+  # Can't be handled as Cygwin above since Mingw does not use newlib.
+  FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET' -L$$r/$(TARGET_SUBDIR)/winsup/mingw -L$$r/$(TARGET_SUBDIR)/winsup/w32api/lib -isystem $$s/winsup/mingw/include -isystem $$s/winsup/w32api/include' ;;
+esac
 
 # Allow the user to override the flags for
 # our build compiler if desired.
Index: libiberty/configure.ac
===================================================================
RCS file: /cvs/src/src/libiberty/configure.ac,v
retrieving revision 1.31
diff -u -p -r1.31 configure.ac
--- libiberty/configure.ac	7 Apr 2006 00:01:25 -0000	1.31
+++ libiberty/configure.ac	29 Aug 2006 09:45:13 -0000
@@ -419,6 +419,55 @@ if test -n "${with_target_subdir}"; then
 
   fi
 
+  # If we are being configured for Mingw, we know which functions
+  # Mingw provides and which ones we will be expected to provide.
+
+  case "${host}" in
+  *-*-mingw*)
+    AC_LIBOBJ([asprintf])
+    AC_LIBOBJ([basename])
+    AC_LIBOBJ([bcmp])
+    AC_LIBOBJ([bcopy])
+    AC_LIBOBJ([bzero])
+    AC_LIBOBJ([clock])
+    AC_LIBOBJ([ffs])
+    AC_LIBOBJ([getpagesize])
+    AC_LIBOBJ([index])
+    AC_LIBOBJ([insque])
+    AC_LIBOBJ([mempcpy])
+    AC_LIBOBJ([mkstemps])
+    AC_LIBOBJ([random])
+    AC_LIBOBJ([rindex])
+    AC_LIBOBJ([sigsetmask])
+    AC_LIBOBJ([stpcpy])
+    AC_LIBOBJ([stpncpy])
+    AC_LIBOBJ([strndup])
+    AC_LIBOBJ([strverscmp])
+    AC_LIBOBJ([vasprintf])
+    AC_LIBOBJ([waitpid])
+
+    for f in $funcs; do
+      case "$f" in
+	asprintf | basename | bcmp | bcopy | bzero | clock | ffs | getpagesize | index | insque | mempcpy | mkstemps | random | rindex | sigsetmask | stpcpy | stpncpy | strdup | strndup | strverscmp | vasprintf | waitpid)
+	  ;;
+	*)
+	  n=HAVE_`echo $f | tr 'abcdefghijklmnopqrstuvwxyz' 'ABCDEFGHIJKLMNOPQRSTUVWXYZ'`
+	  AC_DEFINE_UNQUOTED($n)
+	  ;;
+      esac
+    done
+
+    # Mingw doesnt provide any of the variables in $vars, so we
+    # dont have to check them here.
+
+    # Of the functions in $checkfuncs, Mingw only has strerror.
+    AC_DEFINE(HAVE_STRERROR)
+
+    setobjs=yes
+    ;;
+
+  esac
+
   # We may wish to install the target headers somewhere.
   AC_ARG_ENABLE(install-libiberty,
   [  --enable-install-libiberty       Install headers for end users],
Index: winsup/Makefile.in
===================================================================
RCS file: /cvs/src/src/winsup/Makefile.in,v
retrieving revision 1.24
diff -u -p -r1.24 Makefile.in
--- winsup/Makefile.in	3 Aug 2006 03:47:54 -0000	1.24
+++ winsup/Makefile.in	29 Aug 2006 09:45:13 -0000
@@ -46,6 +46,8 @@ INSTALL_SUBDIRS=${patsubst %,install_%,$
 CLEAN_SUBDIRS=${patsubst %,clean_%,$(SUBDIRS)}
 ZLIB=${findstring zlib,$(SUBDIRS)}
 
+INSTALL_LICENSE:=@INSTALL_LICENSE@
+
 .PHONY: all install clean all-info info install-info check \
 	$(SUBDIRS) $(INSTALL_SUBDIRS) $(CLEAN_SUBDIRS)
 
@@ -61,9 +63,11 @@ endif
 
 all: Makefile $(SUBDIRS)
 
-install: Makefile CYGWIN_LICENSE $(INSTALL_SUBDIRS)
+install-license: CYGWIN_LICENSE 
 	$(INSTALL_DATA) $(srcdir)/CYGWIN_LICENSE $(prefix)/share/doc/Cygwin/CYGWIN_LICENSE
 
+install: Makefile $(INSTALL_LICENSE) $(INSTALL_SUBDIRS)
+
 clean: $(CLEAN_SUBDIRS)
 
 all-info:
Index: winsup/acinclude.m4
===================================================================
RCS file: /cvs/src/src/winsup/acinclude.m4,v
retrieving revision 1.1
diff -u -p -r1.1 acinclude.m4
--- winsup/acinclude.m4	24 May 2006 16:59:02 -0000	1.1
+++ winsup/acinclude.m4	29 Aug 2006 09:45:13 -0000
@@ -41,3 +41,65 @@ fi
 
 CXXFLAGS='$(CFLAGS)'
 ])
+
+# GCC_NO_EXECUTABLES
+# -----------------
+# FIXME: The GCC team has specific needs which the current Autoconf
+# framework cannot solve elegantly.  This macro implements a dirty
+# hack until Autoconf is able to provide the services its users
+# need.
+#
+# Several of the support libraries that are often built with GCC can't
+# assume the tool-chain is already capable of linking a program: the
+# compiler often expects to be able to link with some of such
+# libraries.
+#
+# In several of these libraries, workarounds have been introduced to
+# avoid the AC_PROG_CC_WORKS test, that would just abort their
+# configuration.  The introduction of AC_EXEEXT, enabled either by
+# libtool or by CVS autoconf, have just made matters worse.
+#
+# Unlike the previous AC_NO_EXECUTABLES, this test does not
+# disable link tests at autoconf time, but at configure time.
+# This allows AC_NO_EXECUTABLES to be invoked conditionally.
+AC_DEFUN_ONCE([GCC_NO_EXECUTABLES],
+[m4_divert_push([KILL])
+
+AC_BEFORE([$0], [_AC_COMPILER_EXEEXT])
+AC_BEFORE([$0], [AC_LINK_IFELSE])
+
+m4_define([_AC_COMPILER_EXEEXT],
+AC_LANG_CONFTEST([AC_LANG_PROGRAM()])
+# FIXME: Cleanup?
+AS_IF([AC_TRY_EVAL(ac_link)], [gcc_no_link=no], [gcc_no_link=yes])
+if test x$gcc_no_link = xyes; then
+  # Setting cross_compile will disable run tests; it will
+  # also disable AC_CHECK_FILE but that's generally
+  # correct if we can't link.
+  cross_compiling=yes
+  EXEEXT=
+else
+  m4_defn([_AC_COMPILER_EXEEXT])dnl
+fi
+)
+
+m4_define([AC_LINK_IFELSE],
+if test x$gcc_no_link = xyes; then
+  AC_MSG_ERROR([Link tests are not allowed after [[$0]].])
+fi
+m4_defn([AC_LINK_IFELSE]))
+
+dnl This is a shame.  We have to provide a default for some link tests,
+dnl similar to the default for run tests.
+m4_define([AC_FUNC_MMAP],
+if test x$gcc_no_link = xyes; then
+  if test "x${ac_cv_func_mmap_fixed_mapped+set}" != xset; then
+    ac_cv_func_mmap_fixed_mapped=no
+  fi
+fi
+if test "x${ac_cv_func_mmap_fixed_mapped}" != xno; then
+  m4_defn([AC_FUNC_MMAP])
+fi)
+
+m4_divert_pop()dnl
+])# GCC_NO_EXECUTABLES
Index: winsup/configure.in
===================================================================
RCS file: /cvs/src/src/winsup/configure.in,v
retrieving revision 1.28
diff -u -p -r1.28 configure.in
--- winsup/configure.in	25 Jul 2006 19:18:04 -0000	1.28
+++ winsup/configure.in	29 Aug 2006 09:45:13 -0000
@@ -17,6 +17,8 @@ INSTALL=`cd $srcdir/..; echo $(pwd)/inst
 AC_PROG_INSTALL
 AC_CANONICAL_SYSTEM
 
+GCC_NO_EXECUTABLES
+
 LIB_AC_PROG_CC
 LIB_AC_PROG_CXX
 
@@ -31,10 +33,27 @@ no)	use_cygserver=;;
 esac
 ])
 
-AC_CONFIG_SUBDIRS(cygwin w32api)
+INSTALL_LICENSE=
+
+case "$target" in
+  *cygwin*)
+    if ! test -d $srcdir/cygwin; then
+      AC_MSG_ERROR("No cygwin dir.  Can't build Cygwin.  Exiting...")
+    fi
+    AC_CONFIG_SUBDIRS(cygwin)
+    INSTALL_LICENSE="install-license"
+    ;;
+  *mingw*)
+    if ! test -d $srcdir/mingw; then
+      AC_MSG_ERROR("No mingw dir.  Can't build Mingw.  Exiting...")
+    fi
+    ;;
+esac
+
 if test -d $srcdir/mingw; then
   AC_CONFIG_SUBDIRS(mingw)
 fi
+AC_CONFIG_SUBDIRS(w32api)
 
 case "$with_cross_host" in
   ""|*cygwin*)
@@ -54,6 +73,8 @@ case "$with_cross_host" in
     ;;
 esac
 
+AC_SUBST(INSTALL_LICENSE)
+
 AC_PROG_MAKE_SET
 
 AC_OUTPUT(Makefile)
Index: winsup/mingw/Makefile.in
===================================================================
RCS file: /cvs/src/src/winsup/mingw/Makefile.in,v
retrieving revision 1.63
diff -u -p -r1.63 Makefile.in
--- winsup/mingw/Makefile.in	3 Jul 2006 10:32:58 -0000	1.63
+++ winsup/mingw/Makefile.in	29 Aug 2006 09:45:13 -0000
@@ -28,6 +28,7 @@ objdir = .
 host_alias = @host_alias@
 build_alias = @build_alias@
 target_alias = @target_alias@
+with_cross_host = @with_cross_host@
 prefix = @prefix@
 conf_prefix = @prefix@
 
@@ -53,11 +54,18 @@ inst_includedir:=$(tooldir)/include/ming
 inst_libdir:=$(tooldir)/lib/mingw
 inst_docdir:=$(tooldir)/share/doc/mingw-runtime
 else
+ifneq (,$with_cross_host)
+inst_bindir:=$(tooldir)/bin
+inst_includedir:=$(tooldir)/include
+inst_libdir:=$(tooldir)/lib
+inst_docdir:=$(tooldir)/share/doc/mingw-runtime
+else
 inst_bindir:=$(bindir)
 inst_includedir:=$(includedir)
 inst_libdir:=$(libdir)
 inst_docdir:=$(prefix)/doc/mingw-runtime
 endif
+endif
 
 # The Mingw headers are installed under a subdirectory of
 # $(tooldir)/include when configuring in Cygwin.
@@ -71,7 +79,9 @@ INSTALL_PROGRAM = @INSTALL_PROGRAM@
 mkinstalldirs = $(SHELL) @MKINSTALLDIRS@
 
 CC := @CC@
+ifneq (,$(findstring cygwin,$(target_alias)))
 override CC := ${filter-out -L% -B%,${shell echo $(CC) | sed -e 's%\(-isystem\|-iwithprefixbefore\)  *[^ ]*\( \|$$\)% %g'}}
+endif
 # FIXME: Which is it, CC or CC_FOR_TARGET?
 CC_FOR_TARGET = $(CC)
 AS_FOR_TARGET = $(AS)
Index: winsup/mingw/configure.in
===================================================================
RCS file: /cvs/src/src/winsup/mingw/configure.in,v
retrieving revision 1.12
diff -u -p -r1.12 configure.in
--- winsup/mingw/configure.in	18 Jun 2006 23:06:56 -0000	1.12
+++ winsup/mingw/configure.in	29 Aug 2006 09:45:13 -0000
@@ -19,12 +19,15 @@ dnl Foundation, Inc., 59 Temple Place - 
 AC_PREREQ(2.59)
 AC_INIT(dllmain.c)
 
+AC_CANONICAL_SYSTEM
+GCC_NO_EXECUTABLES
 LIB_AC_PROG_CC
 
 case "$with_cross_host" in
   ""|*cygwin*) all_dlls_host='all_dlls_host'
 	       install_dlls_host='install_dlls_host';;
 esac
+AC_SUBST(with_cross_host)
 AC_SUBST(all_dlls_host)
 AC_SUBST(install_dlls_host)
 
@@ -44,9 +47,12 @@ AC_SUBST(DLLWRAP)
 AC_CHECK_TOOL(WINDRES, windres, windres)
 AC_SUBST(WINDRES)
 
-AC_ALLOCA
+case "$with_cross_host" in
+  ""|*mingw*|*cygwin*)
+    AC_ALLOCA
+    ;;
+esac
 
-AC_CANONICAL_SYSTEM
 AC_CONFIG_SUBDIRS(profile mingwex)
 HEADER_SUBDIR=""
 
Index: winsup/w32api/configure.in
===================================================================
RCS file: /cvs/src/src/winsup/w32api/configure.in,v
retrieving revision 1.5
diff -u -p -r1.5 configure.in
--- winsup/w32api/configure.in	24 May 2006 16:59:03 -0000	1.5
+++ winsup/w32api/configure.in	29 Aug 2006 09:45:13 -0000
@@ -20,6 +20,7 @@ CFLAGS=${CFLAGS-"-O2 -g"}
 AC_CHECK_TOOL(CC, gcc, gcc)
 AC_SUBST(CC)
 AC_SUBST(CFLAGS)
+AC_SUBST(with_cross_host)
 
 dnl check for various tools
 AC_CHECK_TOOL(AR, ar, ar)
Index: winsup/w32api/lib/Makefile.in
===================================================================
RCS file: /cvs/src/src/winsup/w32api/lib/Makefile.in,v
retrieving revision 1.41
diff -u -p -r1.41 Makefile.in
--- winsup/w32api/lib/Makefile.in	22 Jul 2006 12:06:11 -0000	1.41
+++ winsup/w32api/lib/Makefile.in	29 Aug 2006 09:45:13 -0000
@@ -21,6 +21,7 @@ subdirs := ddk directx
 host_alias = @host@
 build_alias = @build@
 target_alias = @target@
+with_cross_host = @with_cross_host@
 prefix = @prefix@
 includedir:=@includedir@
 
@@ -43,9 +44,14 @@ ifneq (,$(findstring cygwin,$(target_ali
 inst_includedir:=$(tooldir)/include/w32api
 inst_libdir:=$(tooldir)/lib/w32api
 else
+ifneq (,$with_cross_host)
+inst_includedir:=$(tooldir)/include/w32api
+inst_libdir:=$(tooldir)/lib
+else
 inst_includedir:=$(includedir)
 inst_libdir:=$(libdir)
 endif
+endif
 
 INSTALL = @INSTALL@
 INSTALL_DATA = @INSTALL_DATA@
Index: winsup/w32api/lib/ddk/Makefile.in
===================================================================
RCS file: /cvs/src/src/winsup/w32api/lib/ddk/Makefile.in,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile.in
--- winsup/w32api/lib/ddk/Makefile.in	25 Nov 2002 18:14:25 -0000	1.3
+++ winsup/w32api/lib/ddk/Makefile.in	29 Aug 2006 09:45:13 -0000
@@ -17,6 +17,7 @@ VPATH = @srcdir@
 host_alias = @host@
 build_alias = @build@
 target_alias = @target@
+with_cross_host = @with_cross_host@
 prefix = @prefix@
 includedir:=@includedir@
 
@@ -39,9 +40,14 @@ ifneq (,$(findstring cygwin,$(target_ali
 inst_includedir:=$(tooldir)/include/w32api/ddk
 inst_libdir:=$(tooldir)/lib/w32api
 else
+ifneq (,$with_cross_host)
+inst_includedir:=$(tooldir)/include/w32api/ddk
+inst_libdir:=$(tooldir)/lib
+else
 inst_includedir:=$(includedir)/ddk
 inst_libdir:=$(libdir)
 endif
+endif
 
 INSTALL = @INSTALL@
 INSTALL_DATA = @INSTALL_DATA@
Index: winsup/w32api/lib/directx/Makefile.in
===================================================================
RCS file: /cvs/src/src/winsup/w32api/lib/directx/Makefile.in,v
retrieving revision 1.2
diff -u -p -r1.2 Makefile.in
--- winsup/w32api/lib/directx/Makefile.in	5 May 2006 19:17:05 -0000	1.2
+++ winsup/w32api/lib/directx/Makefile.in	29 Aug 2006 09:45:13 -0000
@@ -17,6 +17,7 @@ VPATH = @srcdir@
 host_alias = @host@
 build_alias = @build@
 target_alias = @target@
+with_cross_host = @with_cross_host@
 prefix = @prefix@
 includedir:=@includedir@
 
@@ -39,9 +40,14 @@ ifneq (,$(findstring cygwin,$(target_ali
 inst_includedir:=$(tooldir)/include/w32api
 inst_libdir:=$(tooldir)/lib/w32api
 else
+ifneq (,$with_cross_host)
+inst_includedir:=$(tooldir)/include/w32api
+inst_libdir:=$(tooldir)/lib
+else
 inst_includedir:=$(includedir)
 inst_libdir:=$(libdir)
 endif
+endif
 
 INSTALL = @INSTALL@
 INSTALL_DATA = @INSTALL_DATA@

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat