building GCC 4.0 for arm-elf target on mingw host
Hi, I've been attempting to build the gcc-4.0 20050319 snapshot under mingw/msys for arm-elf target with a few problems. the mingw32 gcc is 3.4.2 Configuring seems to work fine. ../../$GCC_SRCDIR/configure \ --enable-languages=c,c++ \ --enable-interwork --enable-multilib\ --with-gcc --with-gnu-ld --with-gnu-as --with-stabs \ --disable-shared --disable-threads --disable-win32-registry --disable-nls\ --target=arm-elf \ --with-newlib \ --prefix=c:/devkitARM_r12 proceeding with make all-gcc results in a number of weird errors configuring in subdirectories Configuring in intl make[1]: Entering directory `/c/projects/devkitPro/sources/arm-elf/gcc/intl' make[1]: *** No rule to make target `all'. Stop. make[1]: Leaving directory `/c/projects/devkitPro/sources/arm-elf/gcc/intl' make: *** [all-intl] Error 2 The build process doesn't stop but carries on with configuring (in some cases displaying the command prompt as if the build had stopped). Removing the files from the subdirectory in the build directory & restarting make all-gcc allows me to continue but results in the same error in a number of subdirectories. After 3 or 4 restarts it finally appears to proceed normally until building libgcc make[3]: Leaving directory `/c/projects/devkitPro/sources/arm-elf/gcc/gcc' /c/projects/devkitPro/sources/arm-elf/gcc/gcc/xgcc -B/c/projects/devkitPro/sources/arm-elf/gcc/gcc/ -Bc:/devkitARM_r12/arm-elf/bin/ -Bc:/devkitARM_r12/arm-elf/lib/ -isystem c:/devkitARM_r12/arm-elf/include -isystem c:/devkitARM_r12/arm-elf/sys-include -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -Dinhibit_libc -fno-inline -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I -I../../../gcc-4.0-20050319-new/gcc -I../../../gcc-4.0-20050319-new/gcc/ -I../../../gcc-4.0-20050319-new/gcc/../include -I../../../gcc-4.0-20050319-new/gcc/../libcpp/include -DL_muldi3 -c ../../../gcc-4.0-20050319-new/gcc/libgcc2.c -o libgcc/./_muldi3.o In file included from ../../../gcc-4.0-20050319-new/gcc/libgcc2.c:43: ./tm.h:5:28: error: config/dbxelf.h: No such file or directory ./tm.h:6:27: error: config/elfos.h: No such file or directory ./tm.h:7:37: error: config/arm/unknown-elf.h: No such file or directory ./tm.h:8:29: error: config/arm/elf.h: No such file or directory ./tm.h:9:30: error: config/arm/aout.h: No such file or directory ./tm.h:10:29: error: config/arm/arm.h: No such file or directory ./tm.h:11:23: error: defaults.h: No such file or directory In file included from ../../../gcc-4.0-20050319-new/gcc/libgcc2.c:56: ../../../gcc-4.0-20050319-new/gcc/libgcc2.h:230:3: error: #error "expand the table" ../../../gcc-4.0-20050319-new/gcc/libgcc2.c: In function '__mulhi3': ../../../gcc-4.0-20050319-new/gcc/libgcc2.c:527: error: 'BITS_PER_UNIT' undeclared (first use in this function) ../../../gcc-4.0-20050319-new/gcc/libgcc2.c:527: error: (Each undeclared identifier is reported only once ../../../gcc-4.0-20050319-new/gcc/libgcc2.c:527: error: for each function it appears in.) make[2]: *** [libgcc/./_muldi3.o] Error 1 make[2]: Leaving directory `/c/projects/devkitPro/sources/arm-elf/gcc/gcc' make[1]: *** [stmp-multilib] Error 2 make[1]: Leaving directory `/c/projects/devkitPro/sources/arm-elf/gcc/gcc' make: *** [all-gcc] Error 2 copying the compile line and removing the spurious -I and the -I../../../gcc-4.0-20050319-new/gcc/ results in no errors. I'm having a little trouble finding where this line is built up in the makefiles, can anyone point me in the right direction to solve this problem? Dave
Re: building GCC 4.0 for arm-elf target on mingw host
E. Weddington wrote: Dave Murphy wrote: copying the compile line and removing the spurious -I and the -I../../../gcc-4.0-20050319-new/gcc/ results in no errors. I'm having a little trouble finding where this line is built up in the makefiles, can anyone point me in the right direction to solve this problem? Interesting. I just got a similar error with building an avr cross in the latest MinGW/MSYS for gcc 3.4.3. Reported here: <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20594> Now I'm wondering whether it's a gcc bug or if it's an MSYS bug. I can successfully build gcc for the avr target using cygwin with -mno-cygwin and explicitly setting the build and host. Danny pointed me to a patch on the mingw mailing list which fixes it for me on win2kpro http://sourceforge.net/tracker/?func=detail&atid=102435&aid=1053052&group_id=2435 Dave
Re: Error building 4.0.1: input.h: No such file...
Chris Garrett wrote: I built 4.0.0 last week and thought I would update to 4.0.1. While building 401 I got the following error: -- gcc -c -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wno-error -DHAVE_CONFIG_H -DGENERATOR_FILE-I. -Ibuild -I/d/developer/src/gcc-4.0.1/gcc -I/d/developer/src/gcc-4.0.1/gcc/build -I/d/developer/src/gcc-4.0.1/gcc/../include -I/d/developer/src/gcc-4.0.1/gcc/../libcpp/include -I/usr/local/gmp-4.1.4/include \ -o build/gengtype-yacc.o /d/developer/src/gcc-4.0.1/gcc/gengtype-yacc.c gcc -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition-DHAVE_CONFIG_H -DGENERATOR_FILE -s -o build/gengtype.exe \ build/gengtype.o build/gengtype-lex.o build/gengtype-yacc.o \ build/errors.o ../build-i686-pc-mingw32/libiberty/libiberty.a build/gengtype.exe /d/developer/src/gcc-4.0.1/gcc/input.h: No such file or directory make[2]: *** [s-gtype] Error 1 make[2]: Leaving directory `/d/developer/projects/chinook_lib/gcc/build/gcc' make[1]: *** [stage1_build] Error 2 make[1]: Leaving directory `/d/developer/projects/chinook_lib/gcc/build/gcc' make: *** [bootstrap] Error 2 -- The file exists in that location so I'm not sure what to do with this. I'm building on winxp pro, GCC 3.4.1 using Msys. Config line: -- ../gcc-4.0.1/configure \ --prefix=/mingw \ --with-gcc \ --with-gnu-ld \ --with-gnu-as \ --enable-threads \ --disable-shared \ --disable-nls \ --enable-languages=c,c++,f95 \ --disable-win32-registry \ --with-gmp=/usr/local/gmp-4.1.4 Make cmd: -- make \ CFLAGS="-O2 -march=i686 -fomit-frame-pointer" \ CXXFLAGS="-mthreads -O2 -march=i686 -fomit-frame-pointer" \ LIBCFLAGS="-O2" \ LIBCXXFLAGS="-O2 -fno-implicit-templates" \ LDFLAGS="-s" \ bootstrap this patch should sort you out Index: gcc/c-incpath.c === RCS file: /cvs/gcc/gcc/gcc/c-incpath.c,v retrieving revision 1.21 diff -c -3 -p -r1.21 c-incpath.c *** gcc/c-incpath.c23 Jan 2005 15:05:27 -1.21 --- gcc/c-incpath.c23 Feb 2005 19:39:49 - *** add_path (char *path, int chain, int cxx *** 331,343 cpp_dir *p; #if defined (HAVE_DOS_BASED_FILE_SYSTEM) ! /* Convert all backslashes to slashes. The native CRT stat() ! function does not recognize a directory that ends in a backslash ! (unless it is a drive root dir, such "c:\"). Forward slashes, ! trailing or otherwise, cause no problems for stat(). */ ! char* c; ! for (c = path; *c; c++) ! if (*c == '\\') *c = '/'; #endif p = xmalloc (sizeof (cpp_dir)); --- 331,348 cpp_dir *p; #if defined (HAVE_DOS_BASED_FILE_SYSTEM) ! /* Remove unnecessary trailing slashes. On some versions of MS ! Windows, trailing _forward_ slashes cause no problems for stat(). ! On newer versions, stat() does not recognise a directory that ends ! in a '\\' or '/', unless it is a drive root dir, such as "c:/", ! where it is obligatory. */ ! int pathlen = strlen (path); ! char* end = path + pathlen - 1; ! /* Preserve the lead '/' or lead "c:/". */ ! char* start = path + (pathlen > 2 && path[1] == ':' ? 3 : 1); ! ! for (; end > start && IS_DIR_SEPARATOR (*end); end--) ! *end = 0; #endif p = xmalloc (sizeof (cpp_dir));
Building mips cross compiler on mingw
Hi, I've been having some trouble building gcc 4.0.1 for mips target on a mingw host The build fails at this point /c/projects/devkitPro/sources/psp/gcc/gcc/xgcc -B/c/projects/devkitPro/sources/psp/gcc/gcc/ -Bc:/devkitPro/devkitPSP_4.0.1/psp/bin/ -Bc:/devkitPro/devkitPSP_4.0.1/psp/lib/ -isystem c:/devkitPro/devkitPSP_4.0.1/psp/include -isystem c:/devkitPro/devkitPSP_4.0.1/psp/sys-include -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -G 0 -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I -I../../../gcc-4.0.1-new/gcc -I../../../gcc-4.0.1-new/gcc/ -I../../../gcc-4.0.1-new/gcc/../include -I../../../gcc-4.0.1-new/gcc/../libcpp/include -DL_muldi3 -c ../../../gcc-4.0.1-new/gcc/libgcc2.c -o libgcc/./_muldi3.o C:/DOCUME~1/DAVEMN~1.000/LOCALS~1/Temp/ccAF.s: Assembler messages: C:/DOCUME~1/DAVEMN~1.000/LOCALS~1/Temp/ccAF.s:19: Warning: expected `$' C:/DOCUME~1/DAVEMN~1.000/LOCALS~1/Temp/ccAF.s:19: Error: junk at end of line, first unrecognized character is `n' make[2]: *** [libgcc/./_muldi3.o] Error 1 make[2]: Leaving directory `/c/projects/devkitPro/sources/psp/gcc/gcc' make[1]: *** [stmp-multilib] Error 2 make[1]: Leaving directory `/c/projects/devkitPro/sources/psp/gcc/gcc' make: *** [all-gcc] Error 2 Error building all-gcc saving temp files and adding -v gives this Reading specs from c:/projects/devkitPro/sources/psp/gcc/gcc/specs Target: psp Configured with: ../../gcc-4.0.1-new/configure --enable-languages=c,c++ --disable-multilib --with-gcc --with-gnu-ld --with-gnu-as --with-stabs --disable-shared --disable-win32-registry --disable-nls --enable-cxx-flags=-G0 --target=psp --with-newlib --prefix=c:/devkitPro/devkitPSP_4.0.1 Thread model: single gcc version 4.0.1 c:/projects/devkitPro/sources/psp/gcc/gcc/cc1.exe -E -quiet -v -I. -I -I../../../gcc-4.0.1-new/gcc -I../../../gcc-4.0.1-new/gcc/ -I../../../gcc-4.0.1-new/gcc/../include -I../../../gcc-4.0.1-new/gcc/../libcpp/include -iprefix c:\projects\devkitpro\sources\psp\gcc\gcc\../lib/gcc/psp/4.0.1/ -isystem c:/projects/devkitPro/sources/psp/gcc/gcc/include -DIN_GCC -DCROSS_COMPILE -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -DL_muldi3 -isystem c:/devkitPro/devkitPSP_4.0.1/psp/include -isystem c:/devkitPro/devkitPSP_4.0.1/psp/sys-include -isystem ./include ../../../gcc-4.0.1-new/gcc/libgcc2.c -G 0 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -fworking-directory -O2 -fpch-preprocess -o libgcc2.i ignoring nonexistent directory "c:/devkitPro/devkitPSP_4.0.1/psp/include" ignoring nonexistent directory "c:/devkitPro/devkitPSP_4.0.1/psp/sys-include" ignoring nonexistent directory "c:\projects\devkitpro\sources\psp\gcc\gcc\../lib/gcc/psp/4.0.1/include" ignoring nonexistent directory "c:\projects\devkitpro\sources\psp\gcc\gcc\../lib/gcc/psp/4.0.1/../../../../psp/sys-include" ignoring nonexistent directory "c:\projects\devkitpro\sources\psp\gcc\gcc\../lib/gcc/psp/4.0.1/../../../../psp/include" ignoring nonexistent directory "c:/devkitPro/devkitPSP_4.0.1/lib/gcc/psp/4.0.1/include" ignoring nonexistent directory "c:/devkitPro/devkitPSP_4.0.1/lib/../psp/sys-include" ignoring nonexistent directory "c:/devkitPro/devkitPSP_4.0.1/lib/../psp/include" ignoring nonexistent directory "-I../../../gcc-4.0.1-new/gcc" #include "..." search starts here: #include <...> search starts here: . ../../../gcc-4.0.1-new/gcc ../../../gcc-4.0.1-new/gcc/../include ../../../gcc-4.0.1-new/gcc/../libcpp/include c:/projects/devkitPro/sources/psp/gcc/gcc/include ./include End of search list. c:/projects/devkitPro/sources/psp/gcc/gcc/cc1.exe -fpreprocessed libgcc2.i -G 0 -quiet -dumpbase libgcc2.c -auxbase-strip libgcc/./_muldi3.o -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -version -o libgcc2.s GNU C version 4.0.1 (psp) compiled by GNU C version 3.4.2 (mingw-special). GGC heuristics: --param ggc-min-expand=56 --param ggc-min-heapsize=49086 c:/devkitPro/devkitPSP_4.0.1/psp/bin/as.exe --traditional-format -G 0 -EL -O2 -g -no-mdebug -mabi=eabi -v -o libgcc/./_muldi3.o libgcc2.s GNU assembler version 2.16.1 (psp) using BFD version 2.16.1 libgcc2.s: Assembler messages: libgcc2.s:19: Warning: expected `$' libgcc2.s:19: Error: junk at end of line, first unrecognized character is `n' I've attached the saved temp files. The same build process works fine on linux and I've compared output. The preprocessed source is identical barring paths. The assembly output differs only in the function prologue on mingw built compiler __muldi3: .frame$sp,0,(null)# vars= 7640055, regs= 0/0, args= 0, gp= 0 on linux built compiler __muldi3: .frame$sp,0,$31# vars= 0, regs= 0/0, args= 0, gp= 0 can anyone point me in the right direction? I'm not quite sure what I should be looking for. Dave # 1 "../../../gcc-4.0
Re: Building mips cross compiler on mingw
Dave Korn wrote: I've been having some trouble building gcc 4.0.1 for mips target on a mingw host No you aren't. You're using a modified version of the gcc-4.0.1 sources and you're targetting PSP. That may be a MIPS backend, but it's a different _target_. :) fair enough, the patches are currently minimal for gcc though. Hmm. Perhaps we have HOST_WIDE_INT problems for mingw host here? If cfun->machine->frame.var_size was a long long, and HOST_WIDE_INT_PRINT_DEC for mingw is just "%d" or "%ld" rather than "%lld", that would push an extra NULL word onto the stack that would be taken as the parameter for %s because the "%d" wouldn't be advancing the varargs pointer past the whole of the second format arg... And that's exactly the problem. in /gcc/config/i386/xm-mingw32.h we have /* MSVCRT does not support the "ll" format specifier for printing "long long" values. Instead, we use "I64". */ #define HOST_LONG_LONG_FORMAT "I64" then in gcc/hwint.h we have /* The string that should be inserted into a printf style format to indicate a "long long" operand. */ #ifndef HOST_LONG_LONG_FORMAT #define HOST_LONG_LONG_FORMAT "ll" #endif and later in the same file #if HOST_BITS_PER_WIDE_INT == HOST_BITS_PER_LONG # define HOST_WIDE_INT_PRINT "l" # define HOST_WIDE_INT_PRINT_C "L" /* 'long' might be 32 or 64 bits, and the number of leading zeroes must be tweaked accordingly. */ # if HOST_BITS_PER_WIDE_INT == 64 # define HOST_WIDE_INT_PRINT_DOUBLE_HEX "0x%lx%016lx" # else # define HOST_WIDE_INT_PRINT_DOUBLE_HEX "0x%lx%08lx" # endif #else # define HOST_WIDE_INT_PRINT "ll" # define HOST_WIDE_INT_PRINT_C "LL" /* We can assume that 'long long' is at least 64 bits. */ # define HOST_WIDE_INT_PRINT_DOUBLE_HEX \ "0x%" HOST_LONG_LONG_FORMAT "x%016" HOST_LONG_LONG_FORMAT "x" #endif /* HOST_BITS_PER_WIDE_INT == HOST_BITS_PER_LONG */ so the HOST_WIDE_INT_PRINT ignores the mingw override. I've currently patched as follows diff -Naurb gcc-4.0.1/gcc/hwint.h gcc-4.0.1-new/gcc/hwint.h --- gcc-4.0.1/gcc/hwint.hWed Nov 24 04:31:57 2004 +++ gcc-4.0.1-new/gcc/hwint.hThu Jul 21 14:37:06 2005 @@ -80,7 +80,7 @@ # define HOST_WIDE_INT_PRINT_DOUBLE_HEX "0x%lx%08lx" # endif #else -# define HOST_WIDE_INT_PRINT "ll" +# define HOST_WIDE_INT_PRINT HOST_LONG_LONG_FORMAT # define HOST_WIDE_INT_PRINT_C "LL" /* We can assume that 'long long' is at least 64 bits. */ # define HOST_WIDE_INT_PRINT_DOUBLE_HEX \ This works for me and allows the build to complete. I'm not currently sure if HOST_WIDE_INT_PRINT_C needs similar treatment. I've created PR22594 - http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22594 Many thanks. Dave
successful build of mingw hosted arm-elf GCC 4.1.0 RC1
output of config.guess $ gcc-4.1.0-20060219/config.guess i686-pc-mingw32 $ arm-elf-gcc -v Using built-in specs. Target: arm-elf Configured with: ../../gcc-4.1.0-20060219/configure --enable-languages=c,c++ --with-cpu=arm7tdmi --enable-interwork --enable-multilib --with-gcc --with-gnu-ld --with-gnu-as --with-stabs --disable-shared --disable-threads --disable-win32-registry --disable-nls --disable-debug --disable-libmudflap --disable-libssp --target=arm-elf --with-newlib --prefix=e:/devkitPro/devkitARM -v Thread model: single gcc version 4.1.0 20060219 (prerelease) (devkitARM release 18) built with binutils 2.16.1 and newlib 1.14.0 The resulting toolchain is building working binaries although slightly larger than the previous 2.16.1, 4.0.2, 1.13.0 combination I was using.
Toolchain relocation
Hi, I've been having some odd problems with relocation of 4.x toolchains - i.e. when a toolchain is configured, built and installed with one prefix but later moved to another location. The binaries appear to be checking something in the old location before reading from the new path. The problem is only obvious on windows machines where the configured prefix is a removable medium such as a CD/DVD or memory card drive when the prebuilt toolchain is moved to a different machine. In this case a dialog box pops up asking the user to insert a disk as shown in this screenshot -> http://img159.imageshack.us/img159/9030/devkiterror3zp.jpg . When a disk is inserted everything works as it should. The error does not occur if the drive doesn't exist, is non removable media, or a disk is inserted in the drive. -print-search-dirs output from relocated toolchain, paths have been separated for clarity. It looks like some paths are being relocated but others are not. $ /c/devkitARM/bin/arm-elf-gcc -print-search-dirs install: e:/devkitPro/devkitARM/lib/gcc/arm-elf/4.1.0/ programs: = c:/devkitarm/bin/../libexec/gcc/arm-elf/4.1.0/; c:/devkitarm/bin/../libexec/gcc/; e:/devkitPro/devkitARM/libexec/gcc/arm-elf/4.1.0/; e:/devkitPro/devkitARM/libexec/gcc/arm-elf/4.1.0/; e:/devkitPro/devkitARM/libexec/gcc/arm-elf/; e:/devkitPro/devkitARM/lib/gcc/arm-elf/4.1.0/; e:/devkitPro/devkitARM/lib/gcc/arm-elf/;/usr/libexec/gcc/arm-elf/4.1.0/; /usr/libexec/gcc/arm-elf/; /usr/lib/gcc/arm-elf/4.1.0/;/usr/lib/gcc/arm-elf/; c:/devkitarm/bin/../lib/gcc/arm-elf/4.1.0/../../../../arm-elf/bin/arm-elf/4.1.0/; c:/devkitarm/bin/../lib/gcc/arm-elf/4.1.0/../../../../arm-elf/bin/; e:/devkitPro/devkitARM/arm-elf/bin/arm-elf/4.1.0/; e:/devkitPro/devkitARM/arm-elf/bin/ libraries: = c:/devkitarm/bin/../lib/gcc/arm-elf/4.1.0/; c:/devkitarm/bin/../lib/gcc/; e:/devkitPro/devkitARM/lib/gcc/arm-elf/4.1.0/; /usr/lib/gcc/arm-elf/4.1.0/; c:/devkitarm/bin/../lib/gcc/arm-elf/4.1.0/../../../../arm-elf/lib/arm-elf/4.1.0/; c:/devkitarm/bin/../lib/gcc/arm-elf/4.1.0/../../../../arm-elf/lib/; e:/devkitPro/devkitARM/arm-elf/lib/arm-elf/4.1.0/; e:/devkitPro/devkitARM/arm-elf/lib/ I can work around this for now by configuring with a c:/ prefix but is there a better way? Dave
Re: Toolchain relocation
Daniel Jacobowitz wrote: On Thu, Apr 13, 2006 at 03:49:43PM +0100, Dave Murphy wrote: Hi, I've been having some odd problems with relocation of 4.x toolchains - i.e. when a toolchain is configured, built and installed with one prefix but later moved to another location. The binaries appear to be checking something in the old location before reading from the new path. How did you configure the toolchain? Which was the configured install directory and which was the relocated install directory? Sorry, meant to include this with the mail. $ arm-elf-gcc -v Using built-in specs. Target: arm-elf Configured with: ../../gcc-4.1.0/configure --enable-languages=c,c++ --with-cpu=arm7tdmi --enable-interwork --enable-multilib --with-gcc --with-gnu-ld --with-gnu-as --with-stabs --disable-shared --disable-threads --disable-win32-registry --disable-nls --disable-debug --disable-libmudflap --disable-libssp --target=arm-elf --with-newlib --prefix=e:/devkitPro/devkitARM Thread model: single gcc version 4.1.0 (devkitARM release 18) configured install directory was e:/devkitPro/devkitARM, relocated to c:/devkitARM This was built with mingw ( gcc 3.4.2 ) & minsys. Dave
Re: Toolchain relocation
Ranjit Mathew wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dave Murphy wrote: I've been having some odd problems with relocation of 4.x toolchains - i.e. when a toolchain is configured, built and installed with one prefix but later moved to another location. The binaries appear to be checking something in the old location before reading from the new path. I might be mistaken, but I think this is intentional behaviour. It may well be, it's certainly been introduced in the 4.x series - 3.x.x does not have the issue ( as far back as 3.3.2 anyway) If I relocate the toolchain on Debian I see the same symptoms with the output from -print-search-dirs. I've manually inserted a newline after each path here for clarity. Note that install is reported as the original configured location, the program paths have 2 extra paths and 7 are not relocated. For the library paths, no extra paths are added and 3 are not relocated. I think the issue is only apparent on windows due to the request to insert a disk when the original path is removable media. fairlight:/usr/local/devkitPro# ./devkitARM/bin/arm-elf-gcc -print-search-dirs install: /usr/local/devkitPro/devkitARM/lib/gcc/arm-elf/4.1.0/ programs: = /usr/local/devkitPro/devkitARM/libexec/gcc/arm-elf/4.1.0/: /usr/local/devkitPro/devkitARM/libexec/gcc/arm-elf/4.1.0/: /usr/local/devkitPro/devkitARM/libexec/gcc/arm-elf/: /usr/local/devkitPro/devkitARM/lib/gcc/arm-elf/4.1.0/: /usr/local/devkitPro/devkitARM/lib/gcc/arm-elf/: /usr/libexec/gcc/arm-elf/4.1.0/: /usr/libexec/gcc/arm-elf/: /usr/lib/gcc/arm-elf/4.1.0/: /usr/lib/gcc/arm-elf/: /usr/local/devkitPro/devkitARM/lib/gcc/arm-elf/4.1.0/../../../../arm-elf/bin/arm-elf/4.1.0/: /usr/local/devkitPro/devkitARM/lib/gcc/arm-elf/4.1.0/../../../../arm-elf/bin/ libraries: = /usr/local/devkitPro/devkitARM/lib/gcc/arm-elf/4.1.0/: /usr/lib/gcc/arm-elf/4.1.0/: /usr/local/devkitPro/devkitARM/lib/gcc/arm-elf/4.1.0/../../../../arm-elf/lib/arm-elf/4.1.0/: /usr/local/devkitPro/devkitARM/lib/gcc/arm-elf/4.1.0/../../../../arm-elf/lib/ fairlight:/usr/local/devkitPro# mv devkitARM MOVED fairlight:/usr/local/devkitPro# ./MOVED/bin/arm-elf-gcc -print-search-dirs install: /usr/local/devkitPro/devkitARM/lib/gcc/arm-elf/4.1.0/ programs: = /usr/local/devkitPro/MOVED/bin/../libexec/gcc/arm-elf/4.1.0/: /usr/local/devkitPro/MOVED/bin/../libexec/gcc/: /usr/local/devkitPro/devkitARM/libexec/gcc/arm-elf/4.1.0/: /usr/local/devkitPro/devkitARM/libexec/gcc/arm-elf/4.1.0/: /usr/local/devkitPro/devkitARM/libexec/gcc/arm-elf/: /usr/local/devkitPro/devkitARM/lib/gcc/arm-elf/4.1.0/: /usr/local/devkitPro/devkitARM/lib/gcc/arm-elf/: /usr/libexec/gcc/arm-elf/4.1.0/:/usr/libexec/gcc/arm-elf/:/usr/lib/gcc/arm-elf/4.1.0/: /usr/lib/gcc/arm-elf/: /usr/local/devkitPro/MOVED/bin/../lib/gcc/arm-elf/4.1.0/../../../../arm-elf/bin/arm-elf/4.1.0/: /usr/local/devkitPro/MOVED/bin/../lib/gcc/arm-elf/4.1.0/../../../../arm-elf/bin/: /usr/local/devkitPro/devkitARM/arm-elf/bin/arm-elf/4.1.0/: /usr/local/devkitPro/devkitARM/arm-elf/bin/ libraries: = /usr/local/devkitPro/MOVED/bin/../lib/gcc/arm-elf/4.1.0/: /usr/local/devkitPro/MOVED/bin/../lib/gcc/: /usr/local/devkitPro/devkitARM/lib/gcc/arm-elf/4.1.0/: /usr/lib/gcc/arm-elf/4.1.0/: /usr/local/devkitPro/MOVED/bin/../lib/gcc/arm-elf/4.1.0/../../../../arm-elf/lib/arm-elf/4.1.0/: /usr/local/devkitPro/MOVED/bin/../lib/gcc/arm-elf/4.1.0/../../../../arm-elf/lib/: /usr/local/devkitPro/devkitARM/arm-elf/lib/arm-elf/4.1.0/: /usr/local/devkitPro/devkitARM/arm-elf/lib/ FWIW, I have faced a different toolchain relocation problem in the GCC 4.1.0 release on MinGW. I configured and built GCC using "--prefix=/mingw" on one machine where "/mingw" maps to "D:\MiscAppz\MinGW" (I used MSYS as the build environment). The compiler built, installed and ran fine on this machine. However, when I moved the binaries to another machine where MinGW was installed in "D:\MinGW", the compiler was not able to find the C runtime headers, even though the folder structure was exactly the same. I think this is due to the compiler believing it was originally installed at /mingw when in fact it was really installed at d:\MiscAppz\Mingw so the relocation of the include directory fails because it can't relate the two. I'm still a little confused by this one because it would seem to indicate that the paths to the binaries and libraries are relocated in a different manner to the include directories since the relocated compiler can find as, ld etc with no trouble. I know I experience the same problem if I don't configure with --prefix=:/path/to. If I use mount points or the MSYS style //path/to then the newly built compiler can't find it's include directories. There was another curious problem with this GCC, even on the original machine where it was built: when run from within the MSYS environment, everything was hunky-dory but when run from th
Re: Toolchain relocation
H. J. Lu wrote:
It may be related to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14435
Can you try
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01757.html
Tried that but no difference.
I had a look through gcc.c and noticed that standard_exec_prefix and
standard_libexec_prefix are constants which refer to the configured
install path. gcc_exec_prefix and gcc_libexec_prefix are the equivalent
paths adjusted for the relocated toolchain but the unadjusted variables
are used in several places. The attached patch switches them for the
adjusted variables and is a partial fix for my problem but unfortunately
isn't the whole story. The relocated compiler is still checking for
includes in the configured location but all the directories reported
from -print-search-dirs are now relocated.
Unfortunately I still don't quite understand how the include paths are
determined so I haven't made much progress in tracking the problem
there. Is there any reason why -print-search-dirs doesn't report include
paths as well?
One caveat with this patch is that the make_relative_prefix calls are
commented on VMS so this might utterly break the compiler on that platform.
Could someone check if this is the right approach and possibly point me
in the right direction to adjust the include paths as well?
Dave
--- gcc-4.1.0/gcc/gcc.c Sat Jan 21 18:29:08 2006
+++ gcc-4.1.0-arm/gcc/gcc.c Sat Apr 15 07:11:53 2006
@@ -3278,6 +3278,8 @@
set_std_prefix (gcc_exec_prefix, len);
add_prefix (&exec_prefixes, gcc_libexec_prefix, "GCC",
PREFIX_PRIORITY_LAST, 0, 0);
+ add_prefix (&exec_prefixes, gcc_exec_prefix, "GCC",
+ PREFIX_PRIORITY_LAST, 0, 0);
add_prefix (&startfile_prefixes, gcc_exec_prefix, "GCC",
PREFIX_PRIORITY_LAST, 0, 0);
}
@@ -3812,11 +3814,11 @@
/* Use 2 as fourth arg meaning try just the machine as a suffix,
as well as trying the machine and the version. */
#ifndef OS2
- add_prefix (&exec_prefixes, standard_libexec_prefix, "GCC",
+ add_prefix (&exec_prefixes, gcc_libexec_prefix, "GCC",
PREFIX_PRIORITY_LAST, 1, 0);
- add_prefix (&exec_prefixes, standard_libexec_prefix, "BINUTILS",
+ add_prefix (&exec_prefixes, gcc_libexec_prefix, "BINUTILS",
PREFIX_PRIORITY_LAST, 2, 0);
- add_prefix (&exec_prefixes, standard_exec_prefix, "BINUTILS",
+ add_prefix (&exec_prefixes, gcc_exec_prefix, "BINUTILS",
PREFIX_PRIORITY_LAST, 2, 0);
add_prefix (&exec_prefixes, standard_exec_prefix_1, "BINUTILS",
PREFIX_PRIORITY_LAST, 2, 0);
@@ -3824,7 +3826,7 @@
PREFIX_PRIORITY_LAST, 2, 0);
#endif
- add_prefix (&startfile_prefixes, standard_exec_prefix, "BINUTILS",
+ add_prefix (&startfile_prefixes, gcc_exec_prefix, "BINUTILS",
PREFIX_PRIORITY_LAST, 1, 0);
add_prefix (&startfile_prefixes, standard_exec_prefix_2, "BINUTILS",
PREFIX_PRIORITY_LAST, 1, 0);
@@ -3857,7 +3859,7 @@
NULL, PREFIX_PRIORITY_LAST, 0, 1);
}
- tooldir_prefix = concat (standard_exec_prefix, spec_machine,
+ tooldir_prefix = concat (gcc_exec_prefix, spec_machine,
dir_separator_str, spec_version,
dir_separator_str, tooldir_prefix, NULL);
}
@@ -6148,10 +6150,10 @@
/* We need to check standard_exec_prefix/just_machine_suffix/specs
for any override of as, ld and libraries. */
- specs_file = alloca (strlen (standard_exec_prefix)
+ specs_file = alloca (strlen (gcc_exec_prefix)
+ strlen (just_machine_suffix) + sizeof ("specs"));
- strcpy (specs_file, standard_exec_prefix);
+ strcpy (specs_file, gcc_exec_prefix);
strcat (specs_file, just_machine_suffix);
strcat (specs_file, "specs");
if (access (specs_file, R_OK) == 0)
@@ -6254,7 +6256,7 @@
standard_startfile_prefix, NULL),
NULL, PREFIX_PRIORITY_LAST, 0, 1);
add_prefix (&startfile_prefixes,
- concat (standard_exec_prefix,
+ concat (gcc_exec_prefix,
machine_suffix,
standard_startfile_prefix, NULL),
NULL, PREFIX_PRIORITY_LAST, 0, 1);
@@ -6303,7 +6305,7 @@
if (print_search_dirs)
{
- printf (_("install: %s%s\n"), standard_exec_prefix, machine_suffix);
+ printf (_("install: %s%s\n"), gcc_exec_prefix, machine_suffix);
printf (_("programs: %s\n"), build_search_list (&exec_prefixes, "", 0));
printf (_("libraries: %s\n"), build_search_list (&startfile_prefixes,
"", 0));
return (0);
Re: Toolchain relocation
Ross Ridge wrote: Dave Murphy wrote: install: e:/devkitPro/devkitARM/lib/gcc/arm-elf/4.1.0/ Don't use a --prefix with a drive letter. Just use --prefix=/devkitARM, and then use "make install DESTDIR=e:/devkitPro" to install it where you actually want it. Doesn't help, it's still checking that the old installation paths exist and producing the "insert disk" dialog. Interestingly configuring and installing in this way does appear to correct the output from -print-search-dirs but gcc still looks for a specs file in the old location. The include paths in the old location are still checked when compiling. Dave
Re: Toolchain relocation
Dave Murphy wrote: Ross Ridge wrote: Dave Murphy wrote: install: e:/devkitPro/devkitARM/lib/gcc/arm-elf/4.1.0/ Don't use a --prefix with a drive letter. Just use --prefix=/devkitARM, and then use "make install DESTDIR=e:/devkitPro" to install it where you actually want it. Doesn't help, it's still checking that the old installation paths exist and producing the "insert disk" dialog. Interestingly configuring and installing in this way does appear to correct the output from -print-search-dirs but gcc still looks for a specs file in the old location. The include paths in the old location are still checked when compiling. Dave Actually no it doesn't. I messed up the DESTDIR and was testing with an old build where I had corrected the relocation of the paths for -print-search-dirs. Oops, sorry. Dave
Re: Toolchain relocation
Daniel Jacobowitz wrote:
No, this patch is not correct. Take a wander through set_std_prefix
and the call to update_path in add_prefix.
Expected as much :)
You might want to play around with relocation on a non-MinGW-hosted
system, for comparison. Does that work better? If so, it's likely
something which does not handle drive letters. make_relative_prefix
may need to be taught something about them.
make_relative_prefix seems to handle drive letters fine, I don't believe
that's the problem.
If a *blank* disk is inserted then the compiler behaves properly so the
relocation works. It's not dependent on finding anything in the
configured location.
What's happening here is that the toolchain is still attempting to
access directories in the configured location (even on my debian box)
but you only notice a problem if the configured location happens to be a
removable media device with no media present on windows when you get a
dialog box asking you to insert a disk.
Looking at set_std_prefix and update_path it appears that std_prefix is
set to the relocated install directory quite early on (line 3278 of
gcc.c). update_path only translates the path if it contains std_prefix,
this section of code in prefix.c
const int len = strlen (std_prefix);
if (! strncmp (path, std_prefix, len)
&& (IS_DIR_SEPARATOR(path[len])
|| path[len] == '\0')
&& key != 0)
{
If I change this code so that it checks against the configured install
location instead of the new relocated location then update_path does
indeed translate the paths. It appears to be enough to add
static const char *old_prefix = PREFIX;
and change that section of code to read as follows
const int len = strlen (old_prefix);
if (! strncmp (path, old_prefix, len)
&& (IS_DIR_SEPARATOR(path[len])
|| path[len] == '\0')
&& key != 0)
{
In this case the output from -print-search-dirs is fully translated with
the exception of the install path which is due to always reporting the
configured path in line 6306 of gcc.c
printf (_("install: %s%s\n"), standard_exec_prefix, machine_suffix);
standard_exec_prefix is a constant which refers to the originally
installed folder, changing this to gcc_exec_prefix displays the
relocated install location.
At line 6149 in gcc.c standard_exec_prefix is used to access the specs file
/* We need to check standard_exec_prefix/just_machine_suffix/specs
for any override of as, ld and libraries. */
specs_file = alloca (strlen (standard_exec_prefix)
+ strlen (just_machine_suffix) + sizeof ("specs"));
strcpy (specs_file, standard_exec_prefix);
strcat (specs_file, just_machine_suffix);
strcat (specs_file, "specs");
if ( access (specs_file, R_OK) == 0)
read_specs (specs_file, TRUE);
Changing this to gcc_exec_prefix removes the last of the attempts to
access anything in the old path as far as gcc is concerned. There are
still some attempts to find include files in the configured install
directory which I believe are related to cc1, cc1plus and c-incpath.c
which I'm currently attempting to grok.
Dave
Re: Crossed-Native Builds, Toolchain Relocation and MinGW
Kai Ruottu wrote:
Ranjit Mathew kirjoitti:
If I understand you correctly, you're saying that the
target runtime libraries are already created by the
cross-compiler in Phase 1, so I don't need to rebuild
them again in Phase 2 along with the crossed-native
compiler - I can get by by just building the compiler.
Yes, once being made and being thoroughly tested, any library shouldn't
be rebuilt. Doing that again only means a test for the compiler producing
the library - the result should by all sanity be identical in size and
bytes
with the existing...
Definitely the cross-GCC for the $target on the $build host is the
expected
compiler to produce the target libraries, not the new GCC being built for
the new $host and for the $target. In your case it could be possible
to have
Wine installed and then trying to run the new MinGW-hosted native GCC
on the $build host, but this isn't the assumption, the
$build-X-$target GCC
is the one producing the $target libraries, in your case the
'i686-mingw32-gcc'
(and all the stuff it uses as subprocesses, headers and libraries) or
something.
I don't know much about the internals of GCC, but what
you're saying should be possible though a bit cumbersome.
Building everything in Phase 2 (compiler and libraries)
just gives a nice bundle that I can then redeploy as I
wish (but this is precisely the thing that seems to be
broken, on MinGW at least).
I would go as far as not even producing that special "native GCC", but to
build instead a "MinGW-targeted and MinGW-hosted GCC" ! I have never
understood why the Windoze-host should cause the MinGW-targeted GCC
being in any way different from a Linux-hosted and MinGW-targeted GCC
in its install scheme... The MinGW-targeted GCC on Windoze really
doesn't
need to mimic any proprietary "native 'cc'" which has its headers in
'/usr/include'
and its libraries in '/usr/lib' or something Maybe some Unix
sources could
require the X11 stuff being in its "native" places, but never that the
C headers
and libraries would be in some virtual "native" places
[snip]
All this is very interesting but has strayed quite a bit from the
problem at hand.
Something both Ranjit and I are experiencing is that relocation of a gcc
toolchain in the 4.x.x series is broken. The problem is especially
apparent on a windows host and symptoms vary depending on whether the
toolchain was built in a linux or a windows environment.
When a mingw gcc toolchain is built on a linux host then it cannot find
it's headers or it's associated tools when running from a cmd shell on
the windows host. This can be worked around by using the msys shell to
provide a mount point identical to the configured prefix but isn't ideal.
Any cross gcc built using mingw on a windows machine has problems when
the toolchain is relocated. The resulting toolchain here will always
attempt to access folders in the original configured directory which
results in a dialog asking the user to insert a disk when the original
install location is a removable media drive on the host machine.
Ranjit, the attached patch stops my cross toolchains accessing the
configured location when looking for specs files and tools but does not
yet address the include problem. In theory it should at least get your
linux built toolchains finding their tools when run on a windows host.
The problem with the include paths is that update_path in prefix.c
expects set_std_prefix to have been called with the location of the
relocated toolchain. While gcc does this, neither cc1 nor cc1plus do. I
think toplev.c needs some code to call make_relative_prefix and
set_std_prefix similar to gcc.c.
Dave
--- gcc-4.1.0/gcc/gcc.c Sat Jan 21 18:29:08 2006
+++ gcc-4.1.0-arm/gcc/gcc.c Mon Apr 24 16:05:45 2006
@@ -6148,10 +6148,10 @@
/* We need to check standard_exec_prefix/just_machine_suffix/specs
for any override of as, ld and libraries. */
- specs_file = alloca (strlen (standard_exec_prefix)
+ specs_file = alloca (strlen (gcc_exec_prefix)
+ strlen (just_machine_suffix) + sizeof ("specs"));
- strcpy (specs_file, standard_exec_prefix);
+ strcpy (specs_file, gcc_exec_prefix);
strcat (specs_file, just_machine_suffix);
strcat (specs_file, "specs");
if (access (specs_file, R_OK) == 0)
--- gcc-4.1.0/gcc/prefix.c Sat Jun 25 03:02:01 2005
+++ gcc-4.1.0-arm/gcc/prefix.c Tue Apr 18 05:03:53 2006
@@ -246,13 +246,16 @@
The returned string is always malloc-ed, and the caller is
responsible for freeing it. */
+
+static const char *old_prefix = PREFIX;
+
char *
update_path (const char *path, const char *key)
{
char *result, *p;
- const int len = strlen (std_prefix);
+ const int len = strlen (old_prefix);
- if (! strncmp (path, std_prefix, len)
+ if (! strncmp (path, old_prefix, len)
&& (IS_DIR_SEPARATOR(path[len])
|| path[len] == '\0')
&& key != 0)
Re: Crossed-Native Builds, Toolchain Relocation and MinGW
Ross Ridge wrote: Dave Murphy wrote: When a mingw gcc toolchain is built on a linux host then it cannot find it's headers or it's associated tools when running from a cmd shell on the windows host. This can be worked around by using the msys shell to provide a mount point identical to the configured prefix but isn't ideal. MinGW GCC is a native Win32 application and is unaffected by any mounts you create with MSYS It's affected when you run from the msys bash shell, my apologies for not being clear. Dave
Re: Crossed-Native Builds, Toolchain Relocation and MinGW
Ross Ridge wrote:
Ross Ridge wrote:
MinGW GCC is a native Win32 application and is unaffected by any mounts
you create with MSYS.
Dave Murphy wrote:
It's affected when you run from the msys bash shell, my apologies for
not being clear.
That makes no difference. MinGW GCC is a native Win32 application and
can't see any mounts you create with MSYS.
sorry but you're most definitely wrong about that.
[EMAIL PROTECTED] /e
$ cat /usr/local/test/test.c
#include
int main(int argc, char **argv) {
printf(argv[0]);
return 0;
}
[EMAIL PROTECTED] /e
$ gcc -v
Reading specs from e:/MinGW/bin/../lib/gcc/mingw32/3.4.2/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as
--host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads
--disable-nls --enable-languages=c,c++,f77,ada,objc,java
--disable-win32-registry --disable-shared --enable-sjlj-exceptions
--enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm
--disable-libgcj-debug --enable-interpreter
--enable-hash-synchronization --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.2 (mingw-special)
[EMAIL PROTECTED] /e
$ gcc /usr/local/test/test.c -o /usr/local/test/test.exe
[EMAIL PROTECTED] /e
$ /usr/local/test/test.exe
E:\msys\local\test\test.exe
[EMAIL PROTECTED] /e
$
As you can see the paths are translated by the shell before being passed
to windows executables.
Dave
Re: Crossed-Native Builds, Toolchain Relocation and MinGW
Ross Ridge wrote:
Ross Ridge wrote:
That makes no difference. MinGW GCC is a native Win32 application and
can't see any mounts you create with MSYS.
Dave Murphy wrote:
sorry but you're most definitely wrong about that
No, I'm not. The example you gave shows how MSYS mounts have an effect on
the MSYS shell, which is not a native Win32 application. The "toolchain
relocation" code in MinGW GCC is unaffected by MSYS mounts you might
create, and so providing "a mount point identical to the configured
prefix" won't have any effect.
oops, that'll teach me to think a bit more before posting :)
I'm totally at a loss to explain the problems Ranjit was experiencing in
this mail then.
http://gcc.gnu.org/ml/gcc/2006-04/msg00247.html
the part where he says " when run from within the MSYS environment,
everything was hunky-dory but when run from the Windows command prompt,
it used to give a "_spawnvp: No such file or directory" error when one
tried to compile something."
I can't say I've encountered that one locally but one of my users had
this issue with win98.
Dave
Re: Toolchain relocation
Daniel Jacobowitz wrote:
On Sat, Apr 15, 2006 at 09:46:24AM +0100, Dave Murphy wrote:
No, this patch is not correct. Take a wander through set_std_prefix
and the call to update_path in add_prefix.
Here's another attempt at a patch which fixes the problem for me,
including the translation of the include paths. I'm still not sure this
is correct
set_std_prefix is called quite early on and sets the root of the
installed toolchain. Since update_path checks for a match against
std_prefix before translating the paths translation only happens on
paths that don't actually require it. Checking against the configured
prefix instead fixes this problem for the gcc executable. The check of
standard_exec_prefix/just_machine_suffix/specs uses the hard coded
standard_exec_prefix causes another access to the old location. Using
the translated gcc_exec_prefix fixes this.
cc1 and cc1plus never call set_std_prefix so their calls to update_path
are not aware that the toolchain has been moved. I noticed that gcc sets
GCC_EXEC_PREFIX to a string which it later uses in the call to
set_std_prefix. Moving the putenv from gcc.c to set_std_prefix in
prefix.c and adding a call to set_std_prefix in toplev.c with the string
from GCC_EXEC_PREFIX fixes this.
Updating and using GCC_EXEC_PREFIX like this feels like the wrong thing
to do though. Would it be better to use another name for this purpose,
STD_PREFIX for example?
I've also been looking for a PR in bugzilla but can't seem to find one
for this issue. Could someone point me in the right direction if there
is one?
Dave
diff -Naurb gcc-4.1.0/gcc/gcc.c gcc-4.1.0-arm/gcc/gcc.c
--- gcc-4.1.0/gcc/gcc.c Sat Jan 21 18:29:08 2006
+++ gcc-4.1.0-arm/gcc/gcc.c Fri May 5 10:18:31 2006
@@ -3250,8 +3250,6 @@
gcc_libexec_prefix = make_relative_prefix (argv[0],
standard_bindir_prefix,
standard_libexec_prefix);
- if (gcc_exec_prefix)
- putenv (concat ("GCC_EXEC_PREFIX=", gcc_exec_prefix, NULL));
}
else
gcc_libexec_prefix = make_relative_prefix (gcc_exec_prefix,
@@ -6148,10 +6146,10 @@
/* We need to check standard_exec_prefix/just_machine_suffix/specs
for any override of as, ld and libraries. */
- specs_file = alloca (strlen (standard_exec_prefix)
+ specs_file = alloca (strlen (gcc_exec_prefix)
+ strlen (just_machine_suffix) + sizeof ("specs"));
- strcpy (specs_file, standard_exec_prefix);
+ strcpy (specs_file, gcc_exec_prefix);
strcat (specs_file, just_machine_suffix);
strcat (specs_file, "specs");
if (access (specs_file, R_OK) == 0)
diff -Naurb gcc-4.1.0/gcc/prefix.c gcc-4.1.0-arm/gcc/prefix.c
--- gcc-4.1.0/gcc/prefix.c Sat Jun 25 03:02:01 2005
+++ gcc-4.1.0-arm/gcc/prefix.c Fri May 5 10:18:51 2006
@@ -246,13 +246,16 @@
The returned string is always malloc-ed, and the caller is
responsible for freeing it. */
+
+static const char *old_prefix = PREFIX;
+
char *
update_path (const char *path, const char *key)
{
char *result, *p;
- const int len = strlen (std_prefix);
+ const int len = strlen (old_prefix);
- if (! strncmp (path, std_prefix, len)
+ if (! strncmp (path, old_prefix, len)
&& (IS_DIR_SEPARATOR(path[len])
|| path[len] == '\0')
&& key != 0)
@@ -354,4 +357,6 @@
set_std_prefix (const char *prefix, int len)
{
std_prefix = save_string (prefix, len);
+
+ putenv (concat ("GCC_EXEC_PREFIX=", std_prefix, NULL));
}
diff -Naurb gcc-4.1.0/gcc/toplev.c gcc-4.1.0-arm/gcc/toplev.c
--- gcc-4.1.0/gcc/toplev.c Sat Feb 4 22:13:20 2006
+++ gcc-4.1.0-arm/gcc/toplev.c Wed Apr 26 16:49:36 2006
@@ -82,6 +82,7 @@
#include "value-prof.h"
#include "alloc-pool.h"
#include "tree-mudflap.h"
+#include "prefix.h"
#if defined (DWARF2_UNWIND_INFO) || defined (DWARF2_DEBUGGING_INFO)
#include "dwarf2out.h"
@@ -1434,6 +1435,10 @@
progname = p;
xmalloc_set_program_name (progname);
+
+ p = getenv("GCC_EXEC_PREFIX");
+ set_std_prefix (p, strlen(p));
+
hex_init ();
Re: mingw32 subtle build failure
FX Coudert wrote:
Hi all, hi mingw32 maintainers,
I'm experiencing a strange bug building mainline as a native compiler
on i386-pc-mingw32 (with MSYS). It builds fine with the following
configure line:
../gcc/configure --prefix=/mingw --with-gmp=/home/coudert/local
--disable-nls --with-ld=/mingw/bin/ld --with-as=/mingw/bin/as
--disable-werror --enable-bootstrap --enable-threads
--host=i386-pc-mingw32 --enable-languages=c,fortran
If I add the --enable-libgomp option (I know libgomp is not supposed
to compile, but go on reading) it fails in
configure-stage3-libdecnumber (that is, even *before* doing anything
with libgomp): the error (from config.log) is the following:
configure:1751: error: C compiler cannot create executables
xgcc.exe: CreateProcess: No such file or directory
Now, if I run the same command line that failed during configure,
directly inside a shell, it works nicely. To understand this strange
failure, I changed libiberty/pex-win32.c to print
printf ("CreateProcess (%s, %s, ...)\n", full_executable, cmdline);
just before the CreateProcess call, I get the following output:
xgcc.exe: CreateProcess: No such file or directory^M
This looks to me like a side effect of some file somewhere being
generated with DOS line endings. I had something vaguely similar
building a powerpc cross compiler on mingw/mys, noted in this message
http://sourceforge.net/mailarchive/message.php?msg_id=15373554
Maybe it will give you a clue what to look for, I have no idea otherwise.
Dave
Re: Modifying ARM code generator for elimination of 8bit writes - need help
Rask Ingemann Lambertsen wrote: There are other targets with targets specific options to work around this or that bug, quirk, defect or errata. In this case, why would two options -mno-byte-writes and -mbyte-writes, with the latter being the default, be unlikely to be acceptable? In particular, the MT port has these two options: -mbacc Use byte loads and stores when generating code. -mno-bacc Do not use byte loads and stores when generating code. I was just about to ask about this very thing since I'm quite sure that there would be interest in adding this to devkitARM. How much work would it be to implement these switches? I assume that the toolchain would need multilibs for these options in order to use newlib etc. Dave
