[Ipopt] Compiling ipopt with ma77

[Mehmet Ersin YUMER]

Hi,

I solved this problem and am currently able to succesfully use ma77 with
ipopt-trunk. I am sending this email to the list so that it might help
others which might face the same problem with a 64-bit OS X. The problem is
related to strict stack requirements in libdyld.dylib. if you configure and
compile Ipopt and ThirdParty code with the following flags strictly for
64-bit, then libdyld will not complain:

from within $[ipopt_dir]:

mkdir build_x64
cd build_x64

../configure 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"

make
make test
make install



On Wed, Jan 23, 2013 at 5:08 PM, Mehmet Ersin YUMER <meyumer at gmail.com>wrote:

> Tony,
>
> This was a good pointer. In fact I cleaned out those left out files, but I
> still have another problem. Has someone experienced this before? Once
> again, this is happening only in the case of ma77. other linear solvers
> (ma27, ma57, mumps) do run and terminate normally.
> IpOpt breaks with an error thrown from libdyld:
>
> libdyld.dylib`misaligned_stack_error_entering_dyld_stub_binder:
>
> 0x7fff8defe8a5:  movdqa %xmm0, 64(%rsp)   <<<<  EXC_BAD_ACCESS (code =
> 13, address = 0x0)
>
> 0x7fff8defe8ab:  movdqa %xmm1, 80(%rsp)
>
> 0x7fff8defe8b1:  movdqa %xmm2, 96(%rsp)
>
> 0x7fff8defe8b7:  movdqa %xmm3, 112(%rsp)
>
> 0x7fff8defe8bd:  movdqa %xmm4, 128(%rsp)
>
> 0x7fff8defe8c6:  movdqa %xmm5, 144(%rsp)
>
> 0x7fff8defe8cf:  movdqa %xmm6, 160(%rsp)
>
> 0x7fff8defe8d8:  movdqa %xmm7, 176(%rsp)
>
>
> On Wed, Jan 23, 2013 at 2:15 PM, Tony Kelman <kelman at berkeley.edu> wrote:
>
>> Mehmet,
>>
>> A problem I've seen that is unique to MA77 is that it saves data files to
>> disk in the current execution folder, containing intermediate evaluation
>> results ("out-of-core"). Under normal circumstances it should delete those
>> files when finished, but if you've been testing or Ipopt/MA77 terminated in
>> some unusual way, sometimes those files are left around. Next time you try
>> to call MA77, if those files exist already, it causes an error rather than
>> overwriting them. So look and see if there are any unexpected data files
>> named "ma77_work" or otherwise ma77_* in the current folder, if so try
>> deleting them and rerunning Ipopt.
>>
>> -Tony
>>
>>
>> -----Original Message----- From: Mehmet Ersin YUMER <meyumer at gmail.com>
>> Date: Tue, 22 Jan 2013 14:25:08 -0500
>> To: Stefan Vigerske <stefan at math.hu-berlin.de>
>> Cc: ipopt at list.coin-or.org
>> Subject: Re: [Ipopt] Compiling ipopt with ma77
>>
>>
>> Hi Stefan,
>>
>> Thanks for your reply. I am still having problems but the problem changed
>> a
>> little. I am able to successfully build ipopt trunk version with ma77 but
>> cannot solve the optimization problem with it, here is a breakdown:
>>
>> - I checked out the trunk version with svn, and placed a    coinhsl
>> directory into $[ipopt_dir]/ThirdParty/HSL/   whose contents are the
>> contents of      coinhsl-2012.12.21.tar.gz.
>>
>> - run ./get.Metis and ./get.Mumps  from their directories.
>>
>> - Create build directory in $[ipopt_dir].
>>
>> - Run ../configure,  make,  make test,  make install   from within
>> $[ipopt_dir]/build/
>>
>> Using the newly created libraries and include files in the build
>> directory,
>> I am able to solve a test problem succesfully with ma27, ma57, and mumps.
>> However, when I try solving the problem with ma77, I get the output below,
>> and Ipopt terminates. As can be understood from above, I did not use any
>> flags while configuring Ipopt. Let me know if you can guess what the
>> problem might be with ma77.
>>
>> Thanks.
>>
>>
>
>
> --
> Mehmet Ersin Yumer
>



-- 
Mehmet Ersin Yumer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/ipopt/attachments/20130124/5700b775/attachment.html>