16.3.2011 21:49, Kai Ruottu kirjoitti:
BTW, I didn't answer anything for the Ada and Fortran issue... But
when I tried gcc-4.5.2 for 'sparc-elf' using
'--enable-languages=c,c++,ada,fortran' I first got a message saying
that GNAT is required on the $host for Ada. After removing and trying
with only 'fortran' being added, the build crashed in the libgfortran
configure. Why, wasn't yet very clear, the 'config.log' there only
gave :
configure:4414: checking whether symbol versioning is supported
configure:4425: error: Link tests are not allowed after GCC_NO_EXECUTABLES.
My guess is that a link test was done and it didn't succeed...
So, with its defaults the 'sparc-elf' target toolchain doesn't produce
executables for something... And it looks like C and C++ are fine but
other languages may be problematic without extra patches to the sources
or manual intervention during the build, for instance editing the
'specs' file for '*endfile' to include some linker script for some
real board/monitor. There seemed to be support for 'cygmon' in libgloss.
Adding '-T cygmon.ld%s' to the end of the '*endfile:' spec and removing
'crt0.o%s' from the beginning of the '*startfile:' spec did the job and
the libgfortran configure succeeded... Just building 'libgfortran' for
all the 'sparc-elf' multilibs (soft, v8, soft/v8)...
Some targets always have a default real target (board), some like the
'sparc-elf' then not. But editing the $BUILD/gcc/specs so that the
built 'xgcc' can produce executables, is one workaround in this kind
of situation...
I really don't know for what you would need Fortran in an embedded
system board. Ok, I have seen 'in-situ' "pole carrying capacity
analyzators" (for geomechanics) and gas analyzators with built-in
"computers" to do a lot number-crunching... Maybe something like
them...
