Hi,
On Fri, Mar 19, 2010 at 03:25:36AM -0400, Scott Brozell wrote:
> On Thu, Mar 18, 2010 at 11:22:35PM -0400, case wrote:
> > On Thu, Mar 18, 2010, Volodymyr Babin wrote:
> >
> > That is what I have been trying, slightly modified:
> >
> > fl=`which ifort | sed -e 's?bin/ifort?lib?'`
> > flibs_arch="-L$fl -lifport -lifcore"
> >
> > For the version 11 compilers, $fl points to a non-existent directory, but
> > that is OK, since version 11 knows where to look anyway. For version 10,
Nope. An invalid path in flibs can cause nab to fail.
Here's an improvement:
-------------------------------------------------------------------------
*** configure.original 2010-03-31 22:59:26.000000000 -0400
--- configure 2010-04-04 20:55:05.000000000 -0400
***************
*** 466,472 ****
intel)
# following reported works on Intel compilers version 9,10,11; the
# "-L$fl" part is not needed for version 11, but doesn't seem to hurt
! fl=`which ifort | sed -e 's?bin/ifort?lib?'`
flibs_arch="-L$fl -lifport -lifcore"
flibsf_arch=
--- 466,472 ----
intel)
# following reported works on Intel compilers version 9,10,11; the
# "-L$fl" part is not needed for version 11, but doesn't seem to hurt
! fl=`which ifort | sed -e 's.bin.lib.' -e 's.ifort..'`
flibs_arch="-L$fl -lifport -lifcore"
flibsf_arch=
-------------------------------------------------------------------------
This produces the correct path when which ifort is
/usr/local/intel-11.1.056/bin/intel64/ifort
scott
> > the above code (or equivalently, yours, assuming dirname exists on all
> > systems), works for me. I don't have access to version 9 intel
> > compilers, but if someone could check for that, this could be a solution.
>
> It works for me:
> % ifort -v
> Version 9.1
> % which ifort | sed -e 's?bin/ifort?lib?'
> /usr/local/intel-9.1-20070320/lib
> % ls /usr/local/intel-9.1-20070320/lib/libifport.a
> /usr/local/intel-9.1-20070320/lib/libifport.a
> ...
>
> > I know from my own experience how easy it is to get a really weird
> > LD_LIBRARY_PATH variable, and I don't think we can rely on that being set
> > correctly.
>
> Fair enough; here's the am-dev on this ancient history:
>
> Date: Thu, 4 Mar 2010 22:50:56 -0500
> From: Scott Brozell <sbrozell.rci.rutgers.edu>
> Subject: Re: [AMBER-Developers] more on ptraj compilation with Intel
>
> > > i think a more clever solution is to use LD_LIBRARY_PATH.
> >
> > You can give it a try, but (by its name) LD_LIBRARY_PATH should be applicable
> > at load time, not at link time(?). Dan reports not having any luck with
> > LD_LIBRARY_PATH. In any event, if you can set whatever PATH works, you could
> > also set flibs_arch, which seems far safer to me.
>
> My point is that the dynamic libs and the static ones are probably in
> the same dirs. So we can use LD_LIBRARY_PATH at compile time.
> This didnt turn out as clever as i had hoped since -L doesnt parse the :
> separator; so my patch has to use sed:
> flibs_arch=`echo $LD_LIBRARY_PATH | sed -e 's/^\(.\)/-L \1/' -e 's/:/ -L /g'`
> flibs_arch=" $flibs_arch -lifport -lifcore"
> This isnt much (if any) improvement over your suggestion; it is slightly
> easier to implement, but may not be as robust.
>
> Testing needed here !
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Sun Apr 04 2010 - 19:00:02 PDT
