Hello, all!
I'm trying to build cross-compiler to build the programs for PowerPC processor. Host is Fedora Core 3, i686, kernel of 2.6.10 version. GPC is of 20050217 version, is being built together with GCC 3.3.3.
I've configured it with
../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --with-newlib --enable-languages=c,pascal --disable-libgcj --target=ppc-linux.
Compiler itself (xgpc) has been built successfully but it doesn't want to build rts and tells me that c compiler cannot create executables. In the <build>/gcc/p/rts there is the only one file, config.log (attached) where cc1 (of just built xgcc) tells that arch=i686 is an invalid option for him (sounds reasonable since it's the compiler for ppc platform). So, could you please make some clarifications for me: 1. why GPC didn't see that it's being built as a cross compiler (there is nothing about it in config.log, it even doesn't try to determine it). 2. what should be done to avoid passing of the CFLAGS of the native host compiler to cross compiler xgcc which has been just built. 3. as I can see from configure script from rts directory of 20050217 version, it's used another way to determine if it's being built the cross-compiler (there was used other method to determine it in 20030830 version). It's written "FIXME: to remove some days" in current "rts/configure" script near this lines. Is it really wrong and needs to be fixed? Current method uses the value of host_alias variable. As I can see from the config.log file, host_alias variable of "rts/configure" script is empty - how should it get its value? In the same script we try to assign it the value using the options entered by user but "rts/configure"script is called automatically during p/rts/Makefile target building and there is no --host parameter. How should it get its value?
It will be really nice if somebody can give me any hint or point to any source to read about. Regards, Igor Marnat marny@rambler.ru
Igor Marnat wrote:
Hello, all!
I'm trying to build cross-compiler to build the programs for PowerPC processor. Host is Fedora Core 3, i686, kernel of 2.6.10 version. GPC is of 20050217 version, is being built together with GCC 3.3.3.
I've configured it with
../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --with-newlib --enable-languages=c,pascal --disable-libgcj --target=ppc-linux.
Compiler itself (xgpc) has been built successfully but it doesn't want to build rts and tells me that c compiler cannot create executables. In the <build>/gcc/p/rts there is the only one file, config.log (attached) where cc1 (of just built xgcc) tells that arch=i686 is an invalid option for him (sounds reasonable since it's the compiler for ppc platform). So, could you please make some clarifications for me:
- why GPC didn't see that it's being built as a cross compiler (there is
nothing about it in config.log, it even doesn't try to determine it). 2. what should be done to avoid passing of the CFLAGS of the native host compiler to cross compiler xgcc which has been just built.
IIRC CFLAGS contains general flags, for _all_ stages of compilation. Gcc makefiles contain a lot of variables like HOST_LIB_PATH and TARGET_LIB_PATH or FLAGS_FOR_TARGET. If you want to pass flags just to native compiler you need to find correct variable (sorry ATM I do not know which one).
FYI I have built to Mac-OSX cross compiler based on 3.4.3. The runtime build failed since I have no OSX libc headers (and no OSX binutils...). But it got past configure stage and attempted to compile files.
I have also build cross mingw-32 compiler based on 3.2.3. This time the runtime built OK, however I had to manually change configure script for the runtime (configure found out that compiled executables can not run, but still did not belive that I am cross-compiling).
On 11 March 2005 16:45, Waldek Hebisch wrote:
I have also build cross mingw-32 compiler based on 3.2.3. This time the runtime built OK, however I had to manually change configure script for the runtime (configure found out that compiled executables can not run, but still did not belive that I am cross-compiling).
Great! It seems to me that this is exactly what I see. Could you please give it (changed script, or diff, or any hints how to fix it) to me as an example? Unfortunately, I'm not quite familiar with configure-autoconf scripts. Thanks, regards, Igor Marnat marny@rambler.ru
FYI I have built to Mac-OSX cross compiler based on 3.4.3. The runtime build failed since I have no OSX libc headers (and no OSX binutils...). But it got past configure stage and attempted to compile files.
Waldek, thank you very much for your answer, it directed me to the right way. I've managed to build cross compiler for ppc from GPC 20050217 version. Just for the information: in <gpc_source_dir>/p/rts/configure I've added string host_alias=i686-pc-linux-gnu
just before strings
build=$build_alias host=$host_alias target=$target_alias
and things went better, gpc understood that it's being built as a cross-compiler. I didn't make the patch because it is not a real one but perhaps it will be useful information for someone. Regards, Igor Marnat marny@rambler.ru
Igor Marnat wrote:
FYI I have built to Mac-OSX cross compiler based on 3.4.3. The runtime build failed since I have no OSX libc headers (and no OSX binutils...). But it got past configure stage and attempted to compile files.
Waldek, thank you very much for your answer, it directed me to the right way. I've managed to build cross compiler for ppc from GPC 20050217 version. Just for the information: in <gpc_source_dir>/p/rts/configure I've added string host_alias=i686-pc-linux-gnu
just before strings
build=$build_alias host=$host_alias target=$target_alias
and things went better, gpc understood that it's being built as a cross-compiler. I didn't make the patch because it is not a real one but perhaps it will be useful information for someone.
Also configure is a generated file (by autoconf) so we couldn't apply such a patch anyway. I currently don't have the time to investigate the issue further, but probably in the end we either need to change the autoconf input (this would be a patch for us to apply), or fix something in autoconf itself (which would be a thing for the autoconf maintainers) -- or use another autoconf versions (I know they differ quite a bit, and I currently don't really follow them) ...
Frank
-
Frank Heckenbach -
Igor Marnat -
Waldek Hebisch