* mingw32 target broken
@ 2001-12-07 21:06 Adam Megacz
2001-12-07 22:01 ` Adam Megacz
0 siblings, 1 reply; 20+ messages in thread
From: Adam Megacz @ 2001-12-07 21:06 UTC (permalink / raw)
To: gcc
Hrm, I checked this out a few mintues ago... does anybody know what
the problem might be? I'm building on an i686-gnu-linux host...
/home/megacz/gcc-3.1/bin/gcc/xgcc -B/home/megacz/gcc-3.1/bin/gcc/ -B/usr/mingw32/bin/ -B/usr/mingw32/lib/ -isystem /usr/mingw32/include -O2 -I../../src/gcc/../winsup/include -I../../src/gcc/../winsup/cygwin/include -I../../src/gcc/../winsup/w32api/include -DCROSS_COMPILE -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -g1 -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/config -I../../src/gcc/../include -DL_chkstk -xassembler-with-cpp -c ../../src/gcc/config/i386/cygwin.asm -o libgcc/./_chkstk.o
/home/megacz/gcc-3.1/bin/gcc/xgcc -B/home/megacz/gcc-3.1/bin/gcc/ -B/usr/mingw32/bin/ -B/usr/mingw32/lib/ -isystem /usr/mingw32/include -O2 -I../../src/gcc/../winsup/include -I../../src/gcc/../winsup/cygwin/include -I../../src/gcc/../winsup/w32api/include -DCROSS_COMPILE -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -g1 -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/config -I../../src/gcc/../include -DL_muldi3 -c ../../src/gcc/libgcc2.c -o libgcc/./_muldi3.o
In file included from ../../src/gcc/config/i386/mingw32.h:25,
from tconfig.h:4,
from ../../src/gcc/libgcc2.c:36:
../../src/gcc/config/i386/cygwin.h:31:19: stdio.h: No such file or directory
In file included from ../../src/gcc/config/i386/mingw32.h:25,
from tconfig.h:4,
from ../../src/gcc/libgcc2.c:36:
../../src/gcc/config/i386/cygwin.h:435: parse error before '*' token
../../src/gcc/config/i386/cygwin.h:435: warning: function declaration isn't a prototype
../../src/gcc/config/i386/cygwin.h:437: parse error before '*' token
../../src/gcc/config/i386/cygwin.h:437: warning: function declaration isn't a prototype
make[2]: *** [libgcc/./_muldi3.o] Error 1
make[2]: Leaving directory `/home/megacz/gcc-3.1/bin/gcc'
make[1]: *** [libgcc.a] Error 2
make[1]: Leaving directory `/home/megacz/gcc-3.1/bin/gcc'
make: *** [all-gcc] Error 2
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: mingw32 target broken 2001-12-07 21:06 mingw32 target broken Adam Megacz @ 2001-12-07 22:01 ` Adam Megacz [not found] ` <20011208003722.A14955@mediaone.net> 0 siblings, 1 reply; 20+ messages in thread From: Adam Megacz @ 2001-12-07 22:01 UTC (permalink / raw) To: gcc Adam Megacz <gcc@lists.megacz.com> writes: > Hrm, I checked this out a few mintues ago... does anybody know what > the problem might be? I'm building on an i686-gnu-linux host... My configure line was ../src/configure --enable-threads=posix --prefix=/usr --enable-shared --enable-languages=c++,java,c --disable-nls --target=mingw if that helps... - a ^ permalink raw reply [flat|nested] 20+ messages in thread
[parent not found: <20011208003722.A14955@mediaone.net>]
* Re: mingw32 target broken [cygwin as well] [not found] ` <20011208003722.A14955@mediaone.net> @ 2001-12-07 23:12 ` Adam Megacz 2001-12-07 23:40 ` Craig Rodrigues 2001-12-08 14:42 ` mingw32 target broken [cygwin as well] Jeff Sturm 0 siblings, 2 replies; 20+ messages in thread From: Adam Megacz @ 2001-12-07 23:12 UTC (permalink / raw) To: gcc Craig Rodrigues <rodrigc@mediaone.net> writes: > Post the output of the configure, and the config.log that was created as well. No config.log was created. I have included config.status below... Side note: this seems to happen with target=i386-pc-mingw and target=i386-pc-cygwin as well. For those just joining the thread, I'm using a fresh cvs checkout from a few hours ago. == configure command =========================================================== ../src/configure --enable-threads=posix --prefix=/usr --enable-shared \ --enable-languages=c++,java,c --disable-nls --target=mingw == configure output ============================================================ Configuring for a i686-pc-linux-gnu host. *** This configuration is not supported in the following subdirectories: target-libffi target-boehm-gc target-zlib target-libjava target-libchill target-libstdc++-v3 target-libf2c zlib fastjar target-libobjc (Any other directories should still work fine.) Created "Makefile" in /home/megacz/gcc-3.1/bin using "mh-frag" and "mt-frag" Configuring libiberty... creating cache ../config.cache checking host system type... i686-pc-linux-gnu checking build system type... i686-pc-linux-gnu checking for ar... ar checking for ranlib... ranlib checking for gcc... gcc checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking for POSIXized ISC... no checking for working const... yes checking for inline... inline checking for a BSD compatible install... /usr/bin/install -c Appending ../../src/libiberty/config/../../config/mh-x86pic to xhost-mkfrag checking how to run the C preprocessor... gcc -E checking for sys/file.h... yes checking for sys/param.h... yes checking for limits.h... yes checking for stdlib.h... yes checking for string.h... yes checking for unistd.h... yes checking for strings.h... yes checking for sys/time.h... yes checking for time.h... yes checking for sys/resource.h... yes checking for sys/stat.h... yes checking for sys/mman.h... yes checking for fcntl.h... yes checking for sys/wait.h that is POSIX.1 compatible... yes checking whether time.h and sys/time.h may both be included... yes checking whether errno must be declared... no checking whether the C compiler (gcc -g -O2 ) works... yes checking whether the C compiler (gcc -g -O2 ) is a cross-compiler... no checking for asprintf... yes checking for atexit... yes checking for basename... yes checking for bcmp... yes checking for bcopy... yes checking for bsearch... yes checking for bzero... yes checking for calloc... yes checking for clock... yes checking for ffs... yes checking for getcwd... yes checking for getpagesize... yes checking for index... yes checking for insque... yes checking for memchr... yes checking for memcmp... yes checking for memcpy... yes checking for memmove... yes checking for memset... yes checking for mkstemps... no checking for putenv... yes checking for random... yes checking for rename... yes checking for rindex... yes checking for setenv... yes checking for sigsetmask... yes checking for strcasecmp... yes checking for strchr... yes checking for strdup... yes checking for strncasecmp... yes checking for strrchr... yes checking for strstr... yes checking for strtod... yes checking for strtol... yes checking for strtoul... yes checking for tmpnam... yes checking for vasprintf... yes checking for vfprintf... yes checking for vprintf... yes checking for vsprintf... yes checking for waitpid... yes checking whether alloca needs Cray hooks... no checking stack direction for C alloca... -1 checking for ANSI C header files... yes checking for pid_t... yes checking for vfork.h... no checking for working vfork... yes checking for sys_errlist... yes checking for sys_nerr... yes checking for sys_siglist... yes checking for getrusage... yes checking for on_exit... yes checking for psignal... yes checking for strerror... yes checking for strsignal... yes checking for sysconf... yes checking for times... yes checking for sbrk... yes checking for gettimeofday... yes checking for unistd.h... (cached) yes checking for getpagesize... (cached) yes checking for working mmap... yes checking for working strncmp... yes updating cache ../config.cache creating ./config.status creating Makefile creating testsuite/Makefile creating config.h Configuring gcc... loading cache ../config.cache checking LIBRARY_PATH variable... ok checking GCC_EXEC_PREFIX variable... ok checking host system type... i686-pc-linux-gnu checking target system type... i386-pc-mingw32 checking build system type... i686-pc-linux-gnu checking for gcc... (cached) gcc checking whether the C compiler (gcc -g -O2 ) works... yes checking whether the C compiler (gcc -g -O2 ) is a cross-compiler... no checking whether we are using GNU C... (cached) yes checking whether gcc accepts -g... (cached) yes checking whether gcc and cc understand -c and -o together... yes checking whether gcc accepts -Wno-long-long... yes checking how to run the C preprocessor... (cached) gcc -E checking for inline... (cached) inline checking for volatile... yes checking for long double... yes checking for long long int... yes checking for __int64... no checking for built-in _Bool... yes checking size of short... 2 checking size of int... 4 checking size of long... 4 checking size of long long... 8 checking execution character set... ASCII checking whether make sets ${MAKE}... yes checking whether a default assembler was specified... no checking whether a default linker was specified... no checking for GNU C library... yes checking for gawk... no checking for mawk... mawk checking whether ln works... yes checking whether ln -s works... yes checking for ranlib... (cached) ranlib checking for a BSD compatible install... (cached) /usr/bin/install -c checking for ANSI C header files... (cached) yes checking whether time.h and sys/time.h may both be included... (cached) yes checking for working stdbool.h... yes checking whether string.h and strings.h may both be included... yes checking for sys/wait.h that is POSIX.1 compatible... (cached) yes checking for limits.h... (cached) yes checking for stddef.h... yes checking for string.h... (cached) yes checking for strings.h... (cached) yes checking for stdlib.h... (cached) yes checking for time.h... (cached) yes checking for fcntl.h... (cached) yes checking for unistd.h... (cached) yes checking for sys/file.h... (cached) yes checking for sys/time.h... (cached) yes checking for sys/resource.h... (cached) yes checking for sys/param.h... (cached) yes checking for sys/times.h... yes checking for sys/stat.h... (cached) yes checking for direct.h... no checking for malloc.h... yes checking for langinfo.h... yes checking for thread.h... no checking for pthread.h... yes checking for CHAR_BIT... yes checking byte ordering... little-endian checking floating point format... IEEE (little-endian) checking for gnatbind... no checking for mktemp... yes checking for makeinfo... makeinfo checking for modern makeinfo... yes checking for recent Pod::Man... yes checking for flex... flex checking for bison... bison checking for collect2 libraries... none required checking for library containing exc_resume... no checking for preprocessor stringizing operator... yes checking for inttypes.h... yes checking for strtoul... (cached) yes checking for bsearch... (cached) yes checking for popen... yes checking for times... (cached) yes checking for clock... (cached) yes checking for strchr... (cached) yes checking for strrchr... (cached) yes checking for kill... yes checking for getrlimit... yes checking for setrlimit... yes checking for atoll... yes checking for atoq... no checking for sysconf... (cached) yes checking for isascii... yes checking for gettimeofday... (cached) yes checking for strsignal... (cached) yes checking for putc_unlocked... yes checking for fputc_unlocked... yes checking for fputs_unlocked... yes checking for getrusage... (cached) yes checking for nl_langinfo... yes checking for lstat... yes checking for ssize_t... yes checking for uid_t in sys/types.h... yes checking type of array argument to getgroups... gid_t checking for vprintf... (cached) yes checking for strstr... (cached) yes checking whether the printf functions support %p... yes checking for pid_t... (cached) yes checking for vfork.h... (cached) no checking for working vfork... (cached) yes checking for getpagesize... (cached) yes checking for working mmap from /dev/zero... yes checking for working mmap with MAP_ANON(YMOUS)... yes checking for working mmap of a file... yes checking for iconv... yes checking for iconv declaration... extern size_t iconv (iconv_t cd, char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft); checking whether getenv is declared... yes checking whether atol is declared... yes checking whether sbrk is declared... yes checking whether abort is declared... yes checking whether atof is declared... yes checking whether getcwd is declared... yes checking whether getwd is declared... yes checking whether strsignal is declared... yes checking whether putc_unlocked is declared... yes checking whether fputs_unlocked is declared... yes checking whether strstr is declared... yes checking whether environ is declared... yes checking whether errno is declared... yes checking whether malloc is declared... yes checking whether realloc is declared... yes checking whether calloc is declared... yes checking whether free is declared... yes checking whether basename is declared... yes checking whether getopt is declared... yes checking whether clock is declared... yes checking whether getrlimit is declared... yes checking whether setrlimit is declared... yes checking whether getrusage is declared... yes checking whether times is declared... yes checking for struct tms... yes checking for clock_t... yes checking if mkdir takes one argument... no Using `../../src/gcc/config/i386/i386.c' for machine-specific logic. Using `../../src/gcc/config/i386/i386.md' as machine description file. Using the following target machine macro files: ../../src/gcc/config/i386/mingw32.h ../../src/gcc/config/i386/crtdll.h checking for strerror in -lcposix... no checking for working const... (cached) yes checking for off_t... yes checking for size_t... yes checking for argz.h... yes checking for limits.h... (cached) yes checking for locale.h... yes checking for nl_types.h... yes checking for malloc.h... (cached) yes checking for string.h... (cached) yes checking for unistd.h... (cached) yes checking for sys/param.h... (cached) yes checking for getcwd... (cached) yes checking for munmap... yes checking for putenv... (cached) yes checking for setenv... (cached) yes checking for setlocale... yes checking for strchr... (cached) yes checking for strcasecmp... (cached) yes checking for strdup... (cached) yes checking for __argz_count... yes checking for __argz_stringify... yes checking for __argz_next... yes checking for stpcpy... yes checking for LC_MESSAGES... yes checking whether NLS is requested... no checking what assembler to use... checking what nm to use... checking assembler alignment features... none checking assembler subsection support... no checking assembler weak support... no checking assembler hidden support... no checking assembler leb128 support... no checking assembler eh_frame optimization... no checking assembler instructions... checking assembler dwarf2 debug_line support... no Using ggc-page for garbage collection. checking whether to enable maintainer-specific portions of Makefiles... no Links are now set up to build a cross-compiler for i386-pc-mingw32 from i686-pc-linux-gnu. updating cache ../config.cache creating ./config.status creating Makefile creating intl/Makefile creating po/Makefile.in creating fixinc/Makefile creating gccbug creating mklibgcc creating auto-host.h linking ../../src/gcc/intl/libgettext.h to intl/libintl.h creating libintl.h == config.status =============================================================== #!/bin/sh # This file was generated automatically by configure. Do not edit. # This directory was configured as follows: ../src/configure --with-gcc-version-trigger=/home/megacz/gcc-3.1/src/gcc/version.c --host=i686-pc-linux-gnu --enable-threads=posix --prefix=/usr --enable-shared --enable-languages=c --disable-nls --target=mingw32 --norecursion # using "mh-frag" and "mt-frag" == build errors ================================================================ ... /home/megacz/gcc-3.1/bin/gcc/xgcc -B/home/megacz/gcc-3.1/bin/gcc/ -B/usr/mingw32/bin/ -B/usr/mingw32/lib/ -isystem /usr/mingw32/include -O2 -I../../src/gcc/..\/winsup/include -I../../src/gcc/../winsup/cygwin/include -I../../src/gcc/../winsup/w32api/include -DCROSS_COMPILE -DIN_GCC -W -Wall -Wwrite-strings -Wstric\t-prototypes -Wmissing-prototypes -isystem ./include -g1 -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../src/gcc -I\../../src/gcc/. -I../../src/gcc/config -I../../src/gcc/../include -DL_chkstk -xassembler-with-cpp -c ../../src/gcc/config/i386/cygwin.asm -o libgcc/./_chkstk.\o /home/megacz/gcc-3.1/bin/gcc/xgcc -B/home/megacz/gcc-3.1/bin/gcc/ -B/usr/mingw32/bin/ -B/usr/mingw32/lib/ -isystem /usr/mingw32/include -O2 -I../../src/gcc/..\/winsup/include -I../../src/gcc/../winsup/cygwin/include -I../../src/gcc/../winsup/w32api/include -DCROSS_COMPILE -DIN_GCC -W -Wall -Wwrite-strings -Wstric\t-prototypes -Wmissing-prototypes -isystem ./include -g1 -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../src/gcc -I\../../src/gcc/. -I../../src/gcc/config -I../../src/gcc/../include -DL_muldi3 -c ../../src/gcc/libgcc2.c -o libgcc/./_muldi3.o In file included from ../../src/gcc/config/i386/mingw32.h:25, from tconfig.h:4, from ../../src/gcc/libgcc2.c:36: ../../src/gcc/config/i386/cygwin.h:31:19: stdio.h: No such file or directory In file included from ../../src/gcc/config/i386/mingw32.h:25, from tconfig.h:4, from ../../src/gcc/libgcc2.c:36: ../../src/gcc/config/i386/cygwin.h:435: parse error before '*' token ../../src/gcc/config/i386/cygwin.h:435: warning: function declaration isn't a prototype ../../src/gcc/config/i386/cygwin.h:437: parse error before '*' token ../../src/gcc/config/i386/cygwin.h:437: warning: function declaration isn't a prototype make[2]: *** [libgcc/./_muldi3.o] Error 1 make[2]: Leaving directory `/home/megacz/gcc-3.1/bin/gcc' make[1]: *** [libgcc.a] Error 2 make[1]: Leaving directory `/home/megacz/gcc-3.1/bin/gcc' make: *** [all-gcc] Error 2 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: mingw32 target broken [cygwin as well] 2001-12-07 23:12 ` mingw32 target broken [cygwin as well] Adam Megacz @ 2001-12-07 23:40 ` Craig Rodrigues 2001-12-08 0:00 ` mingw32 target broken [cygwin as well] [didn't know cross-compilers were such an ordeal] Adam Megacz 2001-12-08 14:42 ` mingw32 target broken [cygwin as well] Jeff Sturm 1 sibling, 1 reply; 20+ messages in thread From: Craig Rodrigues @ 2001-12-07 23:40 UTC (permalink / raw) To: Adam Megacz; +Cc: gcc Hi, I don't think building a mingw cross compiler is a straightforward thing. You need the header files for the mingw runtime and for the w32api. See: http://members.telering.at/jessich/mingw/index.html http://sources.redhat.com/ml/crossgcc/2001-q4/msg00310.html And you might want to ask on the mingw mailing lists at http://www.mingw.org -- Craig Rodrigues http://www.gis.net/~craigr rodrigc@mediaone.net ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: mingw32 target broken [cygwin as well] [didn't know cross-compilers were such an ordeal] 2001-12-07 23:40 ` Craig Rodrigues @ 2001-12-08 0:00 ` Adam Megacz 2001-12-08 16:00 ` Jeff Sturm 0 siblings, 1 reply; 20+ messages in thread From: Adam Megacz @ 2001-12-08 0:00 UTC (permalink / raw) To: gcc Craig Rodrigues <rodrigc@mediaone.net> writes: > http://members.telering.at/jessich/mingw/index.html > http://sources.redhat.com/ml/crossgcc/2001-q4/msg00310.html Wow, I just checked out that patching script -- it's enormous! Why is it so hard to build a cross compiler? Shouldn't it be just like a regular compiler build, except that instead of using system libraries (/usr/lib), it uses alternate libraries (/usr/i686-pc-mingw)? AFAIK, what platform a compiler binary is compiled for really shouldn't have anything to do with what kind of binaries it puts out... it's not like the compiler copies bits of itself into the output... Oh well, I'm going to quit whining right now and ssh to a win98 machine running cygwin to do my builds. Thanks for the help... - a ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: mingw32 target broken [cygwin as well] [didn't know cross-compilers were such an ordeal] 2001-12-08 0:00 ` mingw32 target broken [cygwin as well] [didn't know cross-compilers were such an ordeal] Adam Megacz @ 2001-12-08 16:00 ` Jeff Sturm 2001-12-08 16:05 ` Adam Megacz 0 siblings, 1 reply; 20+ messages in thread From: Jeff Sturm @ 2001-12-08 16:00 UTC (permalink / raw) To: Adam Megacz; +Cc: gcc On 8 Dec 2001, Adam Megacz wrote: > > Craig Rodrigues <rodrigc@mediaone.net> writes: > > http://members.telering.at/jessich/mingw/index.html > > http://sources.redhat.com/ml/crossgcc/2001-q4/msg00310.html > > Wow, I just checked out that patching script -- it's enormous! Last time I looked at the mingw patches, it was mostly features that are not essential to building gcc, but desirable for windows users, e.g. anonymous structs. I've successfully built C cross compilers without any patches. (C++ may be problematic, especially for DLLs.) > Oh well, I'm going to quit whining right now and ssh to a win98 > machine running cygwin to do my builds. I may as well warn you that if you are doing any gcj work, there is a bug that prevents libgcj from bootstrapping on machines without case-sensitive filesystems (OSX on HFS, all Windows releases). http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&database=gcc&pr=2388 (If you find out that this is fixed on the trunk, let us know so we can close the PR!) A Linux-hosted cross compiler doesn't have this problem. (Besides, do you _really_ want to watch libtool on cygwin?) Jeff ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: mingw32 target broken [cygwin as well] [didn't know cross-compilers were such an ordeal] 2001-12-08 16:00 ` Jeff Sturm @ 2001-12-08 16:05 ` Adam Megacz 0 siblings, 0 replies; 20+ messages in thread From: Adam Megacz @ 2001-12-08 16:05 UTC (permalink / raw) To: gcc Jeff Sturm <jsturm@one-point.com> writes: > > Craig Rodrigues <rodrigc@mediaone.net> writes: > > > http://members.telering.at/jessich/mingw/index.html > > > http://sources.redhat.com/ml/crossgcc/2001-q4/msg00310.html > I may as well warn you that if you are doing any gcj work, there is > a bug that prevents libgcj from bootstrapping on machines without > case-sensitive filesystems (OSX on HFS, all Windows releases). Ugh, that's really bad... I was hoping to try for a cross compiler, and if that fails, fall back to ssh'ing to a cygwin machine for builds. Now it looks like the cross-compiler is my only hope... I've got from now until 16-Dec to get libgcj running on mingw. When I had hoped that this would be a simple-though-tedious process of pairing up java.* methods to Win32 API calls, with appropriate glue code... so far I've spent two days just trying to get a working compiler =) - a ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: mingw32 target broken [cygwin as well] 2001-12-07 23:12 ` mingw32 target broken [cygwin as well] Adam Megacz 2001-12-07 23:40 ` Craig Rodrigues @ 2001-12-08 14:42 ` Jeff Sturm 2001-12-08 16:04 ` mingw32 target broken [cygwin as well] [the saga continues] Adam Megacz 1 sibling, 1 reply; 20+ messages in thread From: Jeff Sturm @ 2001-12-08 14:42 UTC (permalink / raw) To: Adam Megacz; +Cc: gcc On 8 Dec 2001, Adam Megacz wrote: > Side note: this seems to happen with target=i386-pc-mingw and > target=i386-pc-cygwin as well. For those just joining the thread, I'm > using a fresh cvs checkout from a few hours ago. I haven't had much trouble building a cross compiler for mingw/cygwin in the past. Note however that gcc needs to find the target headers in $prefix/<target>/include, so you'll want to copy these before configuring gcc. (The CrossGCC faq hints that newlib targets can be built in one pass however, so cygwin might be a little easier starting from a unified tree.) > -isystem /usr/mingw32/include This is where gcc is looking for stdio.h... > ../../src/gcc/config/i386/cygwin.h:31:19: stdio.h: No such file or directory ...which is included from here. Looks like /usr/mingw32/include/stdio.h doesn't exist on your build machine. Jeff ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: mingw32 target broken [cygwin as well] [the saga continues] 2001-12-08 14:42 ` mingw32 target broken [cygwin as well] Jeff Sturm @ 2001-12-08 16:04 ` Adam Megacz 2001-12-08 18:19 ` Craig Rodrigues 0 siblings, 1 reply; 20+ messages in thread From: Adam Megacz @ 2001-12-08 16:04 UTC (permalink / raw) To: gcc Jeff Sturm <jsturm@one-point.com> writes: > Note however that gcc needs to find the target headers in > $prefix/<target>/include, so you'll want to copy these before > configuring gcc Ah, this was the problem. I also had to compile a set of cross-binutils. This time I got much farther -- it seems to get most of the C compiler to compile, but I'm running into problems with libstdc++... has anybody seen anything like this before? ../src/configure \ --prefix=/usr \ --enable-shared \ --enable-languages=c,c++,java \ --disable-nls \ --with-as=/usr/cross-binutils/i686-pc-mingw32/bin/as \ --target=i686-pc-mingw32 \ --with-gnu-ld \ --with-gnu-as \ --with-ld=/usr/cross-binutils/i686-pc-mingw32/bin/ld /home/megacz/gcc-3.1/bin/gcc/xgcc -B/home/megacz/gcc-3.1/bin/gcc/ -nostdinc++ -L/home/megacz/gcc-3.1/bin/i686-pc-mingw32/libstdc++-v3/src -L/home/megacz/gcc-3.1/bin/i686-pc-mingw32/libstdc++-v3/src/.libs -B/usr/i686-pc-mingw32/bin/ -B/usr/i686-pc-mingw32/lib/ -isystem /usr/i686-pc-mingw32/include -nostdinc++ -I/home/megacz/gcc-3.1/bin/i686-pc-mingw32/libstdc++-v3/include/i686-pc-mingw32 -I/home/megacz/gcc-3.1/bin/i686-pc-mingw32/libstdc++-v3/include -I../../../../src/libstdc++-v3/libsupc++ -I../../../../src/libstdc++-v3/libmath -g -O2 -fno-implicit-templates -Wall -Wno-format -W -Wwrite-strings -Winline -fdiagnostics-show-location=once -g -c basic_file.cc -o basic_file.o In file included from /home/megacz/gcc-3.1/bin/i686-pc-mingw32/libstdc++-v3/include/bits/locale_facets.h:54, from /home/megacz/gcc-3.1/bin/i686-pc-mingw32/libstdc++-v3/include/bits/basic_ios.h:41, from /home/megacz/gcc-3.1/bin/i686-pc-mingw32/libstdc++-v3/include/bits/std_ios.h:51, from /home/megacz/gcc-3.1/bin/i686-pc-mingw32/libstdc++-v3/include/bits/basic_file.h:45, from basic_file.cc:34: /home/megacz/gcc-3.1/bin/i686-pc-mingw32/libstdc++-v3/include/i686-pc-mingw32/bits/ctype_base.h:46: ` _U' was not declared in this scope /home/megacz/gcc-3.1/bin/i686-pc-mingw32/libstdc++-v3/include/i686-pc-mingw32/bits/ctype_base.h:47: ` _L' was not declared in this scope /home/megacz/gcc-3.1/bin/i686-pc-mingw32/libstdc++-v3/include/i686-pc-mingw32/bits/ctype_base.h:48: ` _U' was not declared in this scope /home/megacz/gcc-3.1/bin/i686-pc-mingw32/libstdc++-v3/include/i686-pc-mingw32/bits/ctype_base.h:48: ` _L' was not declared in this scope ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: mingw32 target broken [cygwin as well] [the saga continues] 2001-12-08 16:04 ` mingw32 target broken [cygwin as well] [the saga continues] Adam Megacz @ 2001-12-08 18:19 ` Craig Rodrigues 2001-12-08 18:30 ` Adam Megacz 0 siblings, 1 reply; 20+ messages in thread From: Craig Rodrigues @ 2001-12-08 18:19 UTC (permalink / raw) To: Adam Megacz; +Cc: gcc On Sat, Dec 08, 2001 at 07:01:06PM -0500, Adam Megacz wrote: > > _U' was not declared in this scope > /home/megacz/gcc-3.1/bin/i686-pc-mingw32/libstdc++-v3/include/i686-pc-mingw32/bits/ctype_base.h:47: ` > _L' was not declared in this scope > /home/megacz/gcc-3.1/bin/i686-pc-mingw32/libstdc++-v3/include/i686-pc-mingw32/bits/ctype_base.h:48: ` > _U' was not declared in this scope > /home/megacz/gcc-3.1/bin/i686-pc-mingw32/libstdc++-v3/include/i686-pc-mingw32/bits/ctype_base.h:48: ` > _L' was not declared in this scope Hi, Check out this thread on the libstdc++ mailing list: http://gcc.gnu.org/ml/libstdc++/2001-03/msg00131.html http://gcc.gnu.org/ml/libstdc++/2001-03/msg00134.html http://gcc.gnu.org/ml/libstdc++/2001-03/msg00143.html and this patch from bkoz: http://gcc.gnu.org/ml/libstdc++/2001-03/msg00144.html -- Craig Rodrigues http://www.gis.net/~craigr rodrigc@mediaone.net ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: mingw32 target broken [cygwin as well] [the saga continues] 2001-12-08 18:19 ` Craig Rodrigues @ 2001-12-08 18:30 ` Adam Megacz 2001-12-08 18:39 ` Craig Rodrigues 2001-12-09 9:07 ` Jeff Sturm 0 siblings, 2 replies; 20+ messages in thread From: Adam Megacz @ 2001-12-08 18:30 UTC (permalink / raw) To: gcc Craig Rodrigues <rodrigc@mediaone.net> writes: > > _U' was not declared in this scope > > /home/megacz/gcc-3.1/bin/i686-pc-mingw32/libstdc++-v3/include/i686-pc-mingw32/bits/ctype_base.h:47: ` > > _L' was not declared in this scope > > /home/megacz/gcc-3.1/bin/i686-pc-mingw32/libstdc++-v3/include/i686-pc-mingw32/bits/ctype_base.h:48: ` > > _U' was not declared in this scope > > /home/megacz/gcc-3.1/bin/i686-pc-mingw32/libstdc++-v3/include/i686-pc-mingw32/bits/ctype_base.h:48: ` > > _L' was not declared in this scope > > and this patch from bkoz: > http://gcc.gnu.org/ml/libstdc++/2001-03/msg00144.html A bit stale, but I was able to hand-edit for the same effect, and it worked. I'm not too familiar with the administrative end of the gcc project -- is there some patch-approval process that patches like this have not gone through? Is that why they don't end up getting back into the trunk? Otherwise, may I post a diff to the latest CVS in the hopes of getting it folded in? I've also noticed that the configure in the root directory of the gcc checkout does not pass the --target=$TARGET option to the invocation of configure for libstdc++-v3, although it does pass --with-target-dir -- can anybody verify this and/or advise me on how to fix it "the right way"? (right now I'm just manually re-running configure for libstdc++-v3). - a ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: mingw32 target broken [cygwin as well] [the saga continues] 2001-12-08 18:30 ` Adam Megacz @ 2001-12-08 18:39 ` Craig Rodrigues 2001-12-08 18:56 ` Adam Megacz 2001-12-09 9:07 ` Jeff Sturm 1 sibling, 1 reply; 20+ messages in thread From: Craig Rodrigues @ 2001-12-08 18:39 UTC (permalink / raw) To: Adam Megacz; +Cc: gcc On Sat, Dec 08, 2001 at 09:20:37PM -0500, Adam Megacz wrote: > I'm not too familiar with the administrative end of the gcc project -- > is there some patch-approval process that patches like this have not > gone through? Is that why they don't end up getting back into the > trunk? Otherwise, may I post a diff to the latest CVS in the hopes of > getting it folded in? The gcc patch submission guidelines are here: http://gcc.gnu.org/contribute.html If you have a patch that solves a problem, then definitely contribute it. The GCC patch review process is not always automatic though, because the people involved with GCC development are very busy, so you sometimes need to send out reminder e-mails. -- Craig Rodrigues http://www.gis.net/~craigr rodrigc@mediaone.net ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: mingw32 target broken [cygwin as well] [the saga continues] 2001-12-08 18:39 ` Craig Rodrigues @ 2001-12-08 18:56 ` Adam Megacz 0 siblings, 0 replies; 20+ messages in thread From: Adam Megacz @ 2001-12-08 18:56 UTC (permalink / raw) To: gcc Craig Rodrigues <rodrigc@mediaone.net> writes: > If you have a patch that solves a problem, then definitely > contribute it. Sounds good. If/when I finally get a working cross compiler, I'll build up a patch and try to get it accepted. I'm going to be releasing an open source project on 01-Jan-02 that targets mingw, so it'd be really nice if I could tell people interested in building it to just "cvs -z9 co -D $SOME_DATE_KNOWN_TO_WORK gcc" instead of having to go through a long list of patches/hacks... - a ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: mingw32 target broken [cygwin as well] [the saga continues] 2001-12-08 18:30 ` Adam Megacz 2001-12-08 18:39 ` Craig Rodrigues @ 2001-12-09 9:07 ` Jeff Sturm 2001-12-09 20:38 ` Adam Megacz 2001-12-10 12:36 ` DJ Delorie 1 sibling, 2 replies; 20+ messages in thread From: Jeff Sturm @ 2001-12-09 9:07 UTC (permalink / raw) To: Adam Megacz; +Cc: gcc On 8 Dec 2001, Adam Megacz wrote: > > http://gcc.gnu.org/ml/libstdc++/2001-03/msg00144.html > > A bit stale, but I was able to hand-edit for the same effect, and it > worked. A dirty little secret: if all you want is the java runtime, you can skip building libstdc++. Just remove it from the toplevel Makefile. Unfortunately, libjava assumes cross compilers target newlib, just as libstdc++ does... if test -n "${with_cross_host}"; then # We are being configured with a cross compiler. AC_REPLACE_FUNCS # may not work correctly, because the compiler may not be able to # link executables. # We assume newlib. This lets us hard-code the functions we know # we'll have. This never seemed like desirable behavior to me, in part because newlib isn't even GNU software. I'd prefer that configure attempt to link a program before it assumes it cannot. > I've also noticed that the configure in the root directory of the gcc > checkout does not pass the --target=$TARGET option to the invocation > of configure for libstdc++-v3, although it does pass --with-target-dir In the target subdirs, "target" becomes "host". Jeff ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: mingw32 target broken [cygwin as well] [the saga continues] 2001-12-09 9:07 ` Jeff Sturm @ 2001-12-09 20:38 ` Adam Megacz 2001-12-10 12:36 ` DJ Delorie 1 sibling, 0 replies; 20+ messages in thread From: Adam Megacz @ 2001-12-09 20:38 UTC (permalink / raw) To: gcc Jeff Sturm <jsturm@one-point.com> writes: > A dirty little secret: if all you want is the java runtime, you can skip > building libstdc++. Just remove it from the toplevel Makefile. > > Unfortunately, libjava assumes cross compilers target newlib, just as > libstdc++ does... > > if test -n "${with_cross_host}"; then > # We are being configured with a cross compiler. AC_REPLACE_FUNCS > # may not work correctly, because the compiler may not be able to > # link executables. > > # We assume newlib. This lets us hard-code the functions we know > # we'll have. Okay, I think I've worked around this for libstdc++-v3... can somebody with more gcc-hacking experience let me know if this is too kludgey to submit to gcc-patches@gcc.gnu.org? I basically just special-cased out mingw32 with the stuff that I know it doesn't have (said knowledge was acquired by the highly scientific process of trial and error until it built). I'd like to do a more elegant job, but I don't really understand gcc's autoconf setup to come up with anything cleaner. I've also put this patch into http://www.xwt.org/creating.a.mingw.crosscompiler.html - a Index: configure.in =================================================================== RCS file: /cvs/gcc/gcc/libstdc++-v3/configure.in,v retrieving revision 1.79 diff -c -3 -p -r1.79 configure.in *** configure.in 2001/12/03 22:28:57 1.79 --- configure.in 2001/12/10 04:28:53 *************** if test -n "$with_cross_host" || test x" *** 124,129 **** --- 124,132 ---- AC_DEFINE(HAVE_SINCOS) AC_DEFINE(HAVE_SINCOSF) ;; + *-mingw*) + os_include_dir="config/os/mingw32" + ;; *) os_include_dir="config/os/newlib" AC_DEFINE(HAVE_HYPOT) *************** if test -n "$with_cross_host" || test x" *** 136,171 **** # AC_FUNC_MMAP AC_DEFINE(HAVE_MMAP) ! AC_DEFINE(HAVE_ACOSF) ! AC_DEFINE(HAVE_ASINF) ! AC_DEFINE(HAVE_ATAN2F) ! AC_DEFINE(HAVE_ATANF) ! AC_DEFINE(HAVE_CEILF) ! AC_DEFINE(HAVE_COPYSIGN) ! AC_DEFINE(HAVE_COPYSIGNF) ! AC_DEFINE(HAVE_COSF) ! AC_DEFINE(HAVE_COSHF) ! AC_DEFINE(HAVE_EXPF) ! AC_DEFINE(HAVE_FABSF) ! AC_DEFINE(HAVE_FINITE) ! AC_DEFINE(HAVE_FINITEF) ! AC_DEFINE(HAVE_FLOORF) ! AC_DEFINE(HAVE_FMODF) ! AC_DEFINE(HAVE_FREXPF) ! AC_DEFINE(HAVE_ISINF) ! AC_DEFINE(HAVE_ISINFF) ! AC_DEFINE(HAVE_ISNAN) ! AC_DEFINE(HAVE_ISNANF) ! AC_DEFINE(HAVE_LDEXPF) ! AC_DEFINE(HAVE_LOG10F) ! AC_DEFINE(HAVE_LOGF) ! AC_DEFINE(HAVE_MODFF) ! AC_DEFINE(HAVE_POWF) ! AC_DEFINE(HAVE_SINF) ! AC_DEFINE(HAVE_SINHF) ! AC_DEFINE(HAVE_SQRTF) ! AC_DEFINE(HAVE_TANF) ! AC_DEFINE(HAVE_TANHF) # At some point, we should differentiate between architectures # like x86, which have long double versions, and alpha/powerpc/etc., --- 139,179 ---- # AC_FUNC_MMAP AC_DEFINE(HAVE_MMAP) ! case "$target_alias" in ! *-mingw*) ! ;; ! *) ! AC_DEFINE(HAVE_ACOSF) ! AC_DEFINE(HAVE_ASINF) ! AC_DEFINE(HAVE_ATAN2F) ! AC_DEFINE(HAVE_ATANF) ! AC_DEFINE(HAVE_CEILF) ! AC_DEFINE(HAVE_COPYSIGN) ! AC_DEFINE(HAVE_COPYSIGNF) ! AC_DEFINE(HAVE_COSF) ! AC_DEFINE(HAVE_COSHF) ! AC_DEFINE(HAVE_EXPF) ! AC_DEFINE(HAVE_FABSF) ! AC_DEFINE(HAVE_FINITE) ! AC_DEFINE(HAVE_FINITEF) ! AC_DEFINE(HAVE_FLOORF) ! AC_DEFINE(HAVE_FMODF) ! AC_DEFINE(HAVE_FREXPF) ! AC_DEFINE(HAVE_ISINF) ! AC_DEFINE(HAVE_ISINFF) ! AC_DEFINE(HAVE_ISNAN) ! AC_DEFINE(HAVE_ISNANF) ! AC_DEFINE(HAVE_LDEXPF) ! AC_DEFINE(HAVE_LOG10F) ! AC_DEFINE(HAVE_LOGF) ! AC_DEFINE(HAVE_MODFF) ! AC_DEFINE(HAVE_POWF) ! AC_DEFINE(HAVE_SINF) ! AC_DEFINE(HAVE_SINHF) ! AC_DEFINE(HAVE_SQRTF) ! AC_DEFINE(HAVE_TANF) ! AC_DEFINE(HAVE_TANHF) ! esac # At some point, we should differentiate between architectures # like x86, which have long double versions, and alpha/powerpc/etc., ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: mingw32 target broken [cygwin as well] [the saga continues] 2001-12-09 9:07 ` Jeff Sturm 2001-12-09 20:38 ` Adam Megacz @ 2001-12-10 12:36 ` DJ Delorie 2001-12-10 12:48 ` Joseph S. Myers 2001-12-10 21:06 ` Jeff Sturm 1 sibling, 2 replies; 20+ messages in thread From: DJ Delorie @ 2001-12-10 12:36 UTC (permalink / raw) To: jsturm; +Cc: gcc > This never seemed like desirable behavior to me, in part because newlib > isn't even GNU software. I'd prefer that configure attempt to link a > program before it assumes it cannot. Newlib is an operating system, just like solaris or IRIX. It doesn't have to be GNU software for us to support it, it just has to support and allow GNU software. And you can't always do a test link with cross compilers, because you may not have built enough support stuff (crt0, libc, gas/ld) to do so. In fact, for a canadian cross, you can't link *at all* because you just can't run the linker. Newlib is a popular target for GNU tools, so people have contributed extra support for it. There are other platforms we do this for, like cygwin and vxworks. > > I've also noticed that the configure in the root directory of the gcc > > checkout does not pass the --target=$TARGET option to the invocation > > of configure for libstdc++-v3, although it does pass --with-target-dir > > In the target subdirs, "target" becomes "host". Yeah, that confuses people, but it does make sense. "host" is what you're building *for*. For target libraries, you're building for the --target, so $host is --target. $build is what you're building *on*. $host is what you're building *for*. $target is what the stuff you're building produces code for. With these definitions, it's meaningless to use $target with a library, because libraries do not themselves produce code. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: mingw32 target broken [cygwin as well] [the saga continues] 2001-12-10 12:36 ` DJ Delorie @ 2001-12-10 12:48 ` Joseph S. Myers 2001-12-10 12:57 ` DJ Delorie 2001-12-10 21:06 ` Jeff Sturm 1 sibling, 1 reply; 20+ messages in thread From: Joseph S. Myers @ 2001-12-10 12:48 UTC (permalink / raw) To: DJ Delorie; +Cc: jsturm, gcc On Mon, 10 Dec 2001, DJ Delorie wrote: > (crt0, libc, gas/ld) to do so. In fact, for a canadian cross, you > can't link *at all* because you just can't run the linker. But for a Canadian cross, surely you should have a full build x target toolchain - including the linker and target libraries - installed (as well as a build x host one) before building the Canadian cross? (At least, etc/configure.texi in src says so.) -- Joseph S. Myers jsm28@cam.ac.uk ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: mingw32 target broken [cygwin as well] [the saga continues] 2001-12-10 12:48 ` Joseph S. Myers @ 2001-12-10 12:57 ` DJ Delorie 0 siblings, 0 replies; 20+ messages in thread From: DJ Delorie @ 2001-12-10 12:57 UTC (permalink / raw) To: jsm28; +Cc: jsturm, gcc > But for a Canadian cross, surely you should have a full build x target > toolchain - including the linker and target libraries - installed (as well > as a build x host one) before building the Canadian cross? (At least, > etc/configure.texi in src says so.) There's no guarantee it's the same version as the library you're building though. But you're right, we should have a working linker. It's *executing* the tests that you can't rely on. And for Cygwin it's even worse, as parts of libiberty.a are used to build cygwin1.dll, so if you did the linking test you wouldn't build the very functions cygwin pulls from libiberty to build the dll! ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: mingw32 target broken [cygwin as well] [the saga continues] 2001-12-10 12:36 ` DJ Delorie 2001-12-10 12:48 ` Joseph S. Myers @ 2001-12-10 21:06 ` Jeff Sturm 2001-12-10 21:08 ` DJ Delorie 1 sibling, 1 reply; 20+ messages in thread From: Jeff Sturm @ 2001-12-10 21:06 UTC (permalink / raw) To: DJ Delorie; +Cc: gcc On Mon, 10 Dec 2001, DJ Delorie wrote: > Newlib is an operating system, just like solaris or IRIX. It doesn't > have to be GNU software for us to support it, it just has to support > and allow GNU software. Yeah. It's just that assuming a non-GNU runtime doesn't seem to fit the ideology. (Not that GNU has anything better for embedded use... at least newlib is free software.) > And you can't always do a test link with > cross compilers, because you may not have built enough support stuff > (crt0, libc, gas/ld) to do so. But it helps if you do. When I build a cross compiler, I typically follow these steps: 1) Install target runtime headers. 2) Build/install cross binutils. 3) Build/install C cross compiler. 4) Build/install target runtime libraries. 5) Build/install other languages (c++, java). At step 5) I have everything I need for AC_TRY_LINK. I could save a lot of time if configure would first attempt to link, falling back on the newlib guesses. > > In the target subdirs, "target" becomes "host". > > Yeah, that confuses people, but it does make sense. "host" is what > you're building *for*. For target libraries, you're building for the > --target, so $host is --target. That's how I understood it. But I looked in libstdc++-v3 and libjava... the former has a configure.target script, the latter configure.host. So that interpretation isn't uniform throughout GCC. Jeff ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: mingw32 target broken [cygwin as well] [the saga continues] 2001-12-10 21:06 ` Jeff Sturm @ 2001-12-10 21:08 ` DJ Delorie 0 siblings, 0 replies; 20+ messages in thread From: DJ Delorie @ 2001-12-10 21:08 UTC (permalink / raw) To: jsturm; +Cc: gcc > > Yeah, that confuses people, but it does make sense. "host" is what > > you're building *for*. For target libraries, you're building for the > > --target, so $host is --target. > > That's how I understood it. But I looked in libstdc++-v3 and libjava... > the former has a configure.target script, the latter configure.host. So > that interpretation isn't uniform throughout GCC. I *told* you it confuses people ;-) ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2001-12-11 5:06 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-12-07 21:06 mingw32 target broken Adam Megacz
2001-12-07 22:01 ` Adam Megacz
[not found] ` <20011208003722.A14955@mediaone.net>
2001-12-07 23:12 ` mingw32 target broken [cygwin as well] Adam Megacz
2001-12-07 23:40 ` Craig Rodrigues
2001-12-08 0:00 ` mingw32 target broken [cygwin as well] [didn't know cross-compilers were such an ordeal] Adam Megacz
2001-12-08 16:00 ` Jeff Sturm
2001-12-08 16:05 ` Adam Megacz
2001-12-08 14:42 ` mingw32 target broken [cygwin as well] Jeff Sturm
2001-12-08 16:04 ` mingw32 target broken [cygwin as well] [the saga continues] Adam Megacz
2001-12-08 18:19 ` Craig Rodrigues
2001-12-08 18:30 ` Adam Megacz
2001-12-08 18:39 ` Craig Rodrigues
2001-12-08 18:56 ` Adam Megacz
2001-12-09 9:07 ` Jeff Sturm
2001-12-09 20:38 ` Adam Megacz
2001-12-10 12:36 ` DJ Delorie
2001-12-10 12:48 ` Joseph S. Myers
2001-12-10 12:57 ` DJ Delorie
2001-12-10 21:06 ` Jeff Sturm
2001-12-10 21:08 ` DJ Delorie
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).