Compiling gcc 4.8.5 - linux

Im trying to compile gcc 4.8.5 under Red Hat 6. This is my procedure:
tar -xvzf archive.tar.gz
cd gcc-4.8.5
./configure --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release \
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object \
--enable-languages=fortran,c --prefix=/opt/gcc4.8.5
make
Then I get the following error:
make all-am
make[4]: Entering directory `/app/gfortran_build/gcc-4.8.5/host-x86_64-unknown-linux-gnu/lto-plugin'
/bin/sh ./libtool --tag=CC --tag=disable-static --mode=link gcc -Wall -g -module -bindir /opt/gcc4.8.5/libexec/gcc/x86_64-unknown-linux-gnu/4.8.5 -o
liblto_plugin.la -rpath /opt/gcc4.8.5/libexec/gcc/x86_64-unknown-linux-gnu/4.8.5 lto-plugin.lo -Wc,../libiberty/pic/libiberty.a
libtool: link: gcc -shared .libs/lto-plugin.o ../libiberty/pic/libiberty.a -Wl,-soname -Wl,liblto_plugin.so.0 -o .libs/liblto_plugin.so.0.0.0
/usr/bin/ld: ../libiberty/pic/libiberty.a(simple-object-coff.o): relocation R_X86_64_PC32 against undefined symbol `simple_object_set_big_16' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
I already read about CFLAGS, but I wont get it to work.
kind regards

GCC is documented to need to be built outside of its source tree; see the configuring chapter of its installation documentation:
First, we highly recommend that GCC be built into a separate directory from the sources which does not reside within the source tree. This is how we generally build GCC; building where srcdir == objdir should still work, but doesn’t get extensive testing; building where objdir is a subdirectory of srcdir is unsupported.
So you need to build it according to that rule. Hence your GCC build:
cd gcc-4.8.5
#wrong code from the original question! Don't use that
./configure --enable-bootstrap --enable-shared \
--enable-threads=posix --enable-checking=release \
--with-system-zlib --enable-__cxa_atexit \
--disable-libunwind-exceptions --enable-gnu-unique-object \
--enable-languages=fortran,c --prefix=/opt/gcc4.8.5
is wrong; I would recommend at least:
cd gcc-4.8.5
mkdir ../_BuildGCC
cd ../_BuildGCC
../gcc-4.8.5/configure --enable-bootstrap --enable-shared \
--enable-threads=posix --enable-checking=release \
--with-system-zlib --enable-__cxa_atexit \
--disable-libunwind-exceptions --enable-gnu-unique-object \
--enable-languages=fortran,c --prefix=/opt/gnu \
--program-suffix=-mine
then, after the entire build, probably with
make -j4
followed by some mkdir /opt/gnu with appropriate user and permission, then (in the same _BuildGCC)
make install DESTDIR=/tmp/gccinst
and finally cp -vr /tmp/gccinst/opt/gnu /opt/gnu to be run appropriately (perhaps as root...., and perhaps cp -va)
Then you would add /opt/gnu/bin/ to your PATH variable, and you would use gcc-mine to compile your code.
BTW, GCC is compatible for C programs since the ABI don't change. And GCC 4.8 is obsolete and unsupported. You'll better compile from source the supported versions (listed on gcc.gnu.org; in January 2018, GCC 7.2 & GCC 6.4)
Perhaps your particular Redhat system requires additional/specific CFLAGS to be appended into your configure command. You could ask your Redhat support, or try to append CFLAGS=-fPIE or CFLAGS=-fPIC at the end of your ../gcc-4.8.5/configure command.
At last, you might perhaps get such help on gcc-help#gcc.gnu.org, but you'll better try with a recent GCC. Few GCC folks remember 4.8 ....
If you really need precisely GCC 4.8 (but I doubt that), you could buy costly support (e.g. from RedHat or AdaCore folks) if needed.
With Google I found Installing gcc 4.8 and Linuxbrew on CentOS 6

it worked with the following:
../gcc-4.8.5/configure CC="/opt/gcc4.5/bin/gcc" --prefix=/opt/gcc4.8.5 --enable-languages=c,c++,fortran --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object
The interesting part is CC=...
The installed gcc-version is 4.4. With this version, the compiling fails.
kind regards

Related

gdb can't cross-compile for arm-linux

The Linux already having both gcc & arm-gcc in the environment path:
[fit#localhost gdb-arm]$ gcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-cpu=generic --build=i386-redhat-linux
Thread model: posix
gcc version 4.3.0 20080428 (Red Hat 4.3.0-8) (GCC)
[fit#localhost gdb-arm]$ arm-none-linux-gnueabi-gcc -v
Using built-in specs.
Target: arm-none-linux-gnueabi
Configured with: /scratch/mitchell/builds/4.3-arm-none-linux-gnueabi-respin/src/gcc-4.3/configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-none-linux-gnueabi --enable-threads --disable-libmudflap --disable-libssp --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --with-specs='%{funwind-tables|fno-unwind-tables|mabi=*|ffreestanding|nostdlib:;:-funwind-tables}' --enable-languages=c,c++ --enable-shared --enable-symvers=gnu --enable-__cxa_atexit --with-pkgversion='Sourcery G++ Lite 2009q1-203' --with-bugurl=https://support.codesourcery.com/GNUToolchain/ --disable-nls --prefix=/opt/codesourcery --with-sysroot=/opt/codesourcery/arm-none-linux-gnueabi/libc --with-build-sysroot=/scratch/mitchell/builds/4.3-arm-none-linux-gnueabi-respin/lite/install/arm-none-linux-gnueabi/libc --with-gmp=/scratch/mitchell/builds/4.3-arm-none-linux-gnueabi-respin/lite/obj/host-libs-2009q1-203-arm-none-linux-gnueabi-i686-pc-linux-gnu/usr --with-mpfr=/scratch/mitchell/builds/4.3-arm-none-linux-gnueabi-respin/lite/obj/host-libs-2009q1-203-arm-none-linux-gnueabi-i686-pc-linux-gnu/usr --disable-libgomp --enable-poison-system-directories --with-build-time-tools=/scratch/mitchell/builds/4.3-arm-none-linux-gnueabi-respin/lite/install/arm-none-linux-gnueabi/bin --with-build-time-tools=/scratch/mitchell/builds/4.3-arm-none-linux-gnueabi-respin/lite/install/arm-none-linux-gnueabi/bin
Thread model: posix
gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203)
So I configure the gdb 6.6:
$ ./configure --target=arm-none-linux-gnueabi --host=i386-redhat-linux -v
compiled without error, but looks like gdb used the wrong compiler.
file ./gdb-build/bin/arm-none-linux-gnueabi-gdb
./gdb-build/bin/arm-none-linux-gnueabi-gdb: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
So How to indicate the correct CC for gdb?
I tried make CC=arm-none-linux-gnueabi-gcc, but will get the error:
arm-none-linux-gnueabi-gcc ../.././sim/arm/../common/gentmap.c -o gentmap -g -O -I. -I../.././sim/arm -I../common -I../.././sim/arm/../common -I../../include -I../.././sim/arm/../../include -I../../bfd -I../.././sim/arm/../../bfd -I../../opcodes -I../.././sim/arm/../../opcodes
rm -f tmp-tvals.h tmp-tmap.c
./gentmap -h >tmp-tvals.h
/bin/sh: ./gentmap: cannot execute binary file
./configure --target=arm-none-linux-gnueabi --host=i386-redhat-linux -v
Don't use --target. It means something else to Autotools.
Use --build and --host. Something like:
./configure --build=$(config.guess) --host=arm-none-linux-gnueabi
--build should specify the machine you are running Autotools on, and --host should specify the machine the package will run on.
Note there is some Autootols bug that requires you to specify both --build and --host. It is yet another Autotools problem that has never been fixed.
Also see 2.2.8, Cross-Compilation in the Autools manual.
You will still need to get the paths and sysroot right, but this should provide the proper configure command so things begin to fail as expected.
config.guess will return a triplet for the machine you are running Autotools on:
$ find /usr/share/ -name config.guess
/usr/share/libtool/build-aux/config.guess
...
$ /usr/share/libtool/build-aux/config.guess
x86_64-pc-linux-gnu
If you find the package has one but it is out of date you can update it with the following command. You usually need to do this for AIX and Solaris machines.
wget 'https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess' -O config.guess
And you can update config.sub the same way:
wget 'https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub' -O config.sub

Why do I need to explicitly link pthread and rt with new gcc and binutils?

Situation
I have a large multi-library c++ project that has been compiled on Debian Squeeze with its native gcc 4.4 compiler so far.
Now I wanted to benefit from a newer gcc version and its optimizations for a specific architecture, thus being able to use FMA and AVX instructions on my target platform. I have compiled gcc 4.9.1 from source and had to also compile new binutils because the linker did not support the instruction set I guess.
Problem
With the new gcc and ld I now had to modify by cmake based build system to also link libraries like pthread, rt or crypto which I did not have to specify explicitly before. How is that? Did something change in the last versions of gcc or the linker that I should be aware of? Is there a way to get back the "old" behavior of not having to be that specific? Having to specify those linking dependencies makes my CMakeLists.txt less readable by cluttering it with platform specific if-clauses.
Versions
System gcc and ld:
$ /usr/bin/g++ -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-8' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-targets=all --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.4.5 (Debian 4.4.5-8)
$ /usr/bin/ld -v
GNU ld (GNU Binutils for Debian)
2.20.1-system.20100303
Custom gcc and ld:
$ /usr/local/bin/g++-4.9 -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/g++-4.9
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i686-pc-linux-gnu/4.9.1/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages=c++ --enable-threads --enable-threads=posix --enable-shared --with-system-zlib --without-included-gettext --enable-clocale=gnu --enable-checking=release --program-suffix=-4.9 --enable-bootstrap
Thread model: posix
gcc version 4.9.1 (GCC)
$ /usr/local/bin/ld -v
GNU ld (GNU Binutils) 2.24.51.20140916
Actually, the proper CMake build of a thread-enable application should include detection of Threads library which indeed performs platform-dependent tests and then fills appropriate variables. See this for more info.
Regarding the other libs in the question, I think that these libraries are platform specific, so you have to add them only on a particular platform. And indeed they are required on those platforms. Why with your previous compiler the program doesn't need these libraries, at least explicitly specified? Maybe because they are implicitly linked in. Try to gcc -dumpspecs for both compiler versions and compare the output.

'/usr/bin/ld: cannot find -lecore_input' but libecore_input.so exists when compiling Terminology

I am trying to compile the Terminology terminal emulator (btw this does some very cool things and is work checking out). However the build fails giving me the following error:
/usr/bin/ld: cannot find -lecore_input
After some messing around with using make -n to print the commands being (or would would be) run, I find that the following line is the one that fails:
gcc -g -O2 -o terminology terminology-about.o terminology-col.o terminology-config.o terminology-controls.o terminology-ipc.o terminology-keyin.o terminology-main.o terminology-media.o terminology-options.o terminology-options_font.o terminology-options_theme.o terminology-options_themepv.o terminology-options_wallpaper.o terminology-options_colors.o terminology-options_behavior.o terminology-options_keys.o terminology-options_helpers.o terminology-options_video.o terminology-sel.o terminology-termio.o terminology-termcmd.o terminology-termiolink.o terminology-termpty.o terminology-termptydbl.o terminology-termptyesc.o terminology-termptyops.o terminology-termptygfx.o terminology-termptyext.o terminology-termptysave.o lz4/terminology-lz4.o terminology-utf8.o terminology-win.o terminology-utils.o terminology-dbus.o terminology-extns.o terminology-app_server.o terminology-app_server_eet.o -lelementary -lm -lefreet_mime -lefreet_trash -ledbus -ldbus-1 -lecore_con -leina -lpthread -leet -levas -lecore -lecore_evas -lecore_file -ledje -lemotion -lecore_input -lecore_imf -lecore_imf_evas -lecore_ipc -lefreet -lethumb_client -leldbus
Running this command on its own from the correct directory and adding the -v option, I get the following output:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.8.2-16' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.2 (Debian 4.8.2-16)
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-g' '-O2' '-o' 'terminology' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/4.8/collect2 --sysroot=/ --build-id --eh-frame-hdr -m elf_x86_64 --hash-style=gnu -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o terminology /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crt1.o /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.8/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/4.8 -L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../.. terminology-about.o terminology-col.o terminology-config.o terminology-controls.o terminology-ipc.o terminology-keyin.o terminology-main.o terminology-media.o terminology-options.o terminology-options_font.o terminology-options_theme.o terminology-options_themepv.o terminology-options_wallpaper.o terminology-options_colors.o terminology-options_behavior.o terminology-options_keys.o terminology-options_helpers.o terminology-options_video.o terminology-sel.o terminology-termio.o terminology-termcmd.o terminology-termiolink.o terminology-termpty.o terminology-termptydbl.o terminology-termptyesc.o terminology-termptyops.o terminology-termptygfx.o terminology-termptyext.o terminology-termptysave.o lz4/terminology-lz4.o terminology-utf8.o terminology-win.o terminology-utils.o terminology-dbus.o terminology-extns.o terminology-app_server.o terminology-app_server_eet.o -lelementary -lm -lefreet_mime -lefreet_trash -ledbus -ldbus-1 -lecore_con -leina -lpthread -leet -levas -lecore -lecore_evas -lecore_file -ledje -lemotion -lecore_input -lecore_imf -lecore_imf_evas -lecore_ipc -lefreet -lethumb_client -leldbus -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-linux-gnu/4.8/crtend.o /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crtn.o
/usr/bin/ld: cannot find -lecore_input
collect2: error: ld returned 1 exit status
Of course libecore_input is installed:
$ sudo updatedb
$ locate ecore_input.so
/usr/lib/x86_64-linux-gnu/libecore_input.so
/usr/lib/x86_64-linux-gnu/libecore_input.so.1
/usr/lib/x86_64-linux-gnu/libecore_input.so.1.7.7
And /usr/lib/x86_64-linux-gnu/ is in both the LIBRARY_PATH in the gcc output and appear as a -L option on the collect2 command.
I also get the same error when I try with gcc-4.7. What has went wrong here? How can I get the program to build?
Update
Since the cause of this was actually a packaging issue, I should have added that I am using Debian Jessie with mixed testing/unstable repositories.
This was caused by /usr/lib/x86_64-linux-gnu/libecore_input.so being a dead link as the result of a Debian packaging issue and the use of mixed testing/unstable repositories.
The /usr/lib/x86_64-linux-gnu/libecore_input.so link was part of the libecore-dev package while the library itself was part of libecore-input1. The installed version of libecore-dev was 1.8.6-1 while libecore-input1 was version 1.7.7. As such the target of the libecore_input.so link was libecore_input.so.1.8.6 which didn't exist. While libecore-dev had versioned dependencies for other libraries, libecore-input1 was an indirect dependency and not properly versioned. This probably a a bug since if a package includes links to a shared library, then its dependencies should make sure that the correct version of the library is installed.
The solution was simply to upgrade the libecore-input package.
Actually I have the impression that the containing folder /usr/lib/x86_64-linux-gnu/ is not contained in the "collect2 command" as you claim when closing your question. Take a close look: it is indeed mentioned in the LD_LIBRARY_PATH (which is not of interest when linking), but it is not mentioned as -L flag in the COLLECT_GCC_OPTIONS output. There is only a folder /usr/lib/gcc/x86_64-linux-gnu/4.8/collect2 in there.
I suggest you change that and retry the linking.

gfortran: debian 6.0.8 - compilation fails

I am trying to use several programs for watershed generation, genericaly called TOPAZ, from
ftp://solar1.msa-oxford.ars.usda.gov/pub/outgoing/TOPAZ/TOPAZ312/Ascii/
the source code is available, so everybody can try
The code is not mine, and i thank publicly here to the authors for their work.
Machine for development is debian 6.0.8, kernel 2.6.32-5-amd64
The source code of all programs conforms strictly to FORTRAN 90 standards, acording to the documentation.
installed gfortran, and when compiling i get
root#geo:/usr/src/topaz.src/tmp# gfortran -v DEDNM.F90
Driving: gfortran -v DEDNM.F90 -lgfortranbegin -lgfortran -lm -shared-libgcc
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-8' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.5 (Debian 4.4.5-8)
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic'
/usr/lib/gcc/x86_64-linux-gnu/4.4.5/f951 DEDNM.F90 -cpp /tmp/ccLDYiVO.f90 -quiet -v DEDNM.F90 -quiet -dumpbase DEDNM.F90 -mtune=generic -auxbase DEDNM -version -fintrinsic-modules-path /usr/lib/gcc/x86_64-linux-gnu/4.4.5/finclude -o /tmp/ccy4DOzn.s
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../x86_64-linux-gnu/include"
ignoring nonexistent directory "/usr/include/x86_64-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-linux-gnu/4.4.5/finclude
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/4.4.5/include
/usr/lib/gcc/x86_64-linux-gnu/4.4.5/include-fixed
/usr/include
End of search list.
GNU Fortran (Debian 4.4.5-8) version 4.4.5 (x86_64-linux-gnu)
compiled by GNU C version 4.4.5, GMP version 4.3.2, MPFR version 3.0.0-p3.
GGC heuristics: --param ggc-min-expand=55 --param ggc-min-heapsize=47475
DEDNM.F90:12415.1:
\x1A
1
Error: Invalid character in name at (1)
i get a similar error on compiling the other programs,
the source is ANSI Standard Fortran90, acording to documentation
i don't know much of fortran, but i would like to use a linux machine rather than going back to windows, and so need to compile the programs instead of using precompliled ones for win95
many thanks
André

compiling native GCC for arm using cross-compiler

I am looking to create a native build of GCC for an ARM system and I am running into some trouble. The build machine is i686-linux. Every tutorial I see tells me how to set up the actual cross compiling suite (which I have already done using crosstools-ng). However, I don't see anything related to compiling native ARM GCC. The configure string I used is below, I have set up the sysroot only with headers. I have also cross-compiled and installed GMP and MPFR.
../../gcc-4.3.5/configure \
--host=arm-unknown-linux-gnueabi \
--build=i686-build_pc-linux-gnu \
--target=arm-unknown-linux-gnueabi \
--prefix=/home/vm/gcc-native/sysroot \
--with-sysroot=/home/vm/gcc-native/sysroot \
--enable-shared --enable-threads --disable-libmudflap --disable-libssp \
--disable-libgomp --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld \
--enable-languages=c,c++ --enable-symvers=gnu --enable-__cxa_atexit \
--disable-nls --disable-multilib \
--with-gmp=/home/vm/gcc-native/sysroot/ \
--with-mpfr=/home/vm/gcc-native/sysroot/
GCC will build for a while but then dies with this:
checking for suffix of object files... configure: error: cannot compute suffix of object files: cannot compile.
I am not sure how this would even run on my system as I am building on i686-linux and the target/host are both arm-linux. My thought right now is to find a ltib distro and looking at a spec file for GCC and trying to follow all of the steps. The GCC that ltib shipped with for my board fails to compile on my system due to conflicts with the std namespace.
Any info/links would be appreciated!
Look in the config.log file (maybe not the top-level one) and see what it was trying to do when the test failed. Just grep for the cannot compute suffix message and you should find the right bit (it won't be at the end of the file).
Note that you'll need a working arm-unknown-linux-gnueabi-gcc on your path somewhere if you want to build a cross-native toolchain. I.e. you need a cross compiler to build cross-native compiler.

Resources