This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] fix bug in autoconf-2.13 that keeps cross gcc from buildingoncygwin


It'd be good for Cygwin to apply the patch, yes.  Then the gcc FAQ could
have an entry
   Q. Why can't I build cross-compilers on Cygwin?
   A. Because the configure scripts shipped with gcc are buggy.
      Regenerate them all under Cygwin, and it should work.

But frankly, the point of configure scripts is to be portable, so
it makes a fair bit of sense for gcc to ship with configure scripts
that are portable even to systems like cygwin.
- Dan

Earnie Boyd wrote:
I suggest that this issue be dealt with within the Cygwin distribution of autoconf-2.13.

Earnie.

Dan Kegel wrote:


[repost -- mail system problems]

Building cross gcc's on cygwin fails because autoconf 2.13's AC_TRY_COMPILER
test assumes that it's ok to try to run possibly cross-compiled binaries,
and that if they run, the compiler must not be a cross-compiler.
This assumption fails on Cygwin; see
  http://www.oarcorp.com/rtems/maillistArchives/rtems-users/1999/may/msg00075.html
  http://gcc.gnu.org/ml/gcc-help/2002-05/msg00165.html
  http://sources.redhat.com/ml/crossgcc/2002-08/msg00099.html
The symptom is the build hangs about twenty times waiting for you to click a dialog box,
and the target directory's ac_cv_prog_cc_cross is improperly set to 'no'.

The problem will likely go away when gcc moves to using autoconf 2.5x, but
that may take a while, and won't help people who need to build oldish
gcc's like 3.0.x.  So it's worth fixing autoconf-2.13 if it's a small, safe fix.

Fortunately, the fix does look small and safe:

--- /usr/share/autoconf2.13/acgeneral.m4.orig   Thu Aug 22 18:26:58 2002
+++ acgeneral.m4        Thu Aug 22 19:03:12 2002
@@ -1510,11 +1510,13 @@
  EOF
  if AC_TRY_EVAL(ac_link) && test -s conftest${ac_exeext}; then
    [$2]=yes
-  # If we can't run a trivial program, we are probably using a cross compiler.
-  if (./conftest; exit) 2>/dev/null; then
-    [$3]=no
-  else
-    [$3]=yes
+  if test "$[$3]" != yes; then
+    # If we can't run a trivial program, we are probably using a cross compiler.
+    if (./conftest; exit) 2>/dev/null; then
+      [$3]=no
+    else
+      [$3]=yes
+    fi
    fi
  else
    echo "configure: failed program was:" >&AC_FD_CC

i.e. after the patch, AC_TRY_COMPILER checks its 3rd parameter,
and if it's already 'yes', it knows not to run the binaries.

After applying this patch to autoconf-2.13 and installing,
you then need to regenerate libiberty/configure,
gcc/configure and fastjar/configure.  It might be good if future releases
of gcc that still used autoconf-2.13 were done on machines with an
autoconf-2.13 with this patch applied.

This is only a partial fix; it requires the user to override
ac_cv_prog_cc_cross.  A similar bug in ltconfig can be worked around
without a patch by overriding cross_compiling=yes in the same way.
Both overrides should only be done during the build of runtime libraries.
Fortunately, gcc's makefile has pseudotargets that let you do this.
For instance:
     make all-gcc
     ac_cv_prog_cc_cross=yes cross_compiling=yes make all-target
     make install

Users on non-cygwin platforms can ignore this issue, and just do
'make install' as usual.  This patch will neither help nor hurt them.

(Note that overriding ac_cv_prog_cc_cross at make time appears to be sufficient.
Although it would be more logical to override them when doing initial
configuration of gcc, that wouldn't let you work around the ltconfig bug.)

Even if future autoconf and gcc releases don't apply this patch, maybe
this post will help people who need to build gcc on cygwin.

- Dan

http://www.kegel.com




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