This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug bootstrap/30342] New: Tough time building 4.2.0 (CVS) on WinXP with Cygwin
- From: "rob1weld at aol dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 1 Jan 2007 15:08:25 -0000
- Subject: [Bug bootstrap/30342] New: Tough time building 4.2.0 (CVS) on WinXP with Cygwin
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
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
--
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