From: Danny S. <dan...@cl...> - 2006-08-29 21:01:55
|
> What I see is the test to determine the default executable > extension (presumably .exe) fails because the link step needs > crt2.o which is not yet there at this point in time -- at > first glance it seems like a bootstrapping problem. > > Is there a way to skip over that particular test at that stage ? > http://sourceware.org/ml/binutils/2006-08/msg00312.html |
From: Danny S. <dan...@cl...> - 2006-08-30 21:00:40
|
> > > > http://sourceware.org/ml/binutils/2006-08/msg00312.html > > > > I just had a look at it on the train an AFAICS this patchset > > is exactly what I've been looking for. > > It has been installed by Corinna. Danny |
From: Keith M. <kei...@us...> - 2006-08-31 06:00:09
|
On Wednesday 30 August 2006 10:00 pm, Danny Smith wrote: > > > > > > http://sourceware.org/ml/binutils/2006-08/msg00312.html > > > > > > I just had a look at it on the train an AFAICS this patchset > > > is exactly what I've been looking for. > > > > > It has been installed by Corinna. I've not been able to monitor this thread, for a day or two, but I'd also independently tracked down the source of the configure problem, which is definitely due to actions performed by AC_PROC_CC, and I'd also succeeded in resolving it, at the autoconf level, but in a somewhat more simplistic fashion, (see below). Corinna's patch has certainly cleaned up aclocal.m4 considerably, but we can go even further. We do not need any of LIB_AC_PROG_CC_GNU, LIB_AC_PROG_CC or LIB_AC_PROG_CXX; it is sufficient to simply expand GCC_NO_EXECUTABLES *before* expanding the standard AC_PROG_CC, to achieve our objective. In fact, for our immediate purposes it is sufficient to simply m4_define([_AC_COMPILER_EXEEXT],[]) before expanding AC_PROG_CC, but GCC_NO_EXECUTABLES is probably a more robust solution for long term use. BTW, I've now got the beast to build on my Ubuntu-6.06 laptop; I needed to install all of `flex', `bison' and `texinfo', before `binutils' would build successfully. While these dependencies are not unreasonable for building from CVS sources, IMO they should not be prerequisites for building from the source tarballs we distribute from the SF download sites; we *should* include sufficient generated files in the distribution, to eliminate these dependencies. (This would then be consistent with GCC practice itself). Regards, Keith. |
From: Pedro A. <ped...@po...> - 2006-08-30 10:14:56
|
Hi guys! (I'm not on MinGW-dvlpr, so this may not get through...) I've ran into this problem too, while building a arm-wince-mingw32 runtime. The way I've come around it without changing any autoconfigury, was to create a dummy crt2.o and dummy libs (libmingw* and friends). With these in place, when configure tries to make an a.exe to check for the default output filename, etc, it can. Of course the a.exe wouln't run, but that doesn't matter anyway, since we are crosscompiling, and it would never run. With these dummy libs, the steps to build the cross toolchain are: - build/install binutils - build gcc c only (make all-gcc/install-gcc) - run install.sh (install dummy runtime, see below) - build mingw runtime. - build gcc c, c++, etc. --- $ cat crt2.s .text .global __EH_FRAME_BEGIN__ .global _CRT_MT .global __gthread_once .global abort .global GetCurrentThreadId .global TlsFree .global TlsAlloc .global __mingwthr_key_dtor .global atexit __EH_FRAME_BEGIN__: _CRT_MT: __gthread_once: abort: GetCurrentThreadId: TlsFree: TlsAlloc: __mingwthr_key_dtor: atexit: $ cat install.sh #!/bin/sh PREFIX=/usr/local/mingw32ce TARGET=arm-wince-mingw32 LIBDIR=${PREFIX}/${TARGET}/lib AS=${TARGET}-as AR=${TARGET}-ar FAKE_LIBS="libcoldname.a libmingwex.a libmoldname.a libmingw32.a libmingwthrd.a libmoldnamed.a" ${AS} crt2.s -o crt2.o cp -fv crt2.o ${LIBDIR}/crt2.o for lib in $FAKE_LIBS; do rm -f ${LIBDIR}/$lib ${AR} vq ${LIBDIR}/$lib done --- Cheers, Pedro Alves |
From: Michael G. <mg...@te...> - 2006-08-30 05:38:20
|
> > What I see is the test to determine the default executable=20 > > extension (presumably .exe) fails because the link step needs=20 > > crt2.o which is not yet there at this point in time -- at=20 > > first glance it seems like a bootstrapping problem. > >=20 > > Is there a way to skip over that particular test at that stage ? > >=20 > http://sourceware.org/ml/binutils/2006-08/msg00312.html Very interesting post. I'll check it out either today or tomorrow, depending on today's schedule. Best, Michael =2D-=20 Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: mg...@te... GPG-keys available on request or at public keyserver |
From: Michael G. <mg...@te...> - 2006-08-30 07:55:51
|
> > What I see is the test to determine the default executable=20 > > extension (presumably .exe) fails because the link step needs=20 > > crt2.o which is not yet there at this point in time -- at=20 > > first glance it seems like a bootstrapping problem. > >=20 > > Is there a way to skip over that particular test at that stage ? > >=20 > http://sourceware.org/ml/binutils/2006-08/msg00312.html I just had a look at it on the train an AFAICS this patchset is exactly what I've been looking for. In other words and to answer the question D.J.Delorie asked somewhere in the threat: I'm all for including this patchset. Is there anyone speaking up as MinGW maintainer on the binutils list and and approve of it ? Best, Michael =2D-=20 Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: mg...@te... GPG-keys available on request or at public keyserver |
From: Danny S. <dan...@cl...> - 2006-08-30 09:26:27
|
> > http://sourceware.org/ml/binutils/2006-08/msg00312.html > > I just had a look at it on the train an AFAICS this patchset > is exactly what I've been looking for. > > In other words and to answer the question D.J.Delorie asked > somewhere in the threat: I'm all for including this patchset. > > Is there anyone speaking up as MinGW maintainer on the > binutils list and and approve of it ? I've spoken up on the concerned lists in support of this patch. The changes to mingw and w32api directories do not need top-level approval but I would prefer to advocate that the whole patchset is applied to ensure continued top-level support. Danny > > Best, > Michael |
From: Christopher F. <cgf...@so...> - 2006-08-30 13:59:39
|
On Wed, Aug 30, 2006 at 09:26:16PM +1200, Danny Smith wrote: >> > http://sourceware.org/ml/binutils/2006-08/msg00312.html >> >> I just had a look at it on the train an AFAICS this patchset >> is exactly what I've been looking for. >> >> In other words and to answer the question D.J.Delorie asked >> somewhere in the threat: I'm all for including this patchset. >> >> Is there anyone speaking up as MinGW maintainer on the >> binutils list and and approve of it ? > >I've spoken up on the concerned lists in support of this patch. The >changes to mingw and w32api directories do not need top-level approval >but I would prefer to advocate that the whole patchset >is applied to ensure continued top-level support. Looks like the patches are in. FWIW, I forwarded Corinna most of the discussion from this list so she was aware of the problem. Does this solve all of the reported problems now? cgf |
From: Keith M. <kei...@us...> - 2006-09-03 08:08:46
|
On Wednesday 30 August 2006 2:59 pm, Christopher Faylor wrote: [Re: Corinna Vinschen's patchset, as discussed on mingw-patches] > >I've spoken up on the concerned lists in support of this patch. The > >changes to mingw and w32api directories do not need top-level approval > >but I would prefer to advocate that the whole patchset > >is applied to ensure continued top-level support. > > Looks like the patches are in. > > 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. > Does this solve all of the reported problems now? Seems to resolve the problem. As I'd noted in a previous message, I'd independently arrived at a simplified variation on the same theme, but Corinna's patchset is more comprehensive. I do think, however, that some simplification would be appropriate; the following is ok for MinGW, but would it break anything in Cygwin? 2006-09-?? Keith Marshall <kei...@us...> * aclocal.m4 (LIB_AC_PROG_CC): Redundant macro; deleted. (LIB_AC_PROG_CC_GNU, LIB_AC_PROG_CXX): Likewise. * configure.in (LIB_AC_PROG_CC): Replaced by... (AC_PROG_CC): ...this. * configure: Regenerated. Index: aclocal.m4 =================================================================== RCS file: /cvs/mingw/mingw/aclocal.m4,v retrieving revision 1.2 diff -u -r1.2 aclocal.m4 --- aclocal.m4 30 Aug 2006 13:05:05 -0000 1.2 +++ aclocal.m4 3 Sep 2006 07:50:49 -0000 @@ -1,5 +1,11 @@ -# generated automatically by aclocal 1.9.6 -*- Autoconf -*- - +# aclocal.m4 for MinGW Runtime package. -*- Autoconf -*- +# +# This provides configure definitions used by all the winsup +# configure.in files. +# +# The following is copied from `no-executables.m4', in the top +# `src/config' directory. +# # Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, # 2005 Free Software Foundation, Inc. # This file is free software; the Free Software Foundation @@ -73,47 +79,4 @@ m4_divert_pop()dnl ])# GCC_NO_EXECUTABLES -dnl This provides configure definitions used by all the winsup -dnl configure.in files. - -# FIXME: We temporarily define our own version of AC_PROG_CC. This is -# copied from autoconf 2.12, but does not call AC_PROG_CC_WORKS. We -# are probably using a cross compiler, which will not be able to fully -# link an executable. This should really be fixed in autoconf -# itself. - -AC_DEFUN([LIB_AC_PROG_CC_GNU], -[AC_CACHE_CHECK(whether we are using GNU C, ac_cv_prog_gcc, -[dnl The semicolon is to pacify NeXT's syntax-checking cpp. -cat > conftest.c <<EOF -#ifdef __GNUC__ - yes; -#endif -EOF -if AC_TRY_COMMAND(${CC-cc} -E conftest.c) | egrep yes >/dev/null 2>&1; then - ac_cv_prog_gcc=yes -else - ac_cv_prog_gcc=no -fi])]) - -AC_DEFUN([LIB_AC_PROG_CC], -[AC_BEFORE([$0], [AC_PROG_CPP])dnl -AC_CHECK_TOOL(CC, gcc, gcc) -: ${CC:=gcc} -AC_PROG_CC -test -z "$CC" && AC_MSG_ERROR([no acceptable cc found in \$PATH]) -]) - -AC_DEFUN([LIB_AC_PROG_CXX], -[AC_BEFORE([$0], [AC_PROG_CPP])dnl -AC_CHECK_TOOL(CXX, g++, g++) -if test -z "$CXX"; then - AC_CHECK_TOOL(CXX, g++, c++, , , ) - : ${CXX:=g++} - AC_PROG_CXX - test -z "$CC" && AC_MSG_ERROR([no acceptable cc found in \$PATH]) -fi - -CXXFLAGS='$(CFLAGS)' -]) - +# aclocal.m4: end of file: vim: ft=config Index: configure.in =================================================================== RCS file: /cvs/mingw/mingw/configure.in,v retrieving revision 1.13 diff -u -r1.13 configure.in --- configure.in 30 Aug 2006 13:05:05 -0000 1.13 +++ configure.in 3 Sep 2006 07:50:49 -0000 @@ -21,7 +21,7 @@ AC_CANONICAL_SYSTEM GCC_NO_EXECUTABLES -LIB_AC_PROG_CC +AC_PROG_CC case "$with_cross_host" in ""|*cygwin*) all_dlls_host='all_dlls_host' |
From: Keith M. <kei...@us...> - 2006-09-03 10:03:01
|
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. |
From: Christopher F. <me...@cg...> - 2006-09-03 15:33:36
|
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 |