Link ipopt and Open3D in the same project cause segmentation fault

[Ultcrt]

Hello,

I am trying to use ipopt and Open3D together in the same C++ project (Open3D is a 3D data processing library).

Everything worked fine when I ran ipopt or Open3D independently.

But after I linked the two together, I got segment fault.

Once I remove Open3D from target_link_libraries in CMake file, segment fault disappeared.

My CMake file is like this:

cmake_minimum_required(VERSION 3.26)
project(link_test)

set(CMAKE_CXX_STANDARD 17)

find_package(Open3D REQUIRED)

add_executable(link_test main.cpp myTNLP.cpp myTNLP.h)

target_link_libraries(link_test PRIVATE ipopt Open3D::Open3D)   # Segment fault occurs
# target_link_libraries(link_test PRIVATE ipopt)   # Segment fault disappears

The test code I used in main.cpp, myTNLP.cpp and myTNLP.h is the same as /examples/Cpp_example. Open3D is only linked but never used in the test code.

And here is the debug info when segment fault occurs (IpBlas.cpp:252):

I have no ideal about what causes this problem nor how to fix this, could anyone help me with this please?

Thank you

[svigerske]

Since the error comes up in MKL, I would guess that by linking to Open3D, you like to an incompatible MKL library. For example, Ipopt may expect a Blas library that uses 32bit integers, while the MKL library used here uses 64bit integers. (Such mismatch sometimes come up when using Ipopt from Matlab.)

Looking at the actual linker commands may give some more information. Maybe using a static version of Blas+Lapack/MKL when building Ipopt could help.

[Ultcrt]

Thanks for your advice!

The problem is indeed caused by Open3D uses 64bit integers.

I followed your advice and tried to building libipopt.so with static version of OpenBLAS / MKL.

Using OpenBLAS

I built libipopt.so with static version of OpenBLAS with following flag:

--with-lapack-lflags="-Wl,--no-as-needed /opt/OpenBLAS/lib/libopenblas.so -lm"

Using this new libipopt.so, the segment fault disapeared. :)

Using MKL

I also tried to build ipopt with static version of MKL. I used link line from MKL link line advisor:

--with-lapack-lflags="-Wl,--start-group \
${MKLROOT}/lib/intel64/libmkl_intel_lp64.a \
${MKLROOT}/lib/intel64/libmkl_gnu_thread.a \
${MKLROOT}/lib/intel64/libmkl_core.a -Wl,--end-group -lgomp -lpthread -lm -ldl"

libipopt.so is successfully generated using flag above. But when I compile the test code, linker throws tons of undefined reference errors:

/usr/bin/ld: ../src/.libs/libipopt.so: undefined reference to `mkl_pds_lp64_ch_blkldlslvs_ooc_pardiso'
/usr/bin/ld: ../src/.libs/libipopt.so: undefined reference to `mkl_blas_lp64_zscal'
...
/usr/bin/ld: ../src/.libs/libipopt.so: undefined reference to `mkl_pds_pds_her_indef_bk_fct_slv_cmplx'
/usr/bin/ld: ../src/.libs/libipopt.so: undefined reference to `mkl_pds_lp64_sp_pds_copy_a2l_value_omp_cmplx'

Then I noticed that Open3D uses a merged mkl static lib. If I also link the merged lib when building ipopt, the undefined reference errors will disappear.
So I tried to generated a merged mkl lib by my self with following command (the same code used by Open3D):

ar x /usr/lib/x86_64-linux-gnu/libmkl_intel_lp64.a
ar x /usr/lib/x86_64-linux-gnu/libmkl_gnu_thread.a
ar x /usr/lib/x86_64-linux-gnu/libmkl_core.a

find -name "*.o" | xargs ar -qc ./lib/libmkl_merged.a

Then I use this merged lib to build libipopt.so with following flag:

--with-lapack-lflags="-Wl,--no-as-needed /path/to/merged/lib/libmkl_merged.a -lgomp -lpthread -lm -ldl"

With this new libipopt.so, Open3D and ipopt can be linked together.

But I'm still not sure why using link line from MKL link line advisor will leads to undefined reference error and why using a merged lib could solve the problem? I would appreciate it if anyone can give me a hint.

[svigerske]

That's a problem with Ipopt's buildsystem. Somewhere in libtool (if I remember right), it reorganizes the linker flags and the .a files are no longer in between -Wl,---start-group and --Wl,--end-group. However, this is necessary since there are circular dependencies between these .a files.
Putting everything into a single .a file works around this.

[Ultcrt]

Thank you! I should pay more attention to the actual linker commands like you said.

This problem is indeed caused by libtool places flags at a different order in linker command. If using following --with-lapack-lflags flag to build ipopt:

--with-lapack-lflags="-Wl,--no-as-needed -Wl,--start-group \
libmkl_intel_lp64.a \
libmkl_gnu_thread.a \ 
libmkl_core.a -Wl,--end-group -lgomp -lpthread -lm -ldl"

the actual link command would look like this:

g++ ... libmkl_intel_lp64.a libmkl_gnu_thread.a libmkl_core.a -lgomp -lpthread -lm -ldl \
-Wl,--no-as-needed -Wl,--start-group -Wl,--end-group ...

As the above command shows, the static libs are put outside of -Wl,--start-group and --Wl,--end-group. That is why -Wl,--start-group and --Wl,--end-group flags are not working.

There is a heck to fix this, change the --with-lapack-lflags into this (use comma to connect flags):

--with-lapack-lflags="-Wl,--no-as-needed -Wl,--start-group,\
${MKLROOT}/lib/intel64/libmkl_intel_lp64.a,\
${MKLROOT}/lib/intel64/libmkl_gnu_thread.a,\
${MKLROOT}/lib/intel64/libmkl_core.a,--end-group \
-lgomp -lpthread -lm -ldl"

Now, libtool can pass flags to linker at the correct order and circular dependencies is resolved. Using --with-lapack-lflags above can build a usable libipopt.so with static mkl libs.

More information about this reordering behavior of libtool can be found here.

Closing this discussion as resolved. Thanks again!

[svigerske]

Thank you, that's a nice workaround I hadn't thought about.