[Ipopt] Build error "error: linking to Fortran libraries from C fails"

Stefan Vigerske stefan at math.hu-berlin.de
Thu Aug 15 08:50:42 EDT 2013


Hi,

On 08/15/2013 12:24 PM, John Pye wrote:
> Hi Stefan
>
> I reported the bug as requested, see
> https://projects.coin-or.org/Ipopt/ticket/215. Please let me know if
> there is any further information needed.
>
> Do you have anywhere a complete description of a MinGW-w64 build
> environment that currently *does* build IPOPT successfully? I would be
> perfectly happy to modify my build environment if you know something
> that already works (providing my other stuff still builds in that new
> setup).

I don't have descriptions for this platform. All we have is a few lines 
in the documentation:
http://www.coin-or.org/Ipopt/documentation/node15.html#SECTION00045300000000000000

> And while I've got your attention, some suggested steps for a
> higher-performance IPOPT build, using OpenBLAS, would be useful. I
> understand that the binary distribution of the OpenBLAS DLL for
> MinGW-w64 64-bit also includes LAPACK, so what are the ./configure flags
> to make that work correctly?

It should be sufficient to set the --with-blas flag so that it 
recognizes this library. The check for Lapack first tests whether Lapack 
is already included in the Blas library.

Stefan

>
> Cheers
> JP
>
>
> On 15/08/13 18:58, Stefan Vigerske wrote:
>> Hi,
>>
>> something may have gone wrong when configure tried to patch up libtool
>> for use under mingw with gnu compilers.
>> Please open a ticket and attach your config.log files, so we can see
>> what is happening, see also
>> https://projects.coin-or.org/BuildTools/wiki/user-troubleshooting
>>
>> Stefan
>>
>> On 08/15/2013 04:58 AM, John Pye wrote:
>>> Hi Tony
>>>
>>> Thanks very much for the help; it's as I suspected then, something about
>>> the way that the IPOPT build scripts are handling those big long lists
>>> of 'gcc -v' parameters. I note that I've managed to build SUNDIALS and
>>> GSL perfectly well with the rubenvb MinGW-w64 GCC, but neither of these
>>> involving linking C/C++ code to Fortran code. I'm not exactly sure what
>>> "--with-host-libstdcxx" means and where it's used I don't know, but it
>>> seems odd to specify that libstdc++ has to be linked statically, if
>>> that's what it's saying.
>>>
>>> Anyway, so I took your suggestion and downloaded the 'tdb-gcc' tool. But
>>> I'm getting new errors (see below) which look like the MinGW-w64
>>> environment is still not being correctly detected. It's trying to run a
>>> command "lib /OUT" which looks like a Visual C++ thing to me, or
>>> something like that. This is all very puzzling, as I'm fairly sure I did
>>> manage to build IPOPT against MinGW-w64 in the past...!
>>>
>>> Perhaps it would be an option to use a separately compiled LAPACK, but
>>> as earlier, I would expect the problem just to pop up elsewhere in that
>>> case.
>>>
>>> Cheers
>>> JP
>>>
>>> /bin/sh ./../../libtool --tag=F77 --mode=compile gfortran  -g -O0
>>> -pipe   -c -o zsyr.lo zsyr.f
>>>   gfortran -g -O0 -pipe -c zpotf2.f -o zpotf2.o
>>> ./../../libtool: line 338: cygpath: command not found
>>> /bin/sh ./../../libtool --tag=F77 --mode=compile gfortran  -g -O0
>>> -pipe   -c -o zsytri.lo zsytri.f
>>> ./../../libtool: line 338: cygpath: command not found
>>> ./../../libtool: line 1082: cygpath: command not found
>>> ./../../libtool: line 1082: cygpath: command not found
>>> ./../../libtool: line 1082: cygpath: command not found
>>>   gfortran -g -O0 -pipe -c zrot.f -o zrot.o
>>>   gfortran -g -O0 -pipe -c zsymv.f -o zsymv.o
>>>   gfortran -g -O0 -pipe -c zsyr.f -o zsyr.o
>>>   gfortran -g -O0 -pipe -c zsytri.f -o zsytri.o
>>> /bin/sh ./../../libtool --tag=F77 --mode=link gfortran  -g -O0 -pipe
>>> -o libcoinlapack.la -rpath /mingw/lib -version-info 5:3:4
>>>   dbdsqr.lo dgebal.lo dgebak.lo dgebd2.lo dgebrd.lo dgeev.lo dgehd2.lo
>>> dgehrd.lo dgelq2.lo dgelqf.lo dgels.lo dgeqr2.lo dgeqrf.lo d
>>> gesvd.lo dgesv.lo dgetf2.lo dgetrf.lo dgetri.lo dgetrs.lo dggbak.lo
>>> dggbal.lo dgghrd.lo dggev.lo dhgeqz.lo dhseqr.lo disnan.lo dla
>>> bad.lo dlabrd.lo dlacpy.lo dladiv.lo dlaebz.lo dlae2.lo dlaev2.lo
>>> dlaexc.lo dlagtf.lo dlagts.lo dlag2.lo dlahqr.lo dlahr2.lo dlais
>>> nan.lo dlaln2.lo dlamch.lo dlaneg.lo dlange.lo dlanhs.lo dlanst.lo
>>> dlansy.lo dlanv2.lo dlapy2.lo dlapy3.lo dlaqr0.lo dlaqr1.lo dla
>>> qr2.lo dlaqr3.lo dlaqr4.lo dlaqr5.lo dlarf.lo dlarfb.lo dlarfg.lo
>>> dlarft.lo dlarfx.lo dlarnv.lo dlarra.lo dlarrb.lo dlarrc.lo dlar
>>> rd.lo dlarre.lo dlarrf.lo dlarrj.lo dlarrk.lo dlarrr.lo dlarrv.lo
>>> dlartg.lo dlartv.lo dlaruv.lo dlar1v.lo dlas2.lo dlascl.lo dlase
>>> t.lo dlasq1.lo dlasq2.lo dlasq3.lo dlasq4.lo dlasq5.lo dlasq6.lo
>>> dlasr.lo dlasrt.lo dlaswp.lo dlassq.lo dlasv2.lo dlasyf.lo dlasy2
>>> .lo dlatrd.lo dorg2l.lo dorg2r.lo dorgbr.lo dorghr.lo dorglq.lo
>>> dorgl2.lo dorgql.lo dorgqr.lo dorgtr.lo dorm2r.lo dormbr.lo dormhr
>>> .lo dorml2.lo dormlq.lo dormql.lo dormqr.lo dormtr.lo dorm2l.lo
>>> dpotf2.lo dpotrf.lo dpotrs.lo dstebz.lo dstein.lo dstemr.lo dsteqr
>>> .lo dsterf.lo dsyev.lo dsyevr.lo dsyevx.lo dsytd2.lo dsytf2.lo dsytrd.lo
>>> dsytrf.lo dsytri.lo dtgevc.lo dtrevc.lo dtrexc.lo dtrti2.
>>> lo dtrtri.lo dtrtrs.lo ieeeck.lo iladlc.lo iladlr.lo ilaenv.lo iparmq.lo
>>> sgetf2.lo sgetrf.lo slamch.lo slaswp.lo zgetf2.lo zgetrf.
>>> lo zlacgv.lo zlacpy.lo zlaev2.lo zlaswp.lo zpotf2.lo zrot.lo zsymv.lo
>>> zsyr.lo zsytri.lo
>>> *./../../libtool: line 338: cygpath: command not found**
>>> **./../../libtool: line 1082: cygpath: command not found**
>>> *mkdir .libs
>>> libtool: link: warning: undefined symbols not allowed in
>>> x86_64-w64-mingw32 shared libraries
>>> *lib /OUT:.libs/libcoinlapack.lib*   dbdsqr.o dgebal.o dgebak.o dgebd2.o
>>> dgebrd.o dgeev.o dgehd2.o dgehrd.o dgelq2.o dgelqf.o dgels.o
>>>   dgeqr2.o dgeqrf.o dgesvd.o dgesv.o dgetf2.o dgetrf.o dgetri.o dgetrs.o
>>> dggbak.o dggbal.o dgghrd.o dggev.o dhgeqz.o dhseqr.o disna
>>> n.o dlabad.o dlabrd.o dlacpy.o dladiv.o dlaebz.o dlae2.o dlaev2.o
>>> dlaexc.o dlagtf.o dlagts.o dlag2.o dlahqr.o dlahr2.o dlaisnan.o
>>> dlaln2.o dlamch.o dlaneg.o dlange.o dlanhs.o dlanst.o dlansy.o dlanv2.o
>>> dlapy2.o dlapy3.o dlaqr0.o dlaqr1.o dlaqr2.o dlaqr3.o dlaq
>>> r4.o dlaqr5.o dlarf.o dlarfb.o dlarfg.o dlarft.o dlarfx.o dlarnv.o
>>> dlarra.o dlarrb.o dlarrc.o dlarrd.o dlarre.o dlarrf.o dlarrj.o
>>> dlarrk.o dlarrr.o dlarrv.o dlartg.o dlartv.o dlaruv.o dlar1v.o dlas2.o
>>> dlascl.o dlaset.o dlasq1.o dlasq2.o dlasq3.o dlasq4.o dlasq
>>> 5.o dlasq6.o dlasr.o dlasrt.o dlaswp.o dlassq.o dlasv2.o dlasyf.o
>>> dlasy2.o dlatrd.o dorg2l.o dorg2r.o dorgbr.o dorghr.o dorglq.o d
>>> orgl2.o dorgql.o dorgqr.o dorgtr.o dorm2r.o dormbr.o dormhr.o dorml2.o
>>> dormlq.o dormql.o dormqr.o dormtr.o dorm2l.o dpotf2.o dpotr
>>> f.o dpotrs.o dstebz.o dstein.o dstemr.o dsteqr.o dsterf.o dsyev.o
>>> dsyevr.o dsyevx.o dsytd2.o dsytf2.o dsytrd.o dsytrf.o dsytri.o d
>>> tgevc.o dtrevc.o dtrexc.o dtrti2.o dtrtri.o dtrtrs.o ieeeck.o iladlc.o
>>> iladlr.o ilaenv.o iparmq.o sgetf2.o sgetrf.o slamch.o slasw
>>> p.o zgetf2.o zgetrf.o zlacgv.o zlacpy.o zlaev2.o zlaswp.o zpotf2.o
>>> zrot.o zsymv.o zsyr.o zsytri.o
>>> *./../../libtool: line 5910: lib: command not found*
>>> make[1]: *** [libcoinlapack.la] Error 127
>>> make[1]: Leaving directory `/home/john/Ipopt-3.11.3/ThirdParty/Lapack'
>>> make: *** [all-recursive] Error 1
>>>
>>>
>>>
>>>
>>> On 15/08/13 11:01, Tony Kelman wrote:
>>>> John,
>>>> I’ve seen that error when trying to use the rubenvb versions of
>>>> MinGW-w64. As you found, it’s a bad interaction with configure trying
>>>> to extract the libraries needed to link Fortran code, from the verbose
>>>> compiler output which includes the entire GCC configure line used by
>>>> rubenvb, particularly the --with-host-libstdcxx='-static -lstdc++ -lm'
>>>> part. I contacted him on Sourceforge over a year ago asking if he
>>>> could just add a space between -lm and the apostrophe, which I believe
>>>> would fix the problem, but evidently he never made that change.
>>>> Updating the autotools version used by Ipopt might also fix the issue,
>>>> but that’s easier said than done and I don’t think Stefan has had time
>>>> to finish that process.
>>>> If you don’t need GCC 4.8, I recommend using TDM-GCC
>>>> (http://tdm-gcc.tdragon.net/) instead. It’s been the most reliable
>>>> MinGW-w64 distribution that I’ve been able to find, for the purposes
>>>> of building Ipopt.
>>>> -Tony
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Ipopt mailing list
>>> Ipopt at list.coin-or.org
>>> http://list.coin-or.org/mailman/listinfo/ipopt
>>>
>>
>



More information about the Ipopt mailing list