Bug 30342 - Tough time building 4.2.0 (CVS) on WinXP with Cygwin
Summary: Tough time building 4.2.0 (CVS) on WinXP with Cygwin
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: bootstrap (show other bugs)
Version: 4.2.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-01-01 15:08 UTC by Rob
Modified: 2010-03-23 03:37 UTC (History)
2 users (show)

See Also:
Host: i686-pc-cygwin
Target: i686-pc-cygwin
Build: i686-pc-cygwin
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rob 2007-01-01 15:08:25 UTC
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 <stdlib.h>
#include <sys/types.h>	/* for off_t */
#include <sys/mman.h>		/* 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
Comment 1 Andrew Pinski 2007-01-05 05:12:55 UTC
First libmudflap really cannot be supported on cygwin.
Second your patch for libgomp should be sent to the gcc-patches@ list.
Third you are incorrect in saying mmap does not work because it does for so many other people, it might mean you have an older version of cygwin.dll installed.

Fourth to check the compiler/libraries,
just do "make -k check". in the build directory.
Note the -k.
This is documented in http://gcc.gnu.org/install/test.html already.

Also building in the source directory is not supported that much.
Comment 2 Rob 2007-01-12 05:12:27 UTC
Thank you kindly for your comments and e-mails everyone.

Firstly, I am NOT building in the source directory.

My result (as of a while ago) for libmudflap are:
  === libmudflap Summary ===
# of expected passes  1194
# of unexpected  failures 588

Complete result (for an OLD build) are here:
http://gcc.gnu.org/ml/gcc-testresults/2007-01/msg00052.html

I since have it working so well I can type "make check" (without the -k)
and I am able to type "make install" with only a single warning. 

I removed some of the fancy optimization parameters from the CFLAGS I was
building with and built a less optimized but more stable bootstrap. The
extra optimizations worked well for the most part but Ada did not enjoy them.


My "patch" for gomp (as you refer to it) is simply to enable it in the
./configure script - I did NOT change one line of the source for gomp.

Mmap does NOT work when compiling java with the flags _I_ was using.
The error I was getting was "java.io.IOException: mmap not implemented"
and that was with the CVS "AS-IS", with no changes. Much of mmap DOES
work but __some__ portion of it does not work with a small portion of java
(on the particular day I obtained the CVS and then built it - it _might_ be
OK now - I'll try re-enabling it).

I have a newer build that I will post the results of shortly. Nearly everything
is nearly OK - except the pch (which _I_ don't use) doesn't pass many tests.

I do have the newest cygwin and do check their site for updates.

Thanks again to everyone who read my post. I hope more people are
encouraged to try a WinXP cygwin build of 4.2.0 and post the (FULL)
test results.

Please note (with the CVS from a few days ago) that "make check" misses
some things. To get all the logs you need to type:

make check
make check-target-boehm-gc
make check-target-libffi
make check-target-libgomp
make check-target-libmudflap
make check-target-zlib
Comment 3 Andrew Pinski 2007-01-12 05:31:06 UTC
> Please note (with the CVS from a few days ago) that "make check" misses
> some things. To get all the logs you need to type:

No you just do "make -k check".  I mentioned this before.
Comment 4 Rob 2007-01-24 04:26:38 UTC
The newest test results for building according to these instructions are here:
http://gcc.gnu.org/ml/gcc-testresults/2007-01/msg00811.html

Most tests are completed with a dozen (or less) errors - that is not too bad with _every_ possible option enabled. 

Libmudflap is usable (for debugging, then recompile with the feature off) and
most of the errors are "output pattern test" errors (which, to ME, means that the expect script is not catching the output correctly) discounting those errors
there are very few errors remaining.

I'm looking into the Java test to see why there are so many errors. I did make a couple of bug reports but Java is not my strongest language - I can only
hope that someone else will fix it for the cygwin platform :) .

Overall 4.2.0 is testing very well (on _my_ platform), there are fewer errors
reported than "make -k check" on 4.1.1 (release) - this does not mean it actually "works" better, only that the error checking does not find errors ;) .


Comment 5 Rob 2007-05-10 06:51:49 UTC
Having great success compiling GCC (with nearly every option enabled) using the above instructions. More recent compile test results are here:

Results for 4.2.0 20070501 (prerelease) testsuite on i686-pc-cygwin
http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00258.html

Comment 6 Dave Korn 2010-03-23 03:37:31 UTC
This is mostly a HOWTO rather than a bug report.  And 4.2 branch is retired now, and cygwin has released 1.7, and pretty much everything's changed, so closing it to tidy up BZ a bit.