[Ipopt] Created shared objects for Ipopt using the Intel compilers

[Greg Kopff]

> On 22 Jul 2015, at 7:58 pm, Stefan Vigerske <stefan at math.hu-berlin.de> wrote:
> 
> Hi,
> 
> the AC_COIN_PROG_F77 macro has lines
> 
> # correct the LD variable if we use the intel fortran compiler in windows
> case "$F77" in
>  ifort* | */ifort* | IFORT* | */IFORT*)
>    LD=link
>    ;;
> esac
> 
> 
> Obviously, the check whether one is on windows is missing here.
> (For the C/C++ compiler there are similar lines, but the names of the Intel C/C++ compilers on Windows is different from the Linux variants, so that is working fine.)
> 
> I can look into a fix for this.
> In the meanwhile, you could edit the configure scripts and just remove these lines. But you might have to do this in the main configure and the ones in the subdirectories.

Hi Stefan & Tony.

======================
The good
======================

I’ve commented out all the cases where the LD variable is corrected.  My build now reports that it is going to build shared objects. :-)  Thank you.

For reference, this is what config.log now shows:

configure:8770: checking whether the icc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries
configure:9728: result: yes
configure:9749: checking whether -lc should be explicitly linked in
configure:9754: icc -c -O3 -ip -mp1  -DNDEBUG     conftest.c >&5
configure:9757: $? = 0
configure:9772: icc -shared conftest.o  -v -Wl,-soname -Wl,conftest -o conftest 2\>\&1 \| grep  -lc  \>/dev/null 2\>\&1
configure:9775: $? = 0
configure:9787: result: no
configure:9795: checking dynamic linker characteristics
configure:10383: result: GNU/Linux ld.so
configure:10392: checking how to hardcode library paths into programs
configure:10417: result: immediate
configure:10431: checking whether stripping libraries is possible
configure:10436: result: yes
configure:11270: checking if libtool supports shared libraries
configure:11272: result: yes
configure:11275: checking whether to build shared libraries
configure:11296: result: yes
configure:11299: checking whether to build static libraries
configure:11303: result: no
configure:11395: creating libtool
configure:11983: checking for ld used by icpc
configure:12050: result: /usr/bin/ld -m elf_x86_64
configure:12059: checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld
configure:12074: result: yes
configure:12125: checking whether the icpc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries
configure:13063: result: yes
configure:13085: icpc -c -O3 -ip -mp1  -DNDEBUG     conftest.cpp >&5
configure:13088: $? = 0
configure:13207: checking for icpc option to produce PIC
configure:13481: result: -fPIC
configure:13489: checking if icpc PIC flag -fPIC works
configure:13501: icpc -c -O3 -ip -mp1  -DNDEBUG     -fPIC -DPIC conftest.cpp >&5
configure:13505: $? = 0
configure:13524: result: yes

======================
The bad
======================

I have, however, seem to come unstuck during the compilation now (whereas everything compiled without issue previously) …  I get:

icpc -DHAVE_CONFIG_H -I. -I. -I../../../src/Common -I./../../Common -I./../../LinAlg -I./../../LinAlg/TMatrices -I./.. -I./../../Interfaces -I./../../contrib/CGPenalty -I/home/greg/ipopt-3.11.8-intel/include/coin/ThirdParty -O3 -ip -mp1 -DNDEBUG -DIPOPT_BUILD -MT IpMumpsSolverInterface.lo -MD -MP -MF .deps/IpMumpsSolverInterface.Tpo -c IpMumpsSolverInterface.cpp  -fPIC -DPIC -o .libs/IpMumpsSolverInterface.o
IpMumpsSolverInterface.cpp(17): catastrophic error: cannot open source file "mpi.h"
  #include "mpi.h"
                  ^

compilation aborted for IpMumpsSolverInterface.cpp (code 4)
Makefile:554: recipe for target 'IpMumpsSolverInterface.lo' failed
make[3]: *** [IpMumpsSolverInterface.lo] Error 1

I’m going to make sure I’ve not inadvertently screwed something over - I’m going to start from scratch using a freshly untarred source tree.  But while I have your attention, any idea why compilation has suddenly failed?  :-)  (Is it a reasonable guess that the culprit is that we’re now using different compilation switches having switched to shared object mode? Arguing against myself, we’re compiling here, not linking … Apart from things like -fPIC I wouldn’t have thought it much different …  Hmm… )

Once again, thanks to both of you for your help.

Kindest regards,

—
Greg.