Open MPI logo

Open MPI User's Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Open MPI User's mailing list

From: Brian Barrett (bbarrett_at_[hidden])
Date: 2007-04-09 17:35:01

On Apr 9, 2007, at 12:36 PM, Brian Barrett wrote:

> On Apr 6, 2007, at 7:22 AM, Werner Van Geit wrote:
>> In our lab we are installing OpenMPI onto our Apple cluster
>> computer. The cluster contains a couple of PowerPC G5 nodes and
>> the new Intel Xeon Xserves, all with a clean install of Mac OS X
>> Server 10.4.8 , Xcode 2.4.1 and Sun Grid Engine 6 (so we're not
>> using XGrid). Since we want to make it 1 big cluster, we need
>> Universal Binaries of OpenMPI.
>> We have been using the script available from the
>> contrib/dist/macosx-pkg from the openmpi-1.2.tar.gz file. If we
>> run this script on an Intel machine, we get fat binaries (checked
>> this with the command line "file" command) that run on the Intel
>> machine (we used "ompi_info" as the test), but not on the G5
>> machines. While running ompi_info) we get an error:
>> dyld: Symbol not found: _lt_libltdlc_LTX_preloaded_symbols
>> Referenced from: /tmp/werner/mpi/lib/libopen-pal.0.dylib
>> Expected in: flat namespace
>> Trace/BPT trap
> I've managed to track this down a little, and there is definitely
> something wrong with the build of libltdl when we cross-compile on
> Darwin. I've looked a little bit, but haven't had any great
> success in determining what is going on. I'm going to start
> working with the Libtool developers to try to sort this one out,
> but it might take some time. In the mean time, you can build with
> either static or shared libraries, but disabling the dlopen() code
> with the argument --disable-dlopen (which you already discovered).
> Using shared libraries instead of static should still work for you,
> but make adding interconnects or rebuilding Open MPI a bit easier
> on your users.
> I've filed a bug in Trac for the problem. You should get updates
> on the bug via e-mail and anyone else can follow along at:

A little digging and I've found the problem. When building for
architectures other than the build host (which is always either ppc
or i386), Autoconf believes that we are cross-compiling. It really
wants to prepend the target architecture to programs like gcc, g++,
nm, ranlib, etc. It will generally figure out not to do that (since
the system gcc is always a cross-compiler to any of the four
platforms on OS X), but it appears that's not the case with one
libtool test for nm. This leads to a series of mistakes on the part
of Libtool. The short solution is to specify NM="nm -p" when cross-
compiling on OS X. I've updated the build script for v1.2 here:

I'll make sure the updated script is part of the v1.2.1 release. The
updates include some fixes to be a little smarter about what binaries
to build and workarounds for various problems we've found in our
x86_64 support and the NM issue.