Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Danny Smith <dannysmith@clear.net.nz>
To: GCC-patches <gcc-patches@gcc.gnu.org>,
	Binutils <binutils@sourceware.org>,
	 gdb-patches@sourceware.org
Subject: RE: [RFC] Simplify MinGW canadian crosses
Date: Wed, 30 Aug 2006 20:32:00 -0000	[thread overview]
Message-ID: <002701c6cc14$ee7f4c10$ad6d65da@anykey> (raw)

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


             reply	other threads:[~2006-08-30  9:16 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-30 20:32 Danny Smith [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-08-29 13:04 Corinna Vinschen
2006-08-29 13:06 ` Daniel Jacobowitz
2006-08-29 15:32   ` DJ Delorie
2006-08-29 15:35     ` Daniel Jacobowitz
2006-08-29 15:38       ` DJ Delorie
2006-08-29 15:44         ` Daniel Jacobowitz
2006-08-29 16:00           ` DJ Delorie
2006-08-29 15:47       ` Corinna Vinschen
2006-08-29 16:04         ` Daniel Jacobowitz
2006-08-29 16:09           ` Corinna Vinschen
2006-08-29 16:53             ` Daniel Jacobowitz
2006-08-29 17:51               ` Corinna Vinschen
2006-08-29 16:08         ` Christopher Faylor
2006-08-29 16:49           ` Corinna Vinschen
2006-08-29 17:01             ` Daniel Jacobowitz
2006-08-29 17:04               ` Corinna Vinschen
2006-08-29 18:35                 ` Christopher Faylor
2006-08-30  9:16                   ` Christopher Faylor
2006-08-30 12:33                 ` Corinna Vinschen
2006-08-29 15:24 ` DJ Delorie
2006-08-31 11:34 ` Corinna Vinschen
2006-08-31 12:09   ` Danny Smith

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='002701c6cc14$ee7f4c10$ad6d65da@anykey' \
    --to=dannysmith@clear.net.nz \
    --cc=binutils@sourceware.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox