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

Thu Aug 15 06:24:05 EDT 2013

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).

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?

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
>>
>