From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5419 invoked by alias); 1 Jan 2007 15:08:43 -0000 Received: (qmail 5383 invoked by uid 48); 1 Jan 2007 15:08:25 -0000 Date: Mon, 01 Jan 2007 15:08:00 -0000 Subject: [Bug bootstrap/30342] New: Tough time building 4.2.0 (CVS) on WinXP with Cygwin X-Bugzilla-Reason: CC Message-ID: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "rob1weld at aol dot com" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2007-01/txt/msg00008.txt.bz2 I had a lot of trouble getting __everything__ to work. I've tried rebuilding a few times this last month and have managed to get everything (really) working except I can not compile ada (I will try some more). Here is the output of gcc-v : Using built-in specs. Target: athlon_xp-pc-cygwin Configured with: /cygdrive/C/makecygwin/gcc-4_2-branch/configure --disable-werror --verbose --target=athlon_xp-pc-cygwin --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-static --enable-nls --enable-multilib --without-included-gettext --enable-version-specific-runtime-libs --with-gxx-include-dir=/include/c++/4.2.0 --enable-libstdcxx-debug --enable-libgcj --enable-libgcj-debug --enable-java-awt=gtk,xlib --enable-java-gc=boehm --enable-objc-gc --with-system-zlib --enable-threads=posix --without-tls --enable-sjlj-exceptions --enable-hash-synchronization --enable-libada --enable-libssp --enable-libmudflap --enable-win32-registry --with-x --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --with-cpu=athlon-xp --with-arch=athlon-xp --with-tune=athlon-xp athlon_xp-pc-cygwin Thread model: posix gcc version 4.2.0 20061225 (prerelease) I have mudflaps and gomp working on Windows XP. I also used --with-x . Here are some notes for any having trouble enabling every possible flag on WinXP (good for testing but it takes two days to compile). This may be verbose. These notes assume 80 columns - hope this input window does too. I try to fix them up. This is some info to encourage people to attempt to build gcc for Windows XP using the Cygwin environment (get setup program from: http://www.cygwin.com/) . The end result is a new compiler tool chain with "c" and "fortran" that pass almost every test, the "ada" will not build and there are quite a few errors in the other packages. I am enabling ssp, gomp, mudflap, awt - these are not working too badly, but need a maintainer to do some fixing. I have read http://gcc.gnu.org/install/specific.html#windows . It claims "GCC will build under Cygwin without modification". I did not find I was able to build either 4.1.1 release or 4.2.0 prerelease "as is". Hopefully the info that follows will point out some bugs / shortcomings and encourage others to try. The page http://gcc.gnu.org/gcc-4.2/buildstat.html is EMPTY! I will limit much of the following to 4.2.0 ONLY - but to build gcc with Cygwin you can only start from an old version of gcc. The Cygwin Setup program uses gcc 3.4.4-3 as the "newest" version. To go from gcc 3.4.4-3 (release) to 4.2.0 (prerelease) it is advisable to build 4.1.1 (release) along the way. The gcc 3.4.4-3 version is so old that it will reject many of the gcc options that the makefiles pass to it, you don't want to remove to many features. When jumping a "major" version number it is best to use a release version of the same version (4.1.1) to build an experimental version 4.2.0 (prerelease). I know that version 4.1.2 fixes many of the troubles with 4.1.1 but that version was not a 'release' version at the time of this writing and you are going to build 4.2.0 anyway so I do not suggest 4.1.2 but the choice is yours. Make sure you build gcc with "--enable-threads=posix" and NOT "--enable-threads=win32" on Cygwin / Windows XP or you'll find that many Linux / Unix programs will not compile properly. I am enabling (almost) every possible ./configure option possible in my build. If you want to use the same options as I did (to duplicate my test and fix whats broken - HINT to maintainers try compiling gcc for Windows XP) you will need to get the following (I hope this is a complete list - see the installation page http://gcc.gnu.org/install/index.html for more info): 1) Base - select to install everything 2) Devel - autoconf, automake, binutils, bison, byacc, cvs, cvsutils, dejagnu, doxygen, flex, gcc-* (everything starting with the words "gcc-"), gettext, gettext-devel, guile-1.6.7-4 (click the "S" box to get guile source code - don't use a newer version), make, pkg-config, readline, (hope I didn't miss anything). 3) Gnome - atk, glib, gtk, pango 3) Publishing - tetex-* 4) Utils - cygutils, file, patch, time, upx 5) X11 - select to install everything 6) Other - goto http://www.gimp.org/~tml/gimp/win32/downloads.html and get the newest gimp. atk-1.12.3.zip, cairo-1.2.6.zip, glib-2.12.6.zip, gtk+-2.10.6.zip, pango-1.14.8.zip, libiconv-1.9.1.bin.woe32.zip, and gettext-0.14.5.zip. You need both the 'cygwin setup' versions and the 'gimp website' version. You'll need to write .pc files for them and use "cygcheck -c" to make sure they are found. In addition you may want to get "Mortens Cygwin X-Launcher" (to help Windows XP users with X11) from: http://home.arcor.de/martin.halle/archive/cxl_full.zip Read the FAQ at the cygwin site. Use cygcheck to ensure your pkg-config is correct. When running ./configure make sure that configure finds what you have installed - you may need to fix a line or two that I forget to tell you about :) . On the Windows XP platform (for the current version of the bash shell) you MUST use dos2unix on any file you edit with notepad or wordpad otherwise bash will get an error reading it. There is a bit of work to getting cygwin setup to compile the newest version of gcc with ALL the features enables. This preamble is NOT a FAQ for cygwin, just a few tips. You'll need to know how to use cygwin as I'm saving my typing in this post to explain how to compile gcc 4.2.0 not to explain the begining and intermediary steps. After you have cygwin working properly (all C:\cygwin\lib\pkgconfig\*.pc files are correct and new the new gimp files in their own directory with .pc files pointing to them, but the include definitions pointing to cygwin's gimp .h files - unless you want to download all the gimp source). you can use this shell script to configure gcc 4.1.1 release (I build in a different directory than the source). I have split the long lines so they are readable in your web-browser, I have it as one huge line. You will want to make a _small_ change to suit your particular setup (directory and processor) but if you want to build it like I did, leave the rest alone! Please note that the choice of installation directories will wipe out cygwin's gcc with gcc 4.1.1 (it is simple to use cygwin setup to reinstall gcc if you feel the need to do so - your operating system won't break like with Linux / Unix). #!/bin/sh # These "set" command ought to be a single line - they are multiline for readability export set CFLAGS="-march=athlon-xp -ffast-math -mfancy-math-387 -mmmx \ -m3dnow -msse -msse2 -msse3 -mfpmath=sse,387 -O4 -pipe -mthreads \ -finline-functions -fpeel-loops -fomit-frame-pointer -funroll-all-loops \ -fprefetch-loop-arrays -fstack-check" export set BOOT_CFLAGS="-march=athlon-xp -ffast-math -mfancy-math-387 -mmmx \ -m3dnow -msse -msse2 -msse3 -mfpmath=sse,387 -O4 -pipe -mthreads \ -finline-functions -fpeel-loops -fomit-frame-pointer -funroll-all-loops \ -fprefetch-loop-arrays -fstack-check" export set CXXCPP=/bin/cpp /cygdrive/C/makecygwin/gcc-4_2-branch/configure --disable-werror \ --verbose --target=athlon_xp-pc-cygwin \ --enable=languages=c,ada,c++,fortran,java,objc,obj-c++ --prefix=/usr \ --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib \ --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info \ --enable-shared --enable-static --enable-nls --enable-multilib \ --without-included-gettext --enable-version-specific-runtime-libs \ --with-gxx-include-dir=/usr/include/c++/4.2.0 --enable-libstdcxx-debug \ --enable-libgcj --enable-libgcj-debug --enable-java-awt=gtk,xlib \ --enable-java-gc=boehm --enable-objc-gc --with-system-zlib \ --enable-threads=posix --without-tls --enable-sjlj-exceptions \ --enable-hash-synchronization --enable-libada --enable-libssp --enable-libmudflap --enable-win32-registry --with-x \ --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib \ --with-cpu=athlon-xp --with-arch=athlon-xp \ --with-tune=athlon-xp athlon_xp-pc-cygwin # End of ./run_configure script You can use that script to build 4.1.1 and 4.2.0. If you are only building 4.1.1 so you can compile 4.2.0 you will not want to enable everything as it will take a day and a half to compile. You probably want to enable the awt (for 4.1.1) since it is broken there (and in 4.2.0) and you might find it best to have two examples of the breakage to examine. You can copy the .dll-def files created in the 4.1.1 build to the 4.2.0 directory when it breaks to save some time. You can then type "make bootstrap" and "make install". Typing "make profiledbootstrap" is broken in 4.1.1 - it is rumoured to be fixed in prerelease version 4.1.2. Now you have 4.1.1 installed exit your bash shell (you might wish to re-boot and wait ten minutes as well - read up on Windows XP to find out why to wait so long). Exiting bash will ensure that there are no stray processes running in the background hogging your system. Keep your files in your 4.1.1 build and source directories - you will need to refer to them. I obtained "gcc version 4.2.0 20061225 (prerelease)" using cygwin's version of svn from svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch . There may have been some fixes in the last week but it took me a couple of days to do my own fixes and two days to compile. The testsuite ("make check") runs quicker if you create a C:\cygwin\usr\share\dejagnu\site.exp file (and run dos2unix after editing). This also prevents the warning that "make check" gives: "WARNING: Couldn't find the global config file." It contains these lines (change "target_alias" to your processor type): ## From: C:\gcc-4_2-branch-build\stage3-gcc\site.exp ## set host_triplet i686-pc-cygwin set build_triplet i686-pc-cygwin set target_triplet i686-pc-cygwin set target_alias athlon_xp-pc-cygwin set HAVE_LIBSTDCXX_V3 1 Now that you have 4.1.1 working you can download mpfr from http://www.mpfr.org/ (you could install it before compiling 4.1.1 but since your going to install 4.2.0 why bother, you only need the "c" compiler for the 4.2.0 bootstrap). I made http://www.mpfr.org/mpfr-current/mpfr-2.2.1.tar.bz2 using the CFLAGS shown above (yes, I did use -mfpmath=sse,387 and it works well). Mpfr-2.2.1 does not include "tuneup.c" so you might want to get gmp-4.2.1-1 if you want to profile mpfr. Now go to directory C:\cygwin\usr\src\guile-1.6.7-4 and type "./configure" "make" "make install". Don't forget to add "export set DEJAGNULIBS=/usr/share/dejagnu" to your .bashrc file. Now download http://www.gnu.org/software/autogen/ . Make sure it finds guile-1.6.7-4 (it won't work with cygwin's newer version 1.8.1-5) when ./configure is ran. After building you can type "make check" and you will get TWO errors. Don't worry, the autogen.exe will work using "make check" in the /cygdrive/c/gcc-4_2-branch-build/fixincludes directory and all tests will pass. Now, finally, you can start to build gcc-4_2-branch. I used "/cygdrive/c/gcc-4_2-branch-build" as my build directory and copied the ./run_configure script (show above) into it. After you change those multilines to single lines and run dos2unix on the file your almost ready. Go into the gcc 4.2.0 source (not build) directory and open configure in wordpad. Look for this: # Disable libmudflap on some systems. if test x$enable_libmudflap = x ; then case "${target}" in *-*-linux* | *-*-gnu* | *-*-k*bsd*-gnu) # Enable libmudflap by default in GNU and friends. ;; *-*-freebsd*) # Enable libmudflap by default in FreeBSD. ;; and add this right after the above: *-*-cygwin*) # Enable libmudflap by default in cygwin. - Added Let's try libmudflap # on Windows XP ;; Do the same sort of thing to enable OpenMP. Look for this: # Disable libgomp on non POSIX hosted systems. if test x$enable_libgomp = x ; then # Enable libgomp by default on hosted POSIX systems. case "${target}" in *-*-linux* | *-*-gnu* | *-*-k*bsd*-gnu) ;; *-*-netbsd* | *-*-freebsd* | *-*-openbsd*) ;; and add this right after the above: *-*-cygwin*) # Enable libgomp by default in cygwin. - Added Let's try libgomp on # Windows XP ;; Those are the only two changes I made to C:\makecygwin\gcc-4_2-branch\configure . After you run the ./run_configure script there will be a makefile in your directory. Open it in wordpad and also open the makefile from your 4.1.1 build in wordpad. Now you need to do a lot of fixing to get things to work ... This is the way that _I_ fixed things (for me) so that I could get make to run. I'll leave it to the maintainers to decide the best way, when they are ready to so. Goto the wordpad with the 4.1.1 Makefile and search for the text "stage1-start::" . Do the same with the 4.2.0 Makefile. Rename the 4.2.0 "stage?-start::" sections to "Origonal-stage?-start::" and the 4.2.0 "stage?-end::" sections to "Origonal-stage?-end::". Now copy the 4.1.1 "stage?-start::" and 0 "stage?-end::" sections into the 4.2.0 Makefile at each appropriate place. Hope that is clear. You _could_ also fixup "stageprofile-start::" while you are there, I did in my Makefile but have not yet typed "make stageprofile" to test if profiled building is working in 4.2.0. Don't forget that 4.2.0 has an extra directory that is not in 4.1.1 (libdecnumber) so in each of the "stage?-start/end" sections you will need to add a couple of lines for the libdecnumber directory. I found that the 4.1.1 Makefile worked perfectly (for 4.1.1) and adding those sections into the 4.2.0 Makefile caused it to work correctly. Prior to making this fix I was unable to get make to build properly. It kept trying to coping the directories into each other instead of renaming them and shuffling them (if that is how it could best be described). The 4.2.0 Makefile says "We use mv on platforms where symlinks to directories do not work or are not reliable." I've not got to running down why the configure script chose the "mv method" but it breaks on Windows XP (for me). Other people claim to have done a cygwin build (with far fewer things enabled) but they might not have built it on Windows XP (where "ln" works fine and "mv" copies into the directory instead of overwriting the directory - it is not "dos" "copy"). Next fix. Goto source directory C:\gcc-4_2-branch\boehm-gc\include\private\ and add the following to both gc_priv.h and gcconfig.h somewhere near the top (after all "#include" lines). /* Added - Don't use mmap with Cygwin since it is not completely working correctly */ #ifdef __CYGWIN32__ #undef HAVE_MMAP #endif /* __CYGWIN32__ */ Mmap doesn't seem to be working well enough for Java's liking. If you do not do the above you get "error: could not create classmap.db: java.io.IOException: mmap not implemented" even though it would be enabled (but apparently broken). By disabling it as shown the problem seems to go away. Obviously this is a quick-fix. The mmap needs to be fixed, not disabled. Do the same thing to C:\gcc-4_2-branch\gcc\config\i386\host-cygwin.c and these two as well: C:\gcc-4_2-branch\libjava\classpath\native\jni\java-nio\java_nio_MappedByteBufferImpl.c C:\gcc-4_2-branch\libjava\classpath\native\jni\java-nio\gnu_java_nio_channels_FileChannelImpl.c In file C:\gcc-4_2-branch\gcc\configure look for this section. Search for "mmap(0" to find it. Add the word cygwin to the "vms* | ultrix*" line. else # Add a system to this blacklist if # mmap(0, stat_size, PROT_READ, MAP_PRIVATE, fd, 0) doesn't return a # memory area containing the same data that you'd get if you applied # read() to the same fd. The only system known to have a problem here # is VMS, where text files have record structure. case "$host_os" in # vms* | ultrix*) # Added - don't use mmap with cygwin (due to # libjava exceptions) vms* | cygwin* | ultrix*) gcc_cv_func_mmap_file=no ;; *) gcc_cv_func_mmap_file=yes;; esac fi Next fix. Goto file C:\gcc-4_2-branch\boehm-gc\win32_threads.c and add this function: GC_PTR GC_get_thread_stack_base() { return 0; } Otherwise you'll get this error: ./.libs/libgcjgc.a(misc.o): In function `GC_init_inner': /cygdrive/C/makecygwin/gcc-4_2-branch/boehm-gc/misc.c:680: undefined reference to `_GC_get_thread_stack_base' Next fix. Open C:\gcc-4_2-branch\libstdc++-v3\configure and change this: # Double quotes because CXXCPP needs to be expanded for CXXCPP in "$CXX -E" "/lib/cpp" # not for cygwin to this # Double quotes because CXXCPP needs to be expanded # for CXXCPP in "$CXX -E" "/lib/cpp" # not for cygwin for CXXCPP in "$CXX -E" "/lib/cpp" "/bin/cpp -E" Next fix. Open C:\gcc-4_2-branch\libgomp\configure . Search for this section and add the hack: # We may get other options which we leave undocumented: # --with-target-subdir, --with-multisrctop, --with-multisubdir # See config-ml.in if you want the gory details. if test "$srcdir" = "."; then if test "$with_target_subdir" != "."; then multi_basedir="$srcdir/$with_multisrctop../.." else multi_basedir="$srcdir/$with_multisrctop.." fi else multi_basedir="$srcdir/.." fi # Added - fix: ./config.status: line 1185: ./../../config-ml.in: No such file # or directory multi_basedir="$srcdir/.." Next fix. Open C:\gcc-4_2-branch\libjava\classpath\java\awt\peer\ComponentPeer.java and comment out the SECOND definition of setBounds. Changing it to this does the least mess: /* void setBounds (int x, int y, int width, int height, int z); */ It makes sense to leave the second comments in until it is decided whether to keep the first comments or the second comments (or even merge them). I didn't write this file and don't know java well so I kept the tampering to a minimum. Last problem, on to directory C:\gcc-4_2-branch\libmudflap . A few things to do here. Open the configure file and find this line: for name in _start __start unknown; do Change it to this: for name in _start __start __main _main unknown; do I figure this will make mudflaps work for all platforms (__main is almost the first routine in cygwin, there is no _start and I had no luck trying _GLOBAL__I_0_main ). Remember each time you edit a file (with notepad / wordpad) that will be read by bash you need to run dos2unix on that file or bash will barf and Linux / Unix users will not appreciate the file either if it ends up getting passed around. Next fix mf-runtime.c by changing the definintion of __mf_lc_mask from uintptr_t __mf_lc_mask = LOOKUP_CACHE_MASK_DFL; to __mf_uintptr_t __mf_lc_mask = LOOKUP_CACHE_MASK_DFL; It was causing "error: conflicting types for '__mf_lc_mask'" messages when I (but I guess, no one else?) compiled the file. Next fix mf-runtime.h Find these lines #pragma redefine_extname memcpy __mfwrap_memcpy #pragma redefine_extname memmove __mfwrap_memmove #pragma redefine_extname memset __mfwrap_memset .... Make a copy of the whole section (not just those three lines all 132 lines). Change it so it is like this: #ifdef __CYGWIN__ /* Cygwin needs __mfwrap, not ___mfwrap - so use _mfwrap, not __mfwrap */ #pragma redefine_extname memcpy ___mfwrap_memcpy #pragma redefine_extname memmove ___mfwrap_memmove #pragma redefine_extname memset ___mfwrap_memset ... (the rest) #else /* __CYGWIN__ */ #pragma redefine_extname memcpy __mfwrap_memcpy #pragma redefine_extname memmove __mfwrap_memmove #pragma redefine_extname memset __mfwrap_memset ... (the rest) #endif /* __CYGWIN__ */ What you are doing is adding an extra "_" for cygwin. Yes, there may be a different (better) way but this is how I _hacked_ it (and I have _most_ libmudflap tests passing on WinXP :) ). Now change the Makefile (or Makefile.in if you prefer) to add a NEW file that I am naming mf-cygwin.c to the lists of built files. IE: If you are fixing Makefile.in then change: am_libmudflap_la_OBJECTS = mf-runtime.lo mf-heuristics.lo mf-hooks1.lo \ mf-hooks2.lo to am_libmudflap_la_OBJECTS = mf-runtime.lo mf-heuristics.lo mf-hooks1.lo \ mf-hooks2.lo mf-cygwin.lo libmudflap_la_SOURCES = \ mf-runtime.c \ mf-heuristics.c \ mf-hooks1.c \ mf-hooks2.c to libmudflap_la_SOURCES = \ mf-runtime.c \ mf-heuristics.c \ mf-hooks1.c \ mf-hooks2.c \ mf-cygwin.c libmudflapth_la_LIBADD = \ pth/mf-runtime.lo \ pth/mf-heuristics.lo \ pth/mf-hooks1.lo \ pth/mf-hooks2.lo \ pth/mf-hooks3.lo to libmudflapth_la_LIBADD = \ pth/mf-runtime.lo \ pth/mf-heuristics.lo \ pth/mf-hooks1.lo \ pth/mf-hooks2.lo \ pth/mf-hooks3.lo \ pth/mf-cygwin.lo and add this line: @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/mf-cygwin.Plo@am__quote@ directly after this line: @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/mf-runtime.Plo@am__quote@ and add these 2 lines: pth/mf-cygwin.lo: mf-cygwin.c $(LTCOMPILE) -DLIBMUDFLAPTH -c $(srcdir)/mf-cygwin.c -o $@ directly after these 2 lines: pth/mf-hooks3.lo: mf-hooks3.c mf-runtime.h mf-impl.h $(LTCOMPILE) -DLIBMUDFLAPTH -c $(srcdir)/mf-hooks3.c -o $@ This is the contents of mf-cygwin.c (formatted "as-is" - cut and pasted) /* Mudflap support file for Cygwin Windows XP (12-18-2006) v0.01 Copyright info: If the Free Software Foundation wants to use this code with GCC (or other GNU software) thats OK with me. I retain the right to use this code in my own programs without any restrictions. Someone with expertise in Windows XP, GCC, and Cygwin is welcome to make this hack better. */ /* Documentation: This code defines working stubs for some of the function calls listed below. If you have something that won't compile with this limited set simply add a new wrapper using the principles demonstrated below. It's placement of _start and _end may not be 'far enough out' to catch everything it could. Hopefully this attempt will encourage others to make this better. */ /* #define __real_malloc malloc #define __real_free free #define __real_calloc calloc #define __real_realloc realloc #define __real_mmap mmap #define __real_munmap munmap #define __real_alloca alloca #define __real_pthread_create pthread_create #define __real_pthread_join pthread_join #define __real_pthread_exit pthread_exit #define __real_main main */ /* The file file gcc-4_2-branch/gcc/config/rs6000/aix.h has the following definition in it but there is no where else in gcc that "brename" is defined so I couldn't simply change the spec file and needed to write these wrappers for Cygwin instead. If gcc accepted -brename the following would be useful. It does not appear to be a command for GNU ld either. #define MFWRAP_SPEC " %{static: %{fmudflap|fmudflapth: \ -brename:malloc,__wrap_malloc -brename:__real_malloc,malloc \ -brename:free,__wrap_free -brename:__real_free,free \ -brename:calloc,__wrap_calloc -brename:__real_calloc,calloc \ -brename:realloc,__wrap_realloc -brename:__real_realloc,realloc \ -brename:mmap,__wrap_mmap -brename:__real_mmap,mmap \ -brename:munmap,__wrap_munmap -brename:__real_munmap,munmap \ -brename:alloca,__wrap_alloca -brename:__real_alloca,alloca \ } %{fmudflapth: \ -brename:pthread_create,__wrap_pthread_create \ -brename:__real_pthread_create,pthread_create \ -brename:pthread_join,__wrap_pthread_join \ -brename:__real_pthread_join,pthread_join \ -brename:pthread_exit,__wrap_pthread_exit \ -brename:__real_pthread_exit,pthread_exit \ }} %{fmudflap|fmudflapth: \ -brename:main,__wrap_main -brename:__real_main,main \ }" */ void end_it(){} #include #include /* for off_t */ #include /* for mmap munmap */ static int ran_something = 0; /* not the most efficient but it works */ /* fail31-frag.c:14: undefined reference to `_alloca' */ /* The includes in fail31-frag.c don't include alloca.h and thus can't be compiled */ /* Since the test is not intended to test for THAT error the following should fix the test */ # ifdef __STDC__ void * alloca(size_t size) # else void * alloca() int size; # endif { if (ran_something == 0) { atexit(end_it); ran_something = 1; } #ifdef __GNUC__ return((void *)_alloca(size)); /* usually uses __builtin_alloca(size); */ #else return((char *)_alloca(size)); #endif } # ifdef __STDC__ char * __real_malloc(size_t size) # else char * __real_malloc() int size; # endif { if (ran_something == 0) { atexit(end_it); ran_something = 1; } return((char *)malloc(size)); } # ifdef __STDC__ _VOID __real_free(_PTR mem) # else void __real_free() char* mem; # endif { if (ran_something == 0) { atexit(end_it); ran_something = 1; } #if (defined(__STDC__) && __STDC__ == 1) || defined(__cplusplus) || defined(STDC_HEADERS) free(mem); #else return((void)free(mem)); #endif } # ifdef __STDC__ _PTR __real_calloc(size_t __nmemb, size_t __size) # else char * __real_calloc() int __nmemb; int __size; # endif { if (ran_something == 0) { atexit(end_it); ran_something = 1; } return((char *)calloc(__nmemb, __size)); } # ifdef __STDC__ _PTR __real_realloc(_PTR __r, size_t __size) # else char * __real_realloc() char * __r; int __size; # endif { if (ran_something == 0) { atexit(end_it); ran_something = 1; } return((char *)realloc(__r, __size)); } void *__real_mmap (void *__addr, size_t __len, int __prot, int __flags, int __fd, off_t __off){ mmap (__addr, __len, __prot, __flags, __fd, __off); } int __real_munmap (void *__addr, size_t __len){ if (ran_something == 0) { atexit(end_it); ran_something = 1; } return munmap (__addr, __len); } /* __main is '_start', the is '__end' */ /* Without this function we get this error: mf-heuristics.c:(.text$__mf_heuristic_check+0x206): undefined reference to `__end' This function starts at an address AFTER '_end' (when tested with gdb on my WinXP). */ void _end() { end_it(); } /* mf-hooks2.c notes that these are not yet supported (but could / should be) */ /* XXX: stpcpy, memccpy */ /* XXX: *printf,*scanf */ /* XXX: setjmp, longjmp */ /* Here are some notes from using gdb on a Cygwin .exe . Perhaps someone expert on Windows XP would kindly find suitable replacements for _start and _end that would be useful for Cygwin. The ./configure script works 'OK' by using "_start __start __main _main unknown" for the "Check for the name of the symbol used for the entry point" function instead of the origonal "_start __start unknown" check that was used prior to my modifications. This _should_ choose "__main" which is very near (0x01A0 bytes) the start (but would fallback on 'regular' "_main"). Since I don't have the source for Windows XP and since this file works correctly (libmudflap passes many, but not all, tests) I did not further explore this avenue. */ --- END OF FIXES --- Now you can type "make bootstrap" (and wait two days). The first time I tried to compile 4.2.0 (after a couple of fixes) it took six hours before the make broke. Then I ended up changing enough things that I had to "make clean" and run my ./run_configure script again. I've re-compiled 4.2.0 a few times this last month and waited till I had things working better before posting the "make check" results. They are long because I enabled everything I could. Thus far I have not been able to get "ada" to compile. The "c" compiler and "fortran" (with gomp!) are working very well. Even though I did NOT choose "treelang" the Makefile makes it anyways, it didn't take long and it did OK on it's tests ;) ... I did find a number of other minor things to pick about: Error in Makefile typing "make check-treelang" puts files: site.exp treelang.log treelang.sum in directory C:\gcc-4_2-branch-build\stage3-gcc\testsuite\ instead of putting them in directory C:\gcc-4_2-branch-build\stage3-gcc\testsuite\treelang like in other similar tests. The boehm-gc does not make .log or .sum files but produces this output: Completed 3 tests Allocated 5683641 collectable objects Allocated 306 uncollectable objects Allocated 3698982 atomic objects Allocated 34440 stubborn objects Finalized 6613/6613 objects - finalization is probably ok Total number of bytes allocated is 188641060 Final heap size is 12431360 bytes Collector appears to work Completed 131 collections PASS: gctest ================== All 1 tests passed ================== I guess it was not worthy of making itself a testsuite directory and .log or .sum files but there is the output that would otherwise not be included had I not cut and pasted it. The libiberty Makefile does not make .log or .sum but creates a testsuite directory and this output: cd /cygdrive/c/gcc-4_2-branch-build/athlon_xp-pc-cygwin/libiberty $ make check make[1]: Entering directory `/cygdrive/c/gcc-4_2-branch-build/athlon_xp-pc-cygwin/libiberty/testsuite' make[1]: Nothing to be done for `check'. make[1]: Leaving directory `/cygdrive/c/gcc-4_2-branch-build/athlon_xp-pc-cygwin/libiberty/testsuite' What you actually need to type (according to the Makefile) is this: $ make really-check ./test-demangle < /cygdrive/C/makecygwin/gcc-4_2-branch/libiberty/testsuite/demangle-expected ./test-demangle: 755 tests, 0 failures ./test-pexecute ./test-expandargv PASS: test-expandargv-0. PASS: test-expandargv-1. PASS: test-expandargv-2. PASS: test-expandargv-3. File C:\gcc-4_2-branch-build\athlon_xp-pc-cygwin\libobjc\Makefile has no 'proper' "check" in it. Typing "make check" does not create testsuite directory or do any checks. To run checks on "objc" you can type "cd cd /cygdrive/c/gcc-4_2-branch-build/" and make "check-target-libobjc". File C:\gcc-4_2-branch-build\athlon_xp-pc-cygwin\libgfortran\Makefile has a "check" that tests if "all-am" was made but does not do any testsuite tests. To run checks on fortran you need to type: "cd /cygdrive/c/gcc-4_2-branch-build/stage3-gcc" and "make check-fortran". But to test libmudflap libgomp libffi etc. you do need to change to target directory. Typing "cd /cygdrive/c/gcc-4_2-branch-build/athlon_xp-pc-cygwin/libmudflap" and "make check" works. This seems inconsistant with the above two examples. Why not be able to type "make check" in the root of the build and be able to check everything, everywhere, completely. The test summary for libmudflap could be better (expand the summary categories). For example the libjava summary looks like this: # of expected passes 5295 # of unexpected failures 859 # of expected failures 12 # of untested testcases 836 But the libmudflap summary looks like this: (1st compile:) # of expected passes 783 # of unexpected failures 739 (2nd compile:) # of expected passes 834 # of unexpected failures 208 (3rd compile:) # of expected passes 214 # of unexpected failures 70 (4th compile:) # of expected passes 1194 # of unexpected failures 588 The summaries should list the _total_ number of tests and also show: PASS, XPASS, FAIL, XFAIL, UNSUPPORTED, ERROR, WARNING. How else are we to know how close we are to success? ------------------------------------------------------------------------------ The reason that my "make check" of my java programs did not do so well is as follows: In directory C:\gcc-4_2-branch-build\athlon_xp-pc-cygwin\libjava\testsuite\ the test scripts run commands like this ("as-is" not reformatted, just cut-and-pasted here - didn't want to chop any info out or add many "\" everywhere): /cygdrive/c/gcc-4_2-branch-build/gcc/gcj -v -B/cygdrive/c/gcc-4_2-branch-build/athlon_xp-pc-cygwin/libjava/ -B/cygdrive/c/gcc-4_2-branch-build/gcc/ --encoding=UTF-8 -B/cygdrive/c/gcc-4_2-branch-build/athlon_xp-pc-cygwin/libjava/testsuite/../ /cygdrive/C/makecygwin/gcc-4_2-branch/libjava/testsuite/libjava.jni/PR18116.java -fjni --main=PR18116 -g -o PR18116 -L/cygdrive/c/gcc-4_2-branch-build/athlon_xp-pc-cygwin/./libjava/.libs /cygdrive/c/gcc-4_2-branch-build/gcc/jc1.exe /cygdrive/C/makecygwin/gcc-4_2-branch/libjava/testsuite/libjava.jni/PR18116.java -fhash-synchronization -fno-use-divide-subroutine -fuse-boehm-gc -fnon-call-exceptions -fkeep-inline-functions -quiet -dumpbase PR18116.java -mtune=athlon-xp -march=athlon-xp -auxbase PR18116 -g -version -fencoding=UTF-8 -fjni -o /cygdrive/c/DOCUME~1/HP_ADM~1/LOCALS~1/Temp/ccH6vvRz.s /cygdrive/c/gcc-4_2-branch-build/gcc/as -o /cygdrive/c/DOCUME~1/HP_ADM~1/LOCALS~1/Temp/ccrfHZIC.o /cygdrive/c/DOCUME~1/HP_ADM~1/LOCALS~1/Temp/ccH6vvRz.s /cygdrive/c/gcc-4_2-branch-build/gcc/jvgenmain.exe PR18116main /cygdrive/c/DOCUME~1/HP_ADM~1/LOCALS~1/Temp/ccDK0dpQ.i /cygdrive/c/gcc-4_2-branch-build/gcc/cc1.exe /cygdrive/c/DOCUME~1/HP_ADM~1/LOCALS~1/Temp/ccDK0dpQ.i -quiet -dumpbase PR18116main.c -mtune=athlon-xp -march=athlon-xp -g -version -fdollars-in-identifiers -o /cygdrive/c/DOCUME~1/HP_ADM~1/LOCALS~1/Temp/ccH6vvRz.s /cygdrive/c/gcc-4_2-branch-build/gcc/as -o /cygdrive/c/DOCUME~1/HP_ADM~1/LOCALS~1/Temp/ccTv9s0K.o /cygdrive/c/DOCUME~1/HP_ADM~1/LOCALS~1/Temp/ccH6vvRz.s /cygdrive/c/gcc-4_2-branch-build/gcc/collect2.exe -Bdynamic --dll-search-prefix=cyg -o PR18116.exe /usr/lib/gcc/athlon_xp-pc-cygwin/4.2.0/../../../crt0.o -L/cygdrive/c/gcc-4_2-branch-build/athlon_xp-pc-cygwin/./libjava/.libs -L/cygdrive/c/gcc-4_2-branch-build/athlon_xp-pc-cygwin/libjava -L/cygdrive/c/gcc-4_2-branch-build/gcc -L/cygdrive/c/gcc-4_2-branch-build/athlon_xp-pc-cygwin/libjava/testsuite/.. -L/usr/lib/gcc/athlon_xp-pc-cygwin/4.2.0 -L/usr/lib/gcc/athlon_xp-pc-cygwin/4.2.0 -L/usr/lib/gcc/athlon_xp-pc-cygwin/4.2.0/../../.. /cygdrive/c/DOCUME~1/HP_ADM~1/LOCALS~1/Temp/ccTv9s0K.o /cygdrive/c/DOCUME~1/HP_ADM~1/LOCALS~1/Temp/ccrfHZIC.o -lgcc -lgcj -lm /usr/lib/libiconv.a -lz -ldl -lgcc -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc Running the executable program from bash using "gdb ./PR18116.exe": GNU gdb 6.5.50.20060706-cvs (cygwin-special) (gdb) start Breakpoint 1 at 0x401050: file /cygdrive/c/DOCUME~1/HP_ADM~1/LOCALS~1/Temp/ccDK0dpQ.i, line 8. Starting program: /cygdrive/c/gcc-4_2-branch-build/athlon_xp-pc-cygwin/libjava/testsuite/PR18116.exe Loaded symbols for /cygdrive/c/WINDOWS/system32/ntdll.dll Loaded symbols for /cygdrive/c/WINDOWS/system32/kernel32.dll Loaded symbols for /usr/bin/cygwin1.dll Loaded symbols for /cygdrive/c/WINDOWS/system32/advapi32.dll Loaded symbols for /cygdrive/c/WINDOWS/system32/rpcrt4.dll Loaded symbols for /usr/bin/cygz.dll main (argc=2280856, argv=0x61006148) at /cygdrive/c/DOCUME~1/HP_ADM~1/LOCALS~1/Temp/ccDK0dpQ.i:8 8 /cygdrive/c/DOCUME~1/HP_ADM~1/LOCALS~1/Temp/ccDK0dpQ.i: No such file or directory. in /cygdrive/c/DOCUME~1/HP_ADM~1/LOCALS~1/Temp/ccDK0dpQ.i (gdb) Notice that gdb thinks it is running "/cygdrive/c/DOCUME~1/HP_ADM~1/LOCALS~1/Temp/ccDK0dpQ.i". That is the output from jvgenmain, not collect2 (which is last in the chain). I don't know a lot about java but it looks as though it is confused about it's name and trying to dynamically load the wrong name. The compile and linking seem OK (often) when I run "make check" but the execution tests often (but not always) fail. This gives a lot of fails for java and the summary does not distinguish between fail modes. ------------------------------------------------------------------------------ After all that everything works fairly well. There are very few errors in "c" even less with "fortran", not tooo many elsewhere and "ada" won't compile (yet!). I hope I have encouraged some WinXP cygwin users to try a compile and submit a report of your results so gcc will be better for this platform. YT, Rob -- Summary: Tough time building 4.2.0 (CVS) on WinXP with Cygwin Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30342