Odd addressing/linking problem on Mac OS X

[truedas]

Hi,
I am trying to compile a parallel program on a 64-bit architecture, namely on a Mac OS X (Leopard, I think) with Intel Fortran v. 10.0 and MPICH2-1.2.1p1. The MPICH2 has been built for 64-bit, and the gcc and its libraries are also for 64-bit. The program itself seems to be compiled ok, but when I link to built the executable, I get this error:

ld: in plot.o, ObjectFileAddressSpace::mappedAddress(0xFFFFFFFFFFFFFFFC) not in any section

I don't even understand what this means, i.e. what kind of error, bug, or other problem could cause such an error. Any ideas?

I used to build the whole thing with 32-bits, and that worked ok, but it seems I can't do that anymore right now on that machine, because the admin has changed things.
Thomas

[mecej4]

There are a number of known problems of this type with Mac OS X; many of them are specific to which versions of OSX, the Intel compiler, GCC were used and which compiler options were specified. Many have work-arounds. See, for instance,
this link.

[truedas]

Hi,
thanks so far; at least I know now that I can't build a 64-bit executable. That's in principle ok, a 32-bit one will in principle do just as fine. However, now I have different problem.
I have rebuilt MPICH2 as well as my own code for 32-bit now. This program is mostly Fortran 90, with one single C subroutine, which I build with gcc (also for 32-bit, of course). However, when linking everything, I receive this message:
ld: warning: in /usr/lib/gcc/i686-apple-darwin10/4.2.1/x86_64//libgcc.a, file was built for unsupported file format which is not the architecture being linked (i386)

I have tried to resolve this by explicitly adding the path to the 32-bit version of the lib to the LFLAGS, but regardless of whether I do that or not, the program crashes immediately on startup with a segfault:
Image PC Routine Line Source
stagyy 003004B5 Unknown Unknown Unknown
stagyy 002FF957 Unknown Unknown Unknown
stagyy 002C48B8 Unknown Unknown Unknown
stagyy 00287FDE Unknown Unknown Unknown
stagyy 0028E958 Unknown Unknown Unknown
libSystem.B.dylib 930EA1FB Unknown Unknown Unknown
Unknown FFFFFFFF Unknown Unknown Unknown
...

This happens with both the parallel version that includes the MPI stuff and with the serial version without the MPI libs, so it's the compiler. I also tried adding the paths to the 32-bit libs explicitly to $DYLD_LIBRARY_PATH, with no success either. I guess I have to force the compiler somehow to pick the 32-bit version of the gcc libs, but how do I do that?
Thomas

[mecej4]

The following comments are based on the assumption that things on OSX are similar to those on Linux.

It is straightforward to develop 32-bit Fortran objects on a 64-bit OS, once the environment has been setup by running the script ifortvars.(c)sh ia32. If you are using gcc to do the linking, you need the -m32 option, which should then take care of using the 32-bit system libraries without your having to specify the directory containing the libraries.

You cannot mix 32- and 64-bit objects and libraries while linking a program.

[truedas]

Ok, I tried that too:
Set up the env for 32-bit:
. /opt/intel/fc/10.0.016/bin/ifortvars.sh ia32
(also added "source /opt/intel/fc/10.0.016/bin/ifortvars.sh ia32" to my ~/.profile for good measure).
Run make with ifort and these options in compilation as well as the linking step:
ifort -m32 -extend_source -O2 -fpe0 -cm

Still, it is
ld: warning: in /usr/lib/gcc/i686-apple-darwin10/4.2.1/x86_64//libgcc.a, file was built for unsupported file format which is not the architecture being linked (i386)
in other words, it doesn't take the settings. I don't know what else to tell.
Thomas

[TimP]

The -m32 option is for gcc. You would need to build MPICH with ifort ia32 and gcc -m32 as well.
Have you taken the time to go through your object directories with 'file *.o' to find your mis-match?

[truedas]

There is also an -m32 option for the v.10 Intel compilers on Mac OS X (not for Linux or Windows, though). This is the one I use. Also, the problem with the linking step must be unrelated to MPICH, because they occur both when creating the parallel version executable (where MPICH is linked) and the serial version executable (where MPICH is not involved or linked at all).
Running file on all .o files reports them as being "Mach-O object i386" for both the objects from Fortran and C sources. No exceptions. Isn't that a 32-bit file?
It must have to do with the paths, because the warning I get from ld:
ld: warning: in /usr/lib/gcc/i686-apple-darwin10/4.2.1/x86_64//libgcc.a, file was built for unsupported file format which is not the architecture being linked (i386)
shows directly that ld tried to link the 64-bit version of libgcc instead of the 32-bit version.

[TimP]

Yes, that certainly looks like a 64-bit library. How is the path for libgcc chosen when invoking ld? If you use mpif77 or mpf90 built for ifort to link, the additional option -# should show the link script which is built up and shipped to ld. If you have a makefile which is invoking gcc or g++ mpi wrappers for the link, -m32 option would be required there too, if you didn't build in that option when making the wrappers.

[truedas]

If I only knew how the path for libgcc is chosen! The "option" -# (which I have to enter as -\# to avoid having the # interpreted as a comment sign) spits out a lot of information. The bit relevant for the library paths is apparently this:
"-mIPOPT_cmdline_link="-lcrt1.o" "-dynamic" "-arch" "i386" "-weak_reference_mismatches" "non-weak" "-o" "stagyy" "/opt/intel/fc/10.0.016/lib/for_main.o" "main.o" (... leaving out several objects from my code ...) "-L/opt/intel/fc/10.0.016/lib" "-L/usr/lib/gcc/i686-apple-darwin10/4.2.1/x86_64/" "-L/usr/lib/" "/opt/intel/fc/10.0.016/lib/libifport.a" "/opt/intel/fc/10.0.016/lib/libifcore.a" "/opt/intel/fc/10.0.016/lib/libimf.a" "/opt/intel/fc/10.0.016/lib/libsvml.a" "/opt/intel/fc/10.0.016/lib/libipgo.a" "-lgcc" "/opt/intel/fc/10.0.016/lib/libirc.a" "/opt/intel/fc/10.0.016/lib/libirc_s.a" "-ldl"" \
-mIPOPT_save_il0 \
-mIPOPT_il_in_obj \
-mIPOPT_ipo_activate_warn=FALSE \
-mIPOPT_obj_output_file_name=/tmp/ipo_ifortsCkGpV.o \
-mGLOB_os_target=GLOB_OS_TARGET_MACH \

So the bloody thing keeps pointing to /usr/lib/gcc/i686-apple-darwin10/4.2.1/x86_64 although /usr/lib/gcc/i686-apple-darwin10/4.2.1/ contains a libgcc.a as well (and one that, I assume, is 32-bit).
I did use the -m32 option with both ifort and gcc on all occasions; note that my last test was done for the serial code version only, so the MPI stuff is left out altogether now to make things easier.