From: Michael G. <mg...@te...> - 2006-07-24 12:13:49
|
Hi ! During my recent tests regarding dbginfo in mingw gcc libs I realized I can't create a linux hosted xcompiler incorporating mingw-runtime-3.10 I think I have found the cause of the problem: There have been extensive updates to configure when going from 3.9 to 3.10. Among these is starting in line 1673 of configure a test trying to figure out the default output file name of the compiler. Unfortunately the test fails because crt2.o does not yet exist as it is created from crt1.c _after_ configure && make have been run. There may be more problems but that's all I have encountered so far. Not very knowledgeable with the autotool chain I'd like to ask someone in the know: Is there a way to skip this test at this point in time ? Or how would I have to adjust configure/configure.in to rearrange the test ? Any insight appreciated, 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: Keith M. <kei...@us...> - 2006-07-28 20:39:10
|
On Monday 24 July 2006 1:14 pm, Michael Gerdau wrote: > During my recent tests regarding dbginfo in mingw gcc libs I realized > I can't create a linux hosted xcompiler incorporating > mingw-runtime-3.10 > > I think I have found the cause of the problem: > There have been extensive updates to configure when going from > 3.9 to 3.10. I believe those are mostly just a natural consequence of using a newer version of autoconf (2.59) than had been used previously (2.13?) to generate configure. Please post your config.log, so I can see what is causing this failure... > Among these is starting in line 1673 of configure a > test trying to figure out the default output file name of the > compiler. We are talking about the configure script in the src/winsup/mingw directory on sourceware.org, are we not? That test would appear to be the standard autoconf boilerplate from AC_PROG_CC, at the point where it identifies the appropriate substitution for EXEEXT. > Unfortunately the test fails because crt2.o does not yet exist > as it is created from crt1.c _after_ configure && make have been > run. Without seeing your config.log, I can't be sure, but that test wouldn't normally depend on the prior existence of *any* particular object module. However, here we are compiling the runtime libraries needed to support the compiler itself -- libraries which are automatically linked into any executable which the cross compiler itself compiles. Now, as part of this AC_PROG_CC test, configure checks to confirm that the compiler can actually generate executables which we can run. Of course, since this is a *cross* compiler, we will not be able to run those executables, so we need to tell configure to skip this part of the test; we do that by passing `--build' and `--host' specifications, with *different* values of the host triplet to configure, thus notifying it that we are cross compiling. IIRC, the mechanism for notifying configure that we are cross compiling changed subtly, between autoconf versions 2.13 and 2.5x, so I'd guess that the cross compiler build script simply isn't passing the appropriate `--build' and `--host' specifications to configure, to conform to the newer standard, when it configures for cross compiling the runtime libraries. Regards, Keith. |
From: Keith M. <kei...@us...> - 2006-08-12 15:09:03
|
On Monday 24 July 2006 1:14 pm, Michael Gerdau wrote: > During my recent tests regarding dbginfo in mingw gcc libs I realized > I can't create a linux hosted xcompiler incorporating > mingw-runtime-3.10 Michael, I too am experiencing difficulties in this area, but I am seeing very different symptoms from those you report, and even very different behaviours across differing Linux host variants; perhaps Danny, or Chris Faylor could comment on the symptoms of failure I've observed. I'm using your script, and I've set it up thus: # Directories:-- # PACKAGE_DIR=$HOME/packages/mingw-3.4.5 BUILD_ROOT=$HOME/sandbox/mingw/build/mingw-3.4.5 PREFIX=$HOME/sandbox/mingw/staged # # Package Versions:-- # GCC_VERSION="3.4.5-20060117-1" BINUTILS_VERSION="2.17.50-20060716-1" W32API_VERSION="3.7" RUNTIME_VERSION="3.10" Now, running the script on my aged Mandrake 8.2 host, where the native compiler is gcc-2.96, this configuration gives me an i586-mingw32-gcc in $HOME/sandbox/mingw/staged, which appears to work correctly, creating executables which I can run under Wine. However, `gcov' support still isn't working correctly; I get a `.gcno' file from the compiler, but no `.gcda' file when I run it under Wine. Running this identical script on a SUSE-10.0 host, where the native compiler is gcc-4.0.2 fails to build a working i586-mingw32-gcc, and also reveals some deficiencies in the script. First, the symptom of failure: make[1]: Entering directory `/home/keith/sandbox/build/mingw/gcc/BUILD-gcc/i586-mingw32/libstdc++-v3' make[1]: *** No rule to make target `install'. Stop. make[1]: Leaving directory `/home/keith/sandbox/build/mingw/gcc/BUILD-gcc/i586-mingw32/libstdc++-v3' make: *** [install-target-libstdc++-v3] Error 2 Now, the first deficiency in the script: on failing thus, the script proceeds to blow away *all* history of the build, removing any opportunity to analyse, and diagnose the fault. Ok, by setting `do_clean=0' early in the script, I can work around that problem, but it would be better if the script didn't clean up so aggressively, in the event of failure. Secondly, after running again with `do_clean=0', I am able to inspect the build tree, and I find no Makefile in the `libstdc++-v3' directory; on further investigation of the `config.log', I find that the configure script aborted prematurely, without creating one. This *should* have been the show stopper, but no, the script carried on running until the later `make install' failure; in a script which runs for close to ninety minutes, this is not very nice :-( Danny, FWIW, the `config.log' is littered with reports of fatal redefinitions of `exit(int)' throwing different exceptions; is this in some way significant? Is it just not possible to build a gcc-3.x cross with a native gcc-4.x? I've also tried to run this identical script on my Ubuntu-6.06 laptop, where the native compiler is gcc-4.0.3; here I see a completely different, and perhaps more disturbing symptom of failure: make[1]: Entering directory `/home/keith/sandbox/mingw/build/gcc/BUILD-gcc/gcc' /home/keith/sandbox/mingw/build/gcc/BUILD-gcc/gcc/xgcc \ -B/home/keith/sandbox/mingw/build/gcc/BUILD-gcc/gcc/ \ -B/home/keith/mingw/i586-mingw32/bin/ \ -B/home/keith/mingw/i586-mingw32/lib/ \ -isystem /home/keith/mingw/i586-mingw32/include \ -isystem /home/keith/mingw/i586-mingw32/sys-include \ -O2 -DIN_GCC -DCROSS_COMPILE \ -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes \ -Wold-style-definition -isystem ./include \ -I. -I. -I../../gcc-3.4.5-20060117-1/gcc -I../../gcc-3.4.5-20060117-1/gcc/. \ -I../../gcc-3.4.5-20060117-1/gcc/../include \ -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions \ -fno-zero-initialized-in-bss -fno-unit-at-a-time -fno-omit-frame-pointer \ -Dinhibit_libc -c ../../gcc-3.4.5-20060117-1/gcc/crtstuff.c -DCRT_BEGIN \ -o crtbegin.o /tmp/ccA0qU2d.s: Assembler messages: /tmp/ccA0qU2d.s:5: Error: unknown pseudo-op: `.def' /tmp/ccA0qU2d.s:5: Error: unknown pseudo-op: `.scl' /tmp/ccA0qU2d.s:5: Error: unrecognized symbol type "" /tmp/ccA0qU2d.s:5: Error: junk at end of line, first unrecognized character is `3' /tmp/ccA0qU2d.s:5: Error: unknown pseudo-op: `.endef' /tmp/ccA0qU2d.s:11: Error: unknown pseudo-op: `.def' /tmp/ccA0qU2d.s:11: Error: unknown pseudo-op: `.scl' /tmp/ccA0qU2d.s:11: Error: unrecognized symbol type "" /tmp/ccA0qU2d.s:11: Error: junk at end of line, first unrecognized character is `3' /tmp/ccA0qU2d.s:11: Error: unknown pseudo-op: `.endef' make[1]: *** [crtbegin.o] Error 1 make[1]: Leaving directory `/home/keith/sandbox/mingw/build/gcc/BUILD-gcc/gcc' make: *** [install-gcc] Error 2 Any thoughts? Regards, Keith. |
From: Michael G. <mg...@te...> - 2006-08-12 20:39:06
|
Hi Keith ! Sorry to not have reacted on your earlier mail -- I just returned from a 2 weeks vacation this weekend and didn't manage to further investigate prior to that. Currently I'm still catching up with my emails... [problems creating a mingw gcc-3.4.5 toolchain with runtime-3.10] > I too am experiencing difficulties in this area, but I am seeing very=20 > different symptoms from those you report, and even very different=20 > behaviours across differing Linux host variants; perhaps Danny, or=20 > Chris Faylor could comment on the symptoms of failure I've observed. =46WIW I'm on SuSE 9.3 with gcc 3.3.5-prerelease. For me it works as long as I stick with runtime-3.9 (newest binutils and all other components). > Now, running the script on my aged Mandrake 8.2 host, where the native=20 > compiler is gcc-2.96, this configuration gives me an i586-mingw32-gcc in= =20 > $HOME/sandbox/mingw/staged, which appears to work correctly, creating=20 > executables which I can run under Wine. However, `gcov' support still=20 > isn't working correctly; I get a `.gcno' file from the compiler, but no=20 > `.gcda' file when I run it under Wine. Interesting. > Running this identical script on a SUSE-10.0 host, where the native=20 > compiler is gcc-4.0.2 fails to build a working i586-mingw32-gcc, Huh ! > and also reveals some deficiencies in the script. [snip] > Now, the first deficiency in the script: on failing thus, the script=20 > proceeds to blow away *all* history of the build, removing any=20 > opportunity to analyse, and diagnose the fault. [snip] > Secondly, after running again with `do_clean=3D0', I am able to inspect t= he=20 > build tree, and I find no Makefile in the `libstdc++-v3' directory; on=20 > further investigation of the `config.log', I find that the configure=20 > script aborted prematurely, without creating one. This *should* have=20 > been the show stopper, but no, the script carried on running until the=20 > later `make install' failure; Right. My private version of the script does address most of these as I have been a victim of them myself. However since it is still work in progress I did not yet update the script in the wiki. > Danny, FWIW, the `config.log' is littered with reports of fatal=20 > redefinitions of `exit(int)' throwing different exceptions; is this in=20 > some way significant? Is it just not possible to build a gcc-3.x cross=20 > with a native gcc-4.x? I don't see these using a native gcc 3.3.5 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 ? > I've also tried to run this identical script on my Ubuntu-6.06 laptop,=20 > where the native compiler is gcc-4.0.3; here I see a completely=20 > different, and perhaps more disturbing symptom of failure: [errors regarding unknown asm pseudo-ops skipped] > Any thoughts? =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: Keith M. <kei...@us...> - 2006-08-13 13:41:21
|
Hi Michael, Hope you enjoyed your holiday, and are fit, rested and eager to get back to the grindstone. :-) On Saturday 12 August 2006 9:39 pm, Michael Gerdau wrote: > > Danny, FWIW, the `config.log' is littered with reports of fatal > > redefinitions of `exit(int)' throwing different exceptions; is this > > in some way significant? Is it just not possible to build a gcc-3.x > > cross with a native gcc-4.x? > > I don't see these using a native gcc 3.3.5 AIUI, gcc-4.x is a great deal more stringent in standards enforcement than any gcc-3.x version ever was. Autoconf-2.60 no longer uses `exit' calls in any of it's macros, presumably because of such problems. > 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 ? No, it's a fundamental component of the test for a working compiler. However, since this occurs at the stage where you are now using the cross compiler you just built, to compile its support libraries for the foreign host, it should not need any of those libraries to pre-exist. The standard test, for a compile with `host == build', runs a check to ensure that the compiler generates working executables; it should automatically skip that check, when `host != build', (i.e. for the cross compiling case). It seems that, in your case, the test is not correctly identifying that you are cross compiling at this stage. I would need to examine your `config.log' to understand why that might be, but FWIW, I am not seeing that problem on my Mandrake 8.2 box, and I don't think I'm getting to that stage on either of my more recent hosts. BTW, I see apparently identical behaviour, regardless of whether I use runtime-3.9 or runtime-3.10. Regards, Keith. |
From: Keith M. <kei...@us...> - 2006-08-26 08:15:47
|
On Thursday 17 August 2006 6:50 pm, Michael Gerdau wrote: > I have done some more work on this. Attached to this mail you'll find > my current version of the build-script together with the patch to fix > the bugs in math.h (as had been reported on the userlist) as well as > config.log for the following 4 testcase: Thanks, Michael. I've not had time for an in-depth study yet, but here are some initial observations: > I have run configure for runtime with the following options: > 1) host=i686-pc-linux-gnu build=i686-pc-mingw32 > 2) host=i686-pc-mingw32 build=i686-pc-linux-gnu > 3) host=i686-pc-mingw32 build=i686-pc-mingw32 > 4) host=i686-pc-linux-gnu build=i686-pc-linux-gnu Ok, I think some clarification of the meanings of `build', `host' and `target' would be helpful, as they relate to the building of our cross-compiler: 1) build this is *always* the platform on which you are running the build process; since we are building on Linux, this is unequivocally going to specify `linux', with the canonical form being `i686-pc-linux-gnu'. 2) host this is a tricky one: it specifies the platform on which whatever we are building is going to be run; for the cross-compiler itself, that's also `i686-pc-linux-gnu', but when we get to the stage of building the runtime support libraries to go with that cross-compiler, they must contain code which will run on the `i686-pc-mingw32' host, so the `host' specification should change to this, for the `runtime' and `w32api' stages of the build. 3) target this is probably the one which causes the most confusion; it is only relevant when building a cross-compiler, and it specifies where the code which is built by that cross-compiler itself will ultimately run; it should not need to be specified at all, for the `runtime' or `w32api', since these are already targetted to `i686-pc-mingw32' by a correct `host' specification. Given these definitions, your case `4' is correct for building the cross-compiler itself, with case `2' being correct for the `runtime' and `w32api' components. Cases `1' and `3' would apply only if you were running the build process itself on a Win32 box. Note also, that cases `3' and `4' are *not* cross-compiling cases. > target=i686-pc-mingw32 in all 4 cases. As noted above, this is relevant only with case `4', when configuring the cross-compiler. Normally, it wouldn't be required at all, when building `runtime' or `w32api', but I think it's harmless to specify it anyway. > For case 1 and 4 I have set CC=i686-pc-linux-gnu-gcc since otherwise > it would use my native gcc for compiling. This would also represent a native compiler, which is of course what you want when building the cross-compiler itself, but not when you build the `runtime' and `w32api' components, by which stage you should have switched to `CC=i686-pc-mingw32-gcc', (assuming that the cross-compiler is built with that name); but `configure' should be able to work that out for itself, given the correct combination of `--build=i686-pc-linux-gnu' and `--host=i686-pc-mingw32' specifications. BTW, what you specify in `--host=...' is internally assigned, within `configure', to a shell variable called `host_alias'. There is another internal variable called `host', which may be set equal to `$host_alias', or it may be translated to the canonical equivalent, if `configure.ac' or `configure.in' specifies `AC_CANONICAL_HOST'. Regardless of how `host' is defined, `configure' will always look for compilers and tools with `$host_alias-' prefixed to their name, e.g. `CC=$host_alias-gcc', falling back to the naked name, only if the qualified variant isn't found. Thus, you should always specify `--host', if you need it at all, to correctly identify the prefix you've used to name your own cross-compiler tool chain: that may not necessarily be the full canonical host name, and indeed, the default in our build script requires `--host=i586-mingw32', and not `--host=i686-pc-mingw32'. Hope to have more, when I've had a chance to examine your config.log files in more detail. Since case `2' is the relevant one, I'll focus on that, in the first instance. Best regards, Keith. |
From: Keith M. <kei...@us...> - 2006-08-26 08:33:47
|
Hi Michael, On Friday 25 August 2006 11:43 am, Michael Gerdau wrote: > Meanwhile I have a SuSE 10.1 with newer autotools available... Nice! But, unless you are running autoconf to regenerate configure scripts, or automake to regenerate Makefiles, the newer autotools shouldn't have any impact; does cross building GCC require these components to be regenerated? > ...and am > experiencing presumably the same problems as you with building the > crossversion of binutils. > > After some searching I think I have found a workaround: > Pretty early (about line 75) in the script I recently mailed you are > the lines > # Which compiler to use > export CC="gcc" > After changing these to > # Which compiler to use > export CC="gcc" > export AR="ar" > export NM="nm" > I could successfully build the cross binutils. I've tried that on my Ubuntu-6.06 host, but still see the same invalid assembly code errors. I'll have to reboot this box into SUSE-10.0, to try on that; I'll do so shortly. > I'm not once again stuck with compiling mingw-runtime... :-( Well, some success at least. It would still be nice to understand why it was failing before, though. Best regards, Keith. |
From: Michael G. <mg...@te...> - 2006-08-26 17:04:46
|
> > Meanwhile I have a SuSE 10.1 with newer autotools available... >=20 > Nice! But, unless you are running autoconf to regenerate configure=20 > scripts, or automake to regenerate Makefiles, the newer autotools=20 > shouldn't have any impact; does cross building GCC require these=20 > components to be regenerated? Not that I'm aware. However configure itself seems to behave differently. Or that's my impression. But then I have not tried to compare the logs of different runs to really check that. Ok, just had a brief look at an older log: all the native tools are "correctly" identified in the older version. E.g. first a check for i686-pc-linux-gnu-ar (no) and then for plain ar (found). The same goes for all the other tools. Under 10.1 all checks for i686-pc-linux-gnu-* fail but are not followed by checks for the vanilla version. On the other hand all checks for i686-pc-mingw32-* are followed by check for the plain versions which consequently are found which seems to be wrong (at least to me and without trying to carefully understand why that might be correct in a greater picture). Anyway, explicitly setting all required tools directly before running configure does fix that for the crosscompiling case (and according to some webresources I came across this is "expected" or at least known behavior). > > I'm not once again stuck with compiling mingw-runtime... :-( >=20 > Well, some success at least. It would still be nice to understand why it= =20 > was failing before, though. "Strengthened" with the explanations you provided in your other mail I will shortly try to fix the compilation of the runtime libs on my SuSE 10.1. Assuming I'll eventually succeed I'll then try to do the same for a Kubuntu 6.06 (should be able to boot from a CD and use my regular disks from there on :) 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: Keith M. <kei...@us...> - 2006-08-26 22:32:54
|
Hi Michael, On Saturday 26 August 2006 6:04 pm, Michael Gerdau wrote: > > > Meanwhile I have a SuSE 10.1 with newer autotools available... > > > > Nice! But, unless you are running autoconf to regenerate configure > > scripts, or automake to regenerate Makefiles, the newer autotools > > shouldn't have any impact; does cross building GCC require these > > components to be regenerated? > > Not that I'm aware. > > However configure itself seems to behave differently. Or that's > my impression. But then I have not tried to compare the logs of > different runs to really check that. > > Ok, just had a brief look at an older log: > all the native tools are "correctly" identified in the older version. > E.g. first a check for i686-pc-linux-gnu-ar (no) and then for plain > ar (found). The same goes for all the other tools. > > Under 10.1 all checks for i686-pc-linux-gnu-* fail but are not > followed by checks for the vanilla version. That's weird! Since `configure' is a vanilla Bourne shell script, and presumable identically the same in each case, one would expect the same behaviour both times, given the similar results for the searches for the `$host_alias-tools'. > On the other hand all > checks for i686-pc-mingw32-* are followed by check for the plain > versions which consequently are found which seems to be wrong (at > least to me and without trying to carefully understand why that > might be correct in a greater picture). Yes, I tend to agree that this behaviour is wrong; when we are explicitly cross-compiling then we need the `$host_alias-tools', and it isn't really acceptable to substitute native tools. This is autoconf behaviour which is probably broken; AFAIK, it is scheduled to disappear from some future version of autoconf, but until then, I guess we must rely on... > Anyway, explicitly setting all required tools directly before > running configure does fix that for the crosscompiling case (and > according to some webresources I came across this is "expected" > or at least known behavior). > > > > I'm not once again stuck with compiling mingw-runtime... :-( > > > > Well, some success at least. It would still be nice to understand > > why it was failing before, though. > > "Strengthened" with the explanations you provided in your other > mail I will shortly try to fix the compilation of the runtime libs > on my SuSE 10.1. Assuming I'll eventually succeed I'll then try to > do the same for a Kubuntu 6.06 (should be able to boot from a CD > and use my regular disks from there on :) For the record, I've now retried the build on my SUSE-10.0 box, with your minor script change, and it still fails in the `libstdc++-v3' configure, aborting before it generates a Makefile. If the relevant `configure' script had bothered to specify a PACKAGE_BUGREPORT address, I would post the `config.log' there for comment. I've also managed to reproduce this same mode of failure on my original Mandrake-8.2 host, where it was previously building successfully. It seems that the earlier build was succeeding because this `configure' was finding the `i586-mingw32-gcc' in PATH, from the original build last year, and using that to complete the current build; remove that original build from PATH, and the new build fails. I think I may also have found an explanation for the different behaviour observed on Ubuntu-6.06 -- I don't have `flex' installed, and this seems to be required to build `binutils'. I'll get that installed, and try again. However, we really do need to improve the error handling in the build script -- this failure occurs very early in the build, which should have been aborted long before it actually was. In fact, the build continued so far beyond this initial failure, that the respective error message had been lost from the display scroll-back buffer. Regards, Keith. |
From: Michael G. <mg...@te...> - 2006-08-27 11:50:43
|
> For the record, I've now retried the build on my SUSE-10.0 box, with your= =20 > minor script change, and it still fails in the `libstdc++-v3' configure,= =20 > aborting before it generates a Makefile. =A0If the relevant `configure'=20 > script had bothered to specify a PACKAGE_BUGREPORT address, I would post= =20 > the `config.log' there for comment. I'm not sure I fully understand that. The `libstdc++-v3' configure comes relatively late in the whole crossbuild process. Here is a rundown as to how it should work, IMO: =A0 1 build xbinutils with native tools (configure, make, make install) =A0 2 copy ("install") w32api and runtime header (xtract and copy) =A0 3 build xgcc (lang=3Dc only) with native tools (configure, make, make i= nstall) =A0 4 build w32api with xgcc (configure, make, make install) =A0 5 build runtime with xgcc (configure, make, make install) =A0 6 build xgcc,xg++,xg77,... with native tools (configure, make, make ins= tall) =A0 7 strip all created libs and objects My build fails during step 5 when using runtime-3.10. It works with runtime-3.9 (both on SuSE 9.3 and 10.1) `libstdc++-v3' configure is part of step 7 and only if you selected to include c++ with your langs (which you usually do :) > I've also managed to reproduce this same mode of failure on my original=20 > Mandrake-8.2 host, where it was previously building successfully. =A0It=20 > seems that the earlier build was succeeding because this `configure' was= =20 > finding the `i586-mingw32-gcc' in PATH, from the original build last=20 > year, and using that to complete the current build; remove that original= =20 > build from PATH, and the new build fails. That's weird. Yesterday I did a complete fresh run and it worked. > I think I may also have found an explanation for the different behaviour= =20 > observed on Ubuntu-6.06 -- I don't have `flex' installed, and this seems= =20 > to be required to build `binutils'. =A0I'll get that installed, and try=20 > again. However, we really do need to improve the error handling in the=20 > build script -- this failure occurs very early in the build, which should= =20 > have been aborted long before it actually was. =A0In fact, the build=20 > continued so far beyond this initial failure, that the respective error=20 > message had been lost from the display scroll-back buffer. Had you tried this with the version I mailed you ? That one is testing the returncode after each configure and each make and in case of error stops and allows you to either continue or break. =46YC I've uploaded my current version (see URL below). On the other hand if configure succeeds although flex is required to build binutils then I think binutils configure is broken and should be fixed. Meanwhile I did another test. I removed two sections from configure: =A0 'checking for C compiler default output file name' (lines 1696-1742) =A0 'checking for suffix of executables' (lines 1790-1815) by enclosing them with "if ( false ); then" and "fi", i.e. =A0 if ( false ); then =A0 <lines 1696-1742> =A0 fi =A0 ... =A0 if ( false ); then =A0 <lines 1790-1815> =A0 fi and now the build process seems to work as expected. Is there a way to achieve that automatically with the stock distribution of runtime ? In the meantime I've created a patch to be applied to runtime's configure by the xcompiler build script. Anyway, I just successfully did a complete fresh build with the script and patches and uploaded it to www.technosis.de/uploads/mingw-cross.zip Unless I hear about problems I'll update the xcompiler script in the Wiki sometime next week. Now back to the problem with the includepath searchorder of the xcompiler which is still there :-( 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: Earnie B. <ea...@us...> - 2006-08-27 13:37:28
|
Quoting Michael Gerdau <mg...@te...>: > > I'm not sure I fully understand that. The `libstdc++-v3' configure comes > relatively late in the whole crossbuild process. Here is a rundown as to > how it should work, IMO: > 1 build xbinutils with native tools (configure, make, make install) > 2 copy ("install") w32api and runtime header (xtract and copy) > 3 build xgcc (lang=c only) with native tools (configure, make, make > install) > 4 build w32api with xgcc (configure, make, make install) > 5 build runtime with xgcc (configure, make, make install) > 6 build xgcc,xg++,xg77,... with native tools (configure, make, make > install) > 7 strip all created libs and objects > > My build fails during step 5 when using runtime-3.10. It works with > runtime-3.9 (both on SuSE 9.3 and 10.1) > IIRC, Chris Sutcliffe updated the package build process between those versions for the runtime. Perhaps something was modified to break a cross compile. Earnie Boyd http://shop.siebunlimited.com |
From: Chris S. <ir0...@gm...> - 2006-08-27 22:39:01
|
> > My build fails during step 5 when using runtime-3.10. It works with > > runtime-3.9 (both on SuSE 9.3 and 10.1) > > IIRC, Chris Sutcliffe updated the package build process between those > versions for the runtime. Perhaps something was modified to break a > cross compile. Here's the specific ChangeLog entries that I believe Earnie is referring to: 2006-06-18 Danny Smith <dan...@us...> * configure.in (AC_CONFIG_AUX_DIR): Remove. * configure: Regenerate. 2006-06-18 Chris Sutcliffe <ir0...@us...> * configure: add srcdir as a possible location for install-sh. I'm not sure if they are contributing to the issue or not. I'm by no means an auto-tools guru, so I can't comment. Chris -- Chris Sutcliffe http://ir0nh34d.googlepages.com http://ir0nh34d.blogspot.com http://emergedesktop.org |
From: Michael G. <mg...@te...> - 2006-08-28 05:49:49
|
> Here's the specific ChangeLog entries that I believe Earnie is referring = to: >=20 > 2006-06-18 Danny Smith <dan...@us...> >=20 > * configure.in (AC_CONFIG_AUX_DIR): Remove. > * configure: Regenerate. >=20 > 2006-06-18 Chris Sutcliffe <ir0...@us...> >=20 > * configure: add srcdir as a possible location for install-sh. >=20 > I'm not sure if they are contributing to the issue or not. I'm by no > means an auto-tools guru, so I can't comment. Keith had mentioned something similar in an earlier mail. From what I understood back then the "new" problems are not so much due to the specific changes as such but presumably due to the use of way newer auto-tools in general. At least that's what I understood. I'm anything but an auto-tools guru myself though. However as far as I understand the problem I'm facing with generating the runtime libs during build the xcompiler it is that I need a way to omit the two checks I currently do patch out of runtime's configure. Both require a fully working xgcc and that one needs a few libs/objs that aren't there until after runtime has been build (a typical bootstrap issue :) Even better would be I could provide defaults via cmdline switches to configure. The tests in question are (see my other mail): =A0 'checking for C compiler default output file name' (lines 1696-1742) =A0 'checking for suffix of executables' (lines 1790-1815) I'd expect such parameters could be added to autoconf but I've never messed with that. Assuming my assumption is right: Any takers ? 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: Keith M. <kei...@us...> - 2006-08-28 12:01:57
|
Hi Michael, On Monday 28 August 2006 6:49 am, Michael Gerdau wrote: > However as far as I understand the problem I'm facing with generating > the runtime libs during build the xcompiler it is that I need a way > to omit the two checks I currently do patch out of runtime's configure. > Both require a fully working xgcc and that one needs a few libs/objs > that aren't there until after runtime has been build (a typical > bootstrap issue :) Yes. The the two checks which are failing are, as you note:-- 'checking for C compiler default output file name' (lines 1696-1742) 'checking for suffix of executables' (lines 1790-1815) Both of these tests are embedded within autoconf's `AC_PROG_CC' macro, so there is no easy way to disable them, at the autoconf level. As you have discovered, you can patch them out of `configure' itself, but that's not really a satisfactory solution--your patch could too easily be rendered invalid, just by the simple action of running autoconf, regenerating `configure' to incorporate some minor (and maybe unrelated) change, or even simply if a different autoconf version is deployed. Furthermore, both of these tests require that the C compiler, xgcc in our case, be able to successfully link a minimal test program--it doesn't need to be able to run it, if cross-compiling, but the link must succeed. In our case, that link step is failing, because xgcc implicitly tries to link in runtime objects which haven't yet been built. Perhaps passing `LDFLAGS=-nostdlib' as a `configure' parameter could help, or maybe we need to prebuild a minimal subset of the runtime objects, before configuring for the complete build. I'll have a play with it, when I can find some spare time. Regards, Keith. |
From: Michael G. <mg...@te...> - 2006-08-28 16:03:30
|
> Perhaps passing `LDFLAGS=3D-nostdlib' as a `configure' parameter could he= lp, Unfortunately is doesn't :-( > or maybe we =20 > need to prebuild a minimal subset of the runtime objects, before=20 > configuring for the complete build. I'll give that a try later today. When we are lucky all we'll need will be crt2.o and that should be somewhat easy to create. I'll report once I've checked that. 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-28 20:44:13
|
Hi list ! Next iteration. > Perhaps passing `LDFLAGS=3D-nostdlib' as a `configure' parameter could he= lp, As I already wrote, that didn't work for me, therefor... > or maybe we need to prebuild a minimal subset of the runtime objects, bef= ore=20 > configuring for the complete build. =2E..I set out to do what Keith suggested as Plan B. I have been successful in that I now can create the xcompiler without patching runtime's configure though I'm not yet sure I like the clutter of commands that achieved it in the end. Whoever is interested may download my updated files from the following URL: www.technosis.de/uploads/mingw-cross.zip Of course I do appreciate comments and enhancements. 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 |