Upon further examination, I've discovered that this is HARMLESS noise.
The "|| { rm && ln -s }" part DOES make the required symlink.
In fact, ltmain.sh has a comment on this subject:
# Delete the old symlinks, and create new ones.
# Try `ln -sf' first, because the `ln' binary might depend on
# the symlink we replace! Solaris /bin/ln does not
understand -f,
# so we also need to try rm && ln -s.
Sorry for this report, which turned out NOT to be an actual problem.
-Paul
On 1/31/2012 6:53 PM, Paul H. Hargrove wrote:
The problem I described below is ALSO present in hwloc-1.4
-Paul
On 1/31/2012 5:43 PM, Paul H. Hargrove wrote:
When running "make install" for hwloc-1.3.1 on my Solaris-10/x86
system I am seeing multiple messages like:
libtool: install: (cd
/export/home/phargrov/OMPI/hwloc-1.3.1-solaris10-x86-gcc343/INST/lib
&& { ln -s -f libhwloc.so.4.1.4 libhwloc.so.4 || { rm -f
libhwloc.so.4 && ln -s libhwloc.so.4.1.4 libhwloc.so.4; }; })
Usage: ln [-f] [-s] f1
ln [-f] [-s] f1 f2
ln [-f] [-s] f1 ... fn d1
This is because "ln -s -f" is being run by libtool while "ln" on this
platform is happy only with "ln -f -s".
This sensitivity to argument order is sad, but true.
-Paul
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900