When invoking gcc from where it was installed by 'make install' (C:\MinGW\bin) everything works as expected. But as soon as I move the C:\MinGW directory into some other location standard header files are not looked up at the default locations any more. For example if MinGW directory is moved to C:\DevTools and gcc is invoked from C:\DevTools\MinGW\bin, standard headers are not looked up in the C:\DevTools\MinGW\include directory. Additionally, localization stops working after the relocation. To illustrate the problem: C:\>set PATH=C:\MinGW\bin;%PATH% C:\>echo "" | cpp -v Используются внутренние спецификации. COLLECT_GCC=cpp COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.5.0/lto-wrapper.exe Целевая архитектура: mingw32 Параметры конфигурации: ../gcc_trunk/configure --enable-languages=c,c++ --disable-sjlj-exceptions --enable-shared --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --prefix=/mingw --build=mingw32 Модель многопоточности: win32 gcc версия 4.5.0 20100122 (experimental) [trunk revision 150484] (GCC) COLLECT_GCC_OPTIONS='-E' '-v' '-mtune=i386' c:/mingw/bin/../libexec/gcc/mingw32/4.5.0/cc1.exe -E -quiet -v -iprefix c:\mingw\bin\../lib/gcc/mingw32/4.5.0/ - -mtune=i386 повторное задание каталога "/mingw/include" проигнорировано повторное задание каталога "c:/mingw/lib/gcc/../../lib/gcc/mingw32/4.5.0/include" проигнорировано повторное задание каталога "c:/mingw/lib/gcc/../../lib/gcc/mingw32/4.5.0/include-fixed" проигнорировано повторное задание каталога "/mingw/include" проигнорировано порядок поиска для #include "...": порядок поиска для #include <...>: c:\mingw\bin\../lib/gcc/mingw32/4.5.0/include c:\mingw\bin\../lib/gcc/mingw32/4.5.0/include-fixed c:/MinGW/include c:/mingw/lib/gcc/../../mingw32/include конец списка поиска # 1 "<stdin>" # 1 "<built-in>" # 1 "<command-line>" # 1 "<stdin>" COMPILER_PATH=c:/mingw/bin/../libexec/gcc/mingw32/4.5.0/;c:/mingw/bin/../libexec/gcc/;c:/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/bin/ LIBRARY_PATH=c:/mingw/bin/../lib/gcc/mingw32/4.5.0/;c:/mingw/bin/../lib/gcc/;c:/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/lib/;c:/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../;/mingw/lib/ COLLECT_GCC_OPTIONS='-E' '-v' '-mtune=i386' C:\>move MinGW C:\DevTools\ C:\>set PATH=C:\DevTools\MinGW\bin;%PATH% C:\>echo "" | cpp -v Using built-in specs. COLLECT_GCC=cpp COLLECT_LTO_WRAPPER=c:/devtools/mingw/bin/../libexec/gcc/mingw32/4.5.0/lto-wrapper.exe Target: mingw32 Configured with: ../gcc_trunk/configure --enable-languages=c,c++ --disable-sjlj-exceptions --enable-shared --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --prefix=/mingw --build=mingw32 Thread model: win32 gcc version 4.5.0 20100122 (experimental) [trunk revision 150484] (GCC) COLLECT_GCC_OPTIONS='-E' '-v' '-mtune=i386' c:/devtools/mingw/bin/../libexec/gcc/mingw32/4.5.0/cc1.exe -E -quiet -v -iprefix c:\devtools\mingw\bin\../lib/gcc/mingw32/4.5.0/ - -mtune=i386 ignoring nonexistent directory "c:/MinGW/include" ignoring nonexistent directory "/mingw/include" ignoring duplicate directory "c:/devtools/mingw/lib/gcc/../../lib/gcc/mingw32/4.5.0/include" ignoring duplicate directory "c:/devtools/mingw/lib/gcc/../../lib/gcc/mingw32/4.5.0/include-fixed" ignoring nonexistent directory "/mingw/include" #include "..." search starts here: #include <...> search starts here: c:\devtools\mingw\bin\../lib/gcc/mingw32/4.5.0/include c:\devtools\mingw\bin\../lib/gcc/mingw32/4.5.0/include-fixed c:/devtools/mingw/lib/gcc/../../mingw32/include End of search list. # 1 "<stdin>" # 1 "<built-in>" # 1 "<command-line>" # 1 "<stdin>" COMPILER_PATH=c:/devtools/mingw/bin/../libexec/gcc/mingw32/4.5.0/;c:/devtools/mingw/bin/../libexec/gcc/;c:/devtools/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/bin/ LIBRARY_PATH=c:/devtools/mingw/bin/../lib/gcc/mingw32/4.5.0/;c:/devtools/mingw/bin/../lib/gcc/;c:/devtools/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/lib/;c:/devtools/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../ COLLECT_GCC_OPTIONS='-E' '-v' '-mtune=i386'
This is probably due to the way you built GCC. To have a completely relocatable toolchain, you need to use the --with-sysroot option to configure, and you need to set it equal to prefix or below prefix in the directory structure. I don't think this is a bug with GCC.
Waiting for OP to try suggestion of comment #1.
(In reply to comment #1) > This is probably due to the way you built GCC. To have a completely > relocatable toolchain, you need to use the --with-sysroot option to configure, I've just checked out the latest sources from trunk, as well as consulted the previously fetched sources. There are no such option to configure as --with-sysroot. Did you mean --with-build-sysroot?
(In reply to comment #3) > (In reply to comment #1) > > This is probably due to the way you built GCC. To have a completely > > relocatable toolchain, you need to use the --with-sysroot option to configure, > I've just checked out the latest sources from trunk, as well as consulted the > previously fetched sources. There are no such option to configure as > --with-sysroot. Did you mean --with-build-sysroot? > No, --with-build-sysroot is used to specify the location of the sysroot during the build. --with-sysroot does so for during+after. So for instance, let's say that I wanted to build a toolchain that would run on a system where the sysroot was located at /opt/sys, but while building it, on my build machine, it's located at /build/sys. Therefore, I would do --with-build-sysroot=/build/sys --with-sysroot=/opt/sys. It's explained and documented on this page: http://gcc.gnu.org/install/configure.html Scroll down to "--with-sysroot" and you'll see it. Pay attention to this sentence in the description: "If the specified directory is a subdirectory of ${exec_prefix}, then it will be found relative to the GCC binaries if the installation tree is moved." I believe that's what you want. Note also that you can see the options used to build gcc in your "gcc -v" line in your first post. In there, it's clear that the toolchain you are using is not relocatable.
My GCC (4.4 and 4.5) were configured with the following options: `--build=mingw32 --enable-languages=c,c++ --enable-version-specific-runtime-libs --disable-win32-registry --disable-nls --disable-shared'. I move the GCC directories to, for example, `C:\gcc\', the headers to `C:\gcc\mingw32\include\', the libraries to `C:\gcc\mingw32\lib\'. I don't know how the localization, but everything else seem to work well.
In my recent build I configured the binutils as: ../src/configure --target=x86_64-w64-mingw32 --enable-targets=x86_64-w64-mingw32,i686-w64-mingw32 --disable-shared --enable-static --disable-nls --with-mpc=/local --with-gmp=/local --with-mpfr=/local --with-ppl=/local --with-cloog=/local --prefix=/mingw64 --with-sysroot=/mingw64 CFLAGS="-O3 -fomit-frame-pointer -pipe -march=k8 -mfpmath=sse -mmmx -m3dnow -m64 -Wa,-march=k8" LDFLAGS="-s -Wl,--as-needed" and the gcc as: ../src/configure --target=x86_64-w64-mingw32 --enable-targets=all --enable-multilib --enable-64bit --prefix=/mingw64 --with-sysroot=/mingw64 --disable-shared --enable-static --disable-nls --enable-version-specific-runtime-libs --with-dwarf --with-mpc=/local --with-mpfr=/local --with-gmp=/local --with-ppl=/local --with-cloog=/local --enable-fully-dynamic-string --enable-languages=c,c++,fortran,java --disable-libgomp --enable-libjava-multilib --with-host-libstdcxx='-lstdc++ -lsupc++' --with-pkgversion='LunarShaddow - for my Helen' CFLAGS='-O3 -fomit-frame-pointer -pipe -march=k8 -mfpmath=sse -mmmx -m3dnow -Wa,-march=k8' LDFLAGS='-s -Wl,--as-needed' Just omit the optimization options and you'll find the use of prefix and sysroot. ensure that you use the same sysroot while building binutils.
Back to P3 due to waiting state.
I'd recommend closing this as invalid. We build 12 relocatable toolchains for windows daily for http://mingw-w64.sf.net/ I'm pretty sure it works :)
(In reply to comment #8) > I'd recommend closing this as invalid. We build 12 relocatable toolchains for > windows daily for http://mingw-w64.sf.net/ > > I'm pretty sure it works :) > Agree. I've made a bootstrap a week before and copied and merged it with the dev-cpp. Before i did this version i've moved a cross-compiled version from /msys/1.0/mingw64 to /msys/1.0/mingw for pretty look :)
night-strike can i ask a question that had x86_64-w64-mingw32 supported libgcj yet? I failed even explictly --enable-libgcj... and a so-called wiki of mingw-w64 (http://www.cadforte.com/wiki/index.php/Java) said "Java is, unfortunately, not supported in 64-bit by gcc at this time.", i don't know if it's true...
Invalid then.
(In reply to comment #10) > night-strike can i ask a question that had x86_64-w64-mingw32 supported libgcj > yet? I failed even explictly --enable-libgcj... and a so-called wiki of > mingw-w64 (http://www.cadforte.com/wiki/index.php/Java) said "Java is, > unfortunately, not supported in 64-bit by gcc at this time.", i don't know if > it's true... > This is kind of off topic for this bug, and I invite you to use our resources at mingw-w64.sf.net (mailing list, forum, irc). As for java, libffi works, and boehm-gc works. Those are dependencies for java. I don't know if the in-tree boehm-gc was ever updated from upstream, so you might have to do that manually (the in-tree version was very out of date when we were porting it). As for libgcj itself.... I never tried to build it. I can try, and we can work on it if you like. Please take replies to one of the aforementioned places. Thanks!