The problem I have on our own package is definitely a current problem
that requires the ld -search_paths_first option on Mac OS X. From man
ld on Mac OS X Snow Leopard:
-search_paths_first
By default the -lx and -weak-lx options first search
for a
file of the form `libx.dylib' in each directory in the
library search path, then a file of the form
`libx.a' is
searched for in the library search paths. This option
changes it so that in each path `libx.dylib' is
searched for
then `libx.a' before the next path in the library
search path
is searched.
Without -Wl,-search_paths_first:
/usr/bin/gcc -m32 -g -O -Wuninitialized -D_MACOSX -D_INTEL -
D_GFORTRAN -D_USE_PTHREADS -D_USE_SCHED -I/Users/baker/Desktop/
Earthworm/merged/include -I./ -o /Users/baker/Desktop/Earthworm/
merged/bin/reftek2ew main.o hbeat.o init.o notify.o params.o scn.o
send.o terminate.o samprate.o /Users/baker/Desktop/Earthworm/merged/
lib/transport.o /Users/baker/Desktop/Earthworm/merged/lib/getutil.o /
Users/baker/Desktop/Earthworm/merged/lib/kom.o /Users/baker/Desktop/
Earthworm/merged/lib/logit.o /Users/baker/Desktop/Earthworm/merged/
lib/sema_ew.o /Users/baker/Desktop/Earthworm/merged/lib/sleep_ew.o /
Users/baker/Desktop/Earthworm/merged/lib/time_ew.o /Users/baker/
Desktop/Earthworm/merged/lib/threads_ew.o -L./lib -lrtp -lreftek -
lutil -lm -lpthread
Undefined symbols:
"_util_sswap", referenced from:
_reftek_dt in libreftek.a(dt.o)
<snip>
With -Wl,-search_paths_first:
/usr/bin/gcc -m32 -g -O -Wuninitialized -D_MACOSX -D_INTEL -
D_GFORTRAN -D_USE_PTHREADS -D_USE_SCHED -I/Users/baker/Desktop/
Earthworm/merged/include -I./ -Wl,-search_paths_first -o /Users/
baker/Desktop/Earthworm/merged/bin/reftek2ew main.o hbeat.o init.o
notify.o params.o scn.o send.o terminate.o samprate.o /Users/baker/
Desktop/Earthworm/merged/lib/transport.o /Users/baker/Desktop/
Earthworm/merged/lib/getutil.o /Users/baker/Desktop/Earthworm/merged/
lib/kom.o /Users/baker/Desktop/Earthworm/merged/lib/logit.o /Users/
baker/Desktop/Earthworm/merged/lib/sema_ew.o /Users/baker/Desktop/
Earthworm/merged/lib/sleep_ew.o /Users/baker/Desktop/Earthworm/
merged/lib/time_ew.o /Users/baker/Desktop/Earthworm/merged/lib/
threads_ew.o -L./lib -lrtp -lreftek -lutil -lm -lpthread
While this may not be what Matthew is encountering, it is definitely
something to keep in your bag or tricks.
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On 15 Aug 2011, at 5:43 PM, Ralph Castain wrote:
FWIW: I build OMPI on Mac OS-X (Snow Leopard) every day, without
adding any extra flags, without problem. The citation below relates
to something from a long time ago, I believe - haven't seen that
problem in quite some time.
I do not, however, use PGI. We regularly have problems with PGI on a
variety of systems, and I suspect you are hitting one here - but
can't confirm it as we don't have PGI licenses to use for testing.
The Xgrid support is broken, but has nothing to do with the problem
you describe. Just means you can't launch via Xgrid.
On Aug 15, 2011, at 2:53 PM, Larry Baker wrote:
Matthew,
I have the same type of error on a completely different software
package on Mac OS X. The error occurs because of the way that Mac
OS X searches for -lutil. If the libutil.a ORTE needs is theirs,
i.e., not the system libutil.dylib, then you have exactly the same
problem I did.
Here are my notes for the fix using gcc. You will have to find out
the equivalent method to pass the -search_paths_first linker option
using pgcc.
# Mac OS X searches for shared libraries before static libraries.
Thus, -L<ours> -lutil finds the system libutil.dylib
# before our libutil.a, which causes undefined references in the
link step because it is using the wrong library. The
# ld -search_paths_first option forces ld to search each directory
first for a matching library, instead of all directories
# first for a shared library.
# Note: this is the form to pass -search_paths_first to ld when $
(CC) is the linker command in makefile.ux
export LDFLAGS=-Wl,-search_paths_first
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On 15 Aug 2011, at 1:01 PM, Matthew Russell wrote:
I hope this problem merits being posted here.
On OS X (Snow Leopard, and Lion), I cannot seem to build Open MPI.
After a lot of building, I get the error:
/bin/sh ../../../libtool --tag=CC --mode=link /opt/pgi/
osx86-64/10.9/bin/pgcc -DNDEBUG -O2 -Msignextend -V -export-
dynamic -o orte-clean orte-clean.o ../../../orte/libopen-rte.la-
lutil
libtool: link: /opt/pgi/osx86-64/10.9/bin/pgcc -DNDEBUG -O2 -
Msignextend -V -o orte-clean orte-clean.o ../../../orte/.libs/
libopen-rte.a /Users/matt/software/openmpi/openmpi-1.4.3/
opal/.libs/libopen-pal.a -lutil
Undefined symbols for architecture x86_64:
"_orte_odls", referenced from:
_orte_errmgr_base_error_abort in libopen-
rte.a(errmgr_base_fns.o)
ld: symbol(s) not found for architecture x86_64
This is with the PGI 10.9 compiler, OpenMPI 1.4.3, platform is 86x64
The README does not list PGI as a compiler that OpenMPI was tested
with, and there are notes about it's support for XGrid being
broken (I'm not sure if this is related.)
I seem to get the error regardless of which configure flags I'm
using, just for completeness though, here are the flags I am using:
./configure --prefix=/usr/local/openmpi_pg --enable-mpi-f77 --
enable-mpi-f90 --with-memory-manager=none
Has anyone else got or fixed this error?
I looked at other postings in this list, such as http://www.open-mpi.org/community/lists/devel/2007/05/1590.php
, but they didn't help much.
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
