RFH: trouble getting gfortran to build multilib'ed

[Jim Wilson]

Steven Bosscher wrote:
> I'm trying to make libgfortran multilib'ed.  Configuring seems to work,
> but I keep running into the following problem:

I tried this with a mips-elf cross compiler build as I don't have an 
x86_64 machine (yet).

I ran into a few newlib cross issues.  libgfortran uses stdint.h 
conditionally, but its contents (e.g. int32_t) unconditionally, so if it 
is missing, we get parse errors where int32_t is used.  libgfortran uses 
sys/mman.h unconditionally in io/unix.c.  That file should perhaps not 
be compiled for a non-unix target, or else configured so it can be 
compiled for a non-unix target.  I hacked around these problems by 
manually defining the types and macros needed for the build.

After that, I noticed that all of the fortran library files are compiled 
wrong.  This is because the toplevel config-ml.in file does not define 
FFLAGS.  Search for CFLAGS, and add FFLAGS and any other Fortran defines 
you might need.  I didn't see any other obvious problem.  mips-elf 
doesn't build a shared library file, so there might be other issues I 
can't see with an embedded cross.

If that doesn't solve your problem, then you need to figure out why the 
link command for libgfortran.so isn't creating a 32-bit output file.  I 
noticed that there is no -m32 option on this command, which is probably 
a bug.  You need to figure out why it is missing.  Maybe it was missing 
because it wasn't in FFLAGS?  If the -m32 option isn't needed for the 
link, then you need to figure out why the linker is deciding to create a 
64-bit output file.  Maybe something else on the command line is a 
64-bit object?  You can pass verbose options to the linker to see what 
it is doing.  The linker might be collect though, which means you might 
not be able to just use -Wl,-verbose.  You have to get the linker 
command from collect, and then add verbose options there.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com