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

[Tony Kelman]

Does it help at all if you configure with LD=ld ? I think linking with 
"link" should only be happening when you're building with the Intel 
toolchain on Windows, but something might be going down the wrong code path 
for you. I think the Intel toolchain on unix should be using the normal ld 
linker?

-Tony


-----Original Message----- 
From: Greg Kopff
Sent: Wednesday, July 22, 2015 12:11 AM
To: Tony Kelman
Cc: ipopt at list.coin-or.org
Subject: Re: [Ipopt] Created shared objects for Ipopt using the Intel 
compilers

Hello again Tony.

When I compile with GCC, the command used to test the shared library support 
is reported as:

  configure:8764: checking whether the gcc linker (/usr/bin/ld -m 
elf_x86_64) supports shared libraries

… but, as per my earlier email when using the Intel compilers it seems to 
think the linker command is ‘link’.

Do you know how to control/influence the linker command?

Kindest regards,

—
Greg.



On 22 Jul 2015, at 5:01 pm, Greg Kopff <greg at q10stats.com> wrote:


Hi Tony.



On 22 Jul 2015, at 4:29 pm, Tony Kelman <kelman at berkeley.edu> wrote:
It could get pretty messy to determine exactly where that's coming from. You 
should be able to find some evidence in config.log, either in the top-level 
build directory or one level down in the Ipopt subfolder, search for 
something like "whether to enable shared libraries" or "whether to build 
shared libraries." There might be some logic either in one of the 
configure.ac, or BuildTools/coin.m4, or libtool files that could be 
disabling shared libraries when using the Intel compilers? I don't have a 
lot of experience using the Intel compilers but I've used MKL a few times 
before and have done more than my share of debugging strange configure/build 
issues. It might help if you could upload the config.log and libtool files 
(both top-level and under Ipopt subfolder) to somewhere like pastebin or 
gist.github.com, so those of us who know what to look for could try skimming 
through them.


Okay - I think I’ve found the relevant section.  It’s as you expected:

configure:8764: checking whether the icc linker (link -m elf_x86_64) 
supports shared libraries
configure:9722: result: no
configure:9789: checking dynamic linker characteristics
configure:10377: result: GNU/Linux ld.so
configure:10386: checking how to hardcode library paths into programs
configure:10411: result: unsupported
configure:10425: checking whether stripping libraries is possible
configure:10430: result: yes
configure:11264: checking if libtool supports shared libraries
configure:11266: result: no
configure:11269: checking whether to build shared libraries
configure:11290: result: no
configure:11293: checking whether to build static libraries
configure:11297: result: yes
configure:11389: creating libtool

Here’s the whole thing: https://gist.github.com/gkopff/a68c61883eee3191d447

If you have any ideas as to _why_ configure thinks that the icc linker doesn’t 
support shared libraries, I’d love to know. :)

Thanks for your help so far.

Kindest regards,

—
Greg.