[Ipopt] problems on OS X 10.7 Lion

[Ray Zimmerman]

For anyone who is interested in pursuing further the issues with Lion's BLAS when using the Accelerate/vecLib frameworks, below is a response I got from Charlie Sharpsteen to an e-mail I sent to him. If anyone gets a chance to sort through this issue and get Ipopt working with the native OS X BLAS (in Accelerate/vecLib), please post your solution here.

Btw, I also tried the Goto BLAS, but I can't seem to make a 64-bit version without the following sorts of errors:

../kernel/x86_64/symv_U_sse.S:410:32-bit absolute addressing is not supported for x86-64
../kernel/x86_64/symv_U_sse.S:410:cannot do signed 4 byte relocation

Thanks,

-- 
Ray Zimmerman
Senior Research Associate
419A Warren Hall, Cornell University, Ithaca, NY 14853
phone: (607) 255-9645

On Oct 18, 2011, at 4:47 PM, Charlie Sharpsteen wrote:
> On Tue, Oct 18, 2011 at 11:54 AM, Ray Zimmerman wrote:
> Hi Charlie,
> 
> I ran across some comments of yours at https://github.com/mxcl/homebrew/issues/6649#issuecomment-1666673 that appeared relevant to an issue I'm having.
> 
> I have been running into issues with building a numerical optimization package (Ipopt) on Mac OS X Lion and I finally tracked it down to an issue with the BLAS in the Accelerate or vecLib frameworks (I assume both reference the same BLAS library?).
> 
> That is correct. vecLib is actually a sub-component of Accelerate.
> 
>  
> I found that if I force Ipopt to use a reference BLAS/LAPACK from netlib, everything works fine, but I'd really like to stick to the optimized versions provided by Apple for obvious reasons.
> 
> I was wondering if you have any suggestions for how I might work around these issues in my situation. The following threads describe my attempts to get this package working on Snow Leopard (solved) and now Lion.
> 
>   http://list.coin-or.org/pipermail/ipopt/2011-October/002609.html
>   http://list.coin-or.org/pipermail/ipopt/2011-October/002610.html
> 
> In case it matters, some of the parts of Ipopt are built from fortran code, and I'm using the gfortran from gfortran-lion-5666-3.pkg at http://r.research.att.com/tools/
> and the following configure options for Ipopt.
> 
> ../configure --with-blas="-framework vecLib" \
>     --with-lapack="-framework vecLib" F77=gfortran \
>     FFLAGS="-fexceptions -m64 -fbackslash" \
>     CFLAGS="-fno-common -no-cpp-precomp -fexceptions -arch x86_64 -m64" \
>     CXXFLAGS="-fno-common -no-cpp-precomp -fexceptions -arch x86_64 -m64" \
>     -disable-shared
> 
> Thanks in advance for any insight you might have to share.
> 
> On Snow Leopard, you should be able to fix the vecLib BLAS by installing the `dotwrp` library (https://github.com/tenomoto/dotwrp) which is a simple set of wrapper functions that normalize the BLAS API so that it can be linked during 64-bit compilation. To do so, make sure libdotwrp is linked first:
> 
>   --with-lapack="-ldotwrp -framework vecLib"
> 
> I haven't upgraded to Lion yet, but from what I have heard the bug that `dotwrp` was fixing got fixed in a different way by Apple. In this case, the only way to properly link against vecLib may be to force GFortran into the legacy G77 mode using the `-ff2c` switch. This is explained in the documentation for the vecLib Framework:
> 
>   http://developer.apple.com/hardwaredrivers/ve/errata.html#fortran_conventions
> 
> I have tried going this route before and it was a major pain in the rear---there are a lot of software components that simply expect the newer GFortran linking conventions to be used and things tend to turn into a confused mess if some parts of the program have to use G77 conventions.
> 
> If it turns out that G77 conventions are required on Lion, I would take a hard look at how badly you need the vecLib BLAS. Do some profiling on Snow Leopard and see exactly how much speedup you get compared to NetLib. Perhaps another optimized implementation such as ATLAS (http://math-atlas.sourceforge.net) or GOTO BLAS (http://www.tacc.utexas.edu/tacc-projects/gotoblas2) would give you enough speed without the linking headache. The BLAS in Intel's Math Kernel Library is also pretty darn good if you have access to it.
> 
> Good Luck!
> 
> -Charlie


And later he wrote ...

On Oct 21, 2011, at 1:04 PM, Charlie Sharpsteen wrote:
> On Fri, Oct 21, 2011 at 9:42 AM, Ray Zimmerman wrote:
> On Oct 18, 2011, at 4:47 PM, Charlie Sharpsteen wrote:
> 
>> On Snow Leopard, you should be able to fix the vecLib BLAS by installing the `dotwrp` library (https://github.com/tenomoto/dotwrp) which is a simple set of wrapper functions that normalize the BLAS API so that it can be linked during 64-bit compilation. To do so, make sure libdotwrp is linked first:
>> 
>>   --with-lapack="-ldotwrp -framework vecLib"
> 
> Hmmm ... the thing is, I haven't had any problems with the BLAS in vecLib on Snow Leopard ... only on Lion. And as far as I can tell the -ldotwrp flag is not being used anywhere.
> 
> Under GFortran linking conventions on Snow Leopard the COMPLEX and DOUBLE COMPLEX routines are affected. This is a relatively rare data type for a matrix so the bug is obscure.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/ipopt/attachments/20111021/5f845eac/attachment.html>