Hi all.
I'm new to this list.
I followed the instructions for using MPICH (1.0.7) located here : http://wiki.freepascal.org/MPICH , and it works perfectly under Linux (Centos 5.2) and Win32 (XP). However, trying to do the same thing on Leopard (10.5.5) fails. First, to compile well, i had to add the following directive : {$Linklib mpi} to the HelloWorld1 sample. If i don't, ld outputs : "Symbol not found : _MPI_Init" ...: the library cannot be found, even if i have added the library path to /etc/fpc.cfg, or if i put the library in location already covered by the paths (i checked the link.res file). I checked libpmpi.a with nm, and symbols are well present.
After having added the {$Linklib mpi} directive (or manually change the ppaslink.sh file or even directly using ld), it compiles well, but can't run.
Here's the behaviour :

nemes:mpich2 jideel$ mpiexec -n 1 HelloWorld1
[nemes:00407] *** Process received signal ***
[nemes:00407] Signal: Segmentation fault (11)
[nemes:00407] Signal code: Address not mapped (1)
[nemes:00407] Failing at address: 0x44000088
[ 1] [0xbffff4d8, 0x44000088] (-P-)
[ 2] (PASCALMAIN + 0x45) [0xbffff4f8, 0x00001705]
[ 3] (FPC_SYSTEMMAIN + 0x45) [0xbffff508, 0x0001b475] [ 4] (start + 0xfc) [0xbffff548, 0x0000169c]
[ 5] (start + 0x29) [0xbffff56c, 0x000015c9]
[ 6] [0x00000000, 0x00000001] (FP-)
[nemes:00407] *** End of error message ***
mpiexec noticed that job rank 0 with PID 407 on node nemes.local exited on signal 11 (Segmentation fault).
nemes:mpich2 jideel$

if i use gdb, it outputs :

Reading symbols for shared libraries . done
....
Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x44000088 0x000df006 in MPI_Comm_rank ()

Platform is a Macbook Pro Intel Core 2 Duo, Xcode 3.0 installed.

I checked there was no other MPI libraries that could conflict, it doesn't seems there is.

I tried all the manipulations either from Lazarus (0.9.27) or directly from command line, using fpc and a modified Makefile to 'cut' Lazarus component from the build process, behaviour is the same.

I checked other forums, there's somewhat similar problems, but with openmpi, or some other libraries, but no solution provided.

Any idea or suggestion are welcome
Thanks.

No, on Mac OS X the library is simply not searched without the linklib statement.

even if i have added the library path to /etc/fpc.cfg, or if i put the library in location already covered by the paths (i checked the link.res file). I checked libpmpi.a with nm, and symbols are well present

The linker will always prefer a dynamic over a static library if you simply use {$linklib xxx} (which is equivalent with the linker parameter -lxxx, which is equivalent on non-Mac OS X FPC platforms with "procedure test; cdecl; external 'xxx' name 'test';"; but adding {$linklib xxx} does not hurt on other platforms either).

If you want to link with a static library, you have to specify the full path name of the file to the linker, using FPC's -k parameter: - k"/full/path/to/libmpi.a"

You are linking against the system-installed version of mpi, which is not mpich2 (for which the header translation was made). 0x44000000 is the value of MPI_COMM_WORLD in the mpich2 distribution, but in the version shipped with Mac OS X MPI_COMM_WORLD is the address of some symbol instead (and hence you get a segmentation fault when the program tries to read something from a struct supposedly located at 0x44000000).

Jonas

Ok,

If i try to compile using the following command line : fpc -k/Users/ jideel/mpich2/lib/libmpich.a -k/Users/jideel/mpich2/lib/libpmpich.a HelloWorld1.pp , it builds and executes succesfully. I was not aware of this behaviour on Mac OS X.
Many thanks for your quick response.
I removed the openmpi dynamic libs provided with Leopard, do you think i should enable shared libs while building MPICH2 ("--enable- sharedlibs"), and thus be able to avoid the -k switches ?

jideel wrote

If i try to compile using the following command line : fpc -k/Users/ jideel/mpich2/lib/libmpich.a -k/Users/jideel/mpich2/lib/libpmpich.a HelloWorld1.pp , it builds and executes succesfully. I was not aware of this behaviour on Mac OS X.

I don't know whether it is specific to Mac OS X that the linker prefers dynamic over static libraries. You were also specifying the wrong library name to the linker (mpi rather than mpich). The system- installed version is called libmpi, the one you want is libmpich (and apparently also libmpich). You might also be able to use {$l libmpich.a} and {$l libpmpich.a} in the source (*not* {$linklib libmpich.a}) to explicitly refer the static libraries.

Many thanks for your quick response. I removed the openmpi dynamic libs provided with Leopard,

I hope that in the future you will restore this library before reporting any problems, as it might be caused by you removing system- supplied libraries (including general system instability and what not). In general, I would strong recommend against removing system libraries (regardless of whether you're on Mac OS X, Linux or Windows).

do you think i should enable shared libs while building MPICH2 ("-- enable-sharedlibs"), and thus be able to avoid the -k switches ?

That would be an option. But then you will also have to learn about library install names on Mac OS X if you intend to distribute your program to other people. And at least in this case, simply linking against mpich/pmich rather than against mpi will also solve your problem.

Jonas

During investigation, i did some renaming (mpich to mpi) to check whether it changes something or not, that's why the library name was wrong.
thanks for the directive's tip.

By 'removing', i meant 'move to a temporary location' :) I did this because it seemed to have been installed by the XCode package, but perhaps i'm wrong.
I do agree with you about system manipulations, so i'll follow your suggestion and restore them.

This is not intended to be distributed, this is rather an experimentation (pathfinding, comparison with Erlang (as long as it can be compared...)).

Jonas _______________________________________________ fpc-devel maillist - http://lists.freepascal.org/mailman/listinfo/fpc-devel

By the way, it seems that the MPI implementation provided by Apple is OpenMPI rather than MPICH2 (from their site : "MPICH2 currently does not support heterogeneous platforms.", that's why i looked at OpenMPI). I tried h2pas with it to generate some bindings, but (of course) my first attempt failed, i'll try again this week.

Thanks again,

Jd

h2pas is quite rudimentary. Most of the time it can only be used to generate some skeleton conversion, which needs manual finishing afterwards.

Jonas