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 PHHargrove_at_[hidden]
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
|
![[Flag]](../../../../../community/mirrors/flag-us.gif){kind=small}