Hi, I compild and installed binutils as descriped in the ARM-GCC forum without problems. But building gcc-4.1.0 breaks with the following error: /root/buildgcc/./gcc/xgcc -B/root/buildgcc/./gcc/ -B//bin/ -B//lib/ -isystem //include -isystem //sys-include -c -DHAVE_CONFIG_H -O2 -g -O2 -I. -I../../../gcc-4.1.0/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../../gcc-4.1.0/libiberty/strsignal.c -o strsignal.o ../../../gcc-4.1.0/libiberty/strsignal.c:553: error: conflicting types for 'psignal' /usr/include/signal.h:141: error: previous declaration of 'psignal' was here ../../../gcc-4.1.0/libiberty/strsignal.c: In function 'psignal': ../../../gcc-4.1.0/libiberty/strsignal.c:558: warning: comparison between signed and unsigned make[2]: *** [strsignal.o] Error 1 make[2]: Leaving directory `/root/buildgcc/i686-pc-linux-gnu/libiberty' make[1]: *** [all-target-libiberty] Error 2 make[1]: Leaving directory `/root/buildgcc' make: *** [all] Error 2 This was the command: beta:~/buildgcc# ../gcc-4.1.0/configure --prefix=$PREFIX --target=$TARGET --enable-interwork --enable-multilib --enable-languages=c --without-headers --with-newlib Thanks in advance! Best regards, Christoph
Christoph Bayer wrote: > I compild and installed binutils as descriped in the ARM-GCC forum > without problems. But building gcc-4.1.0 breaks with the following > error: What Debian release are you using? I didn't have any problems building 4.1.0 on Sarge.
This might be a problem with the binutils and the configuration of the binutils. IRC there is some documented problem with the libiberty and the parameters of strsignal on other platforms and a patch for this i.e. in crosstool. So far I have not seen this issue when building the WinARM components with MinGW/minsys (up to 4.0.2). This might not help in the first place but you may check the binutils Version and configuration-options again. It there a special reason for "--without-headers"? Martin Thomas
I have checked again and realized that in this run I have forgotten to set the prefix and target variables... Shame on me! I tried again with the correct target but it breaks again (only c now): Configuring in arm-elf/libssp configure: creating cache ./config.cache checking build system type... i686-pc-linux-gnu checking host system type... arm-unknown-elf checking target system type... arm-unknown-elf checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for arm-elf-strip... arm-elf-strip checking for --enable-version-specific-runtime-libs... no checking whether to enable maintainer-specific portions of Makefiles... no checking for arm-elf-gcc... /root/gcc-arm/./gcc/xgcc -B/root/gcc-arm/./gcc/ -B/usr/local/arm/arm-elf/bin/ -B/usr/local/arm/arm-elf/lib/ -isystem /usr/local/arm/arm-elf/include -isystem /usr/local/arm/arm-elf/sys-include checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. make[1]: *** [configure-target-libssp] Error 1 make[1]: Leaving directory `/root/gcc-arm' make: *** [all] Error 2 I had no problems building binutils and gcc for target=host, I used this new compiler in the last try building the arm stuff, but makes no change compared to the 4.0.2 version of the compiler... > What Debian release are you using? I didn't have any problems building > 4.1.0 on Sarge. I am using sid with gcc version 4.0.2.
mthomas wrote:
> It there a special reason for "--without-headers"?
Not really, I googled a little bit and found this options set in some
examples for building a cross compiler, as far as I remember it shoud be
a workaround for a bug in gcc-3.4.3... I just gave it a try ;-)
Christoph Bayer wrote:
> See `config.log' for more details.
^^^^^^^^^^
Good idee :-) >> See `config.log' for more details. > ^^^^^^^^^^ This is the reason: configure:2310: /root/gcc-arm/./gcc/xgcc -B/root/gcc-arm/./gcc/ -B/usr/local/arm/arm-elf/bin/ -B/usr/local/arm/arm-elf/lib/ -isystem /usr/local/arm/arm-elf/include -isystem /usr/local/arm/arm-elf/sys-include -O2 -g -O2 conftest.c >&5 /usr/local/arm/bin/arm-elf-ld: crt0.o: No such file: No such file or directory collect2: ld returned 1 exit status Looks like gcc needs the newlib lib, which needs gcc to be build :-) Any other idee than using a prebuild gcc to first build newlib and than build the new gcc?
I am now able to successfully build gcc for plain C by adding "--disable-libssp" to the configuration line. But I am still unable to compile the C++ compiler. It seems like the build process tries to build the libssp (for C if no --disable-libssp is given) and libstdc++ (for C++ which I can not stop...). What is interesting, at some point the build process tells me that libstdcc++ is not supported for that platform (what a surprise...). Does anyboday have an idee whats going wrong here?
Watch this topic
Disable multi-page viewPlease log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
Log in with Google account
No account? Register here.