[RFC] Simplify MinGW canadian crosses

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

[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

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
MinGW-patches mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-patches
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Simplify MinGW canadian crosses

Daniel Jacobowitz-2
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

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
MinGW-patches mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-patches
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Simplify MinGW canadian crosses

DJ Delorie-2
In reply to this post by Corinna Vinschen

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

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
MinGW-patches mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-patches
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Simplify MinGW canadian crosses

DJ Delorie-2
In reply to this post by Daniel Jacobowitz-2

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

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
MinGW-patches mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-patches
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Simplify MinGW canadian crosses

Daniel Jacobowitz-2
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

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
MinGW-patches mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-patches
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Simplify MinGW canadian crosses

DJ Delorie-2

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

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
MinGW-patches mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-patches
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Simplify MinGW canadian crosses

Daniel Jacobowitz-2
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

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
MinGW-patches mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-patches
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Simplify MinGW canadian crosses

Corinna Vinschen
In reply to this post by Daniel Jacobowitz-2
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

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
MinGW-patches mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-patches
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Simplify MinGW canadian crosses

DJ Delorie-2
In reply to this post by Daniel Jacobowitz-2

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.

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
MinGW-patches mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-patches
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Simplify MinGW canadian crosses

Christopher Faylor-9
In reply to this post by Corinna Vinschen
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

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
MinGW-patches mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-patches
Reply | Threaded
Open this post in threaded view
|

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

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
MinGW-patches mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-patches
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Simplify MinGW canadian crosses

Daniel Jacobowitz-2
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

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
MinGW-patches mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-patches
Reply | Threaded
Open this post in threaded view
|

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

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
MinGW-patches mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-patches
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Simplify MinGW canadian crosses

Christopher Faylor-9
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

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
MinGW-patches mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-patches
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Simplify MinGW canadian crosses

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

cgf

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
MinGW-patches mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-patches
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Simplify MinGW canadian crosses

Corinna Vinschen
In reply to this post by 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

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
MinGW-patches mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-patches
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Simplify MinGW canadian crosses

Corinna Vinschen
In reply to this post by 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

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
MinGW-patches mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-patches
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Simplify MinGW canadian crosses

Keith Marshall-3
In reply to this post by Corinna Vinschen
On Sunday 03 September 2006 9:13 am, Keith Marshall wrote:
> On Wednesday 30 August 2006 2:59 pm, Christopher Faylor wrote:
> > FWIW, I forwarded Corinna most of the discussion from this list so
> > she was aware of the problem.
>
> I'm coming somewhat late to this particular party.  I guess I should
> have been subscribed to mingw-patches, but wasn't; we normally discuss
> this sort of thing on mingw-dvlpr.

Just to add my two pennyworth...

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?

and Daniel Jacobowitz replied:
> If you do that it'll just emit a sinclude into aclocal.m4 anyway, won't
> it?

FWIW, aclocal will *never* emit `sinclude'; but that's being pedantic,
for it *might* emit `m4_include', which amounts to the same thing.

What aclocal actually does emit depends on whether the path to the
sourced file is specified with an absolute or a relative path; the
`m4_include' form would be seen with a relative path, while using an
absolute path results in verbatim copying of the source into aclocal.m4.

It is important that mingw-runtime continues to be maintained as a stand
alone package; (I checked it out of CVS, as a separate module).  Thus, as
Corinna points out, it is not appropriate to `m4_include' no-executables
from its current location in the tree, (which would actually be
`../../config/no-executables.m4' in this case); if you want to
`m4_include' it, then you must maintain a separate copy *within* the
mingw-runtime package tree itself, say in a new `./m4' directory, but
since aclocal.m4 can itself be reduced to no more than a verbatim copy of
no-executables.m4, that would seem to be overkill.

Just for the record, I personally prefer to maintain aclocal.m4 by hand,
rather than generate it using the aclocal tool--which is not an autoconf
tool, BTW; it is provided by automake, which I utterly loathe and detest.
Whle aclocal may be convenient, it is also an excellent way to carelessly
drag in needless dependencies--as an example, consider the GNU libiconv
autoconfigury, which forces you to distribute config.guess, config.sub
and config.rpath, together with about half a dozen unnecessary m4 files,
along with your project, but none of these are essential for a basic
libiconv client, and by handcrafting aclocal.m4, I can easily eliminate
the unnecessary dependencies.  (Of course, it isn't the aclocal tool that
is particularly at fault here--it is a consequence of carelessly written
m4 sources in the first instance--but using aclocal is lazy, and tends to
conceal this initial carelessness).

Regards,
Keith.

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
MinGW-patches mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-patches
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Simplify MinGW canadian crosses

Christopher Faylor
On Sun, Sep 03, 2006 at 11:07:27AM +0100, Keith Marshall wrote:

>Just for the record, I personally prefer to maintain aclocal.m4 by
>hand, rather than generate it using the aclocal tool--which is not an
>autoconf tool, BTW; it is provided by automake, which I utterly loathe
>and detest.  Whle aclocal may be convenient, it is also an excellent
>way to carelessly drag in needless dependencies--as an example,
>consider the GNU libiconv autoconfigury, which forces you to distribute
>config.guess, config.sub and config.rpath, together with about half a
>dozen unnecessary m4 files, along with your project, but none of these
>are essential for a basic libiconv client, and by handcrafting
>aclocal.m4, I can easily eliminate the unnecessary dependencies.  (Of
>course, it isn't the aclocal tool that is particularly at fault
>here--it is a consequence of carelessly written m4 sources in the first
>instance--but using aclocal is lazy, and tends to conceal this initial
>carelessness).

While I agree 100% about automake (I'm not a big fan of autoconf
either), I don't think that it makes sense to hand-craft aclocal.m4.
IMO, if you have a bunch of people updating aclocal.m4 in their own
idiosyncratic way, you are just asking for trouble.  If acinclude.m4
is kept relatively simple, I don't see the harm in using aclocal to
generate all of the aclocal.m4's in the winsup tree.

cgf

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
MinGW-patches mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-patches