Linking fails despite correct pkg-config flags

[fsimonis]

Problem Description

When installing precice 2.0.0 in /usr/local/ and using ldd as a linker., then running ./Allwmake fails due to missing symbols Setting the LD_LIBRARY_PATH fixes this issue.

Potential Solution

Forward the necessary flags to the linker invocation.

[quentonwu]

To elaborate, run the following command:"export LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu:$LD_LIBRARY_PATH" in the same terminal window before running ./Allwmake should allow a successful build source:http://penguinitis.g1.xrea.com/study/preCICE/OpenFOAM_CalculiX_FSI/OpenFOAM_CalculiX_FSI.html

[fsimonis]

@quentonwu Thank you for the comment! The (your?) blog post mentions preCICE version 1.3.0. Which version are you currently using?

This issue should be fixed with https://github.com/precice/precice/pull/686 which was released with preCICE 2.1.0. @MakisH Can you confirm this?

[quentonwu]

@fsimonis No, the blog post isn't mine, I just came across it after searching the error online. I am using the latest preCICE build(2.1.1) on Ubuntu along with OpenFOAM 2012

[MakisH]

This issue should be fixed with precice/precice#686 which was released with preCICE 2.1.0. @MakisH Can you confirm this?

It is not very easy for me to test this at the moment, but I understand from @quentonwu's comment that it is not fixed.

[quentonwu]

I just tried to build the CalculiX adapter and I had the exact same problem as well. Could it be something from my end? Or have the library changed something? Apologises for my uncertainness, I don't have much experience building software.

[MakisH]

@fsimonis @quentonwu do you still have the same issue with v1.1.0?

[fsimonis]

We could use build the vm with precice installed in /usr/local (default).

[MakisH]

We could use build the vm with precice installed in /usr/local (default).

Please open an issue in the vm for that, explaining the motivation.

[davidscn]

I stumbled across the same issue and dug a bit deeper. I think the problem here is more with our building script. We use the following lines to 'detect' success or failure of the linking step in our script:

https://github.com/precice/openfoam-adapter/blob/25f9798da00eb9ef38d96109fb2dab3eaec310a2/Allwmake#L109-L118

However, gcc and ldd are actually happy when passing the build/linking instructions manually via the command line. Using pkg-config --libs (as we do) provides the necessary flags to the linker. The problem is that ldd checks whether all runtime dependencies are found, which is different from the linker knowledge via pkg-config. This is somewhat comparable to a CMake build, where building and running (in the build directory) succeeds, but after installation running the executable fails if dependencies are not discoverable. Note that CMake does not emit any error in such a case.

In principle, having dependencies discoverable is a responsibility of the user/ the installed dependencies and different from the building and linking step here. So, we should maybe try to improve the check used to raise an error for linking problems.

[MakisH]

The problem is that ldd checks whether all runtime dependencies are found, which is different from the linker knowledge via pkg-config. This is somewhat comparable to a CMake build, where building and running (in the build directory) succeeds, but after installation running the executable fails if dependencies are not discoverable. Note that CMake does not emit any error in such a case.

I am not sure what the right approach is here, and this check predates the support for pkg-config. But the intention with asking ldd was to check that everything will work even building, when loading the adapter.

Do we need an additional check, a different check, or are we missing the pkg-config flags somewhere?

[davidscn]

But the intention with asking ldd was to check that everything will work even building, when loading the adapter.

Do we need an additional check, a different check, or are we missing the pkg-config flags somewhere?

Long story short:

What we check right now:

• compiling the library
• linking the library
• loading the library

What we should check (in my opinion):

• compiling the library
• linking the library

pkg-config (and the way we use it) is sufficient to handle the latter, but not the former. Hence, we would need a different check.

[MakisH]

@fsimonis @davidscn I am not sure I understand the issue itself and what we can/should do about it.

What I understand is that "the adapter asks ldd if it can resolve all symbols, but this is not the right approach, because ?the system? has additional ways to resolve the symbols compared to ldd".

I just tried installing preCICE v2.5.0, OpenFOAM v2306, and the adapter version v1.2.3 on a clean Ubuntu 22.04 system. I built preCICE from source and make install-ed it to /usr/local. What happens:

• pkg-config finds preCICE
• The adapter's Allwmake finds preCICE via pkg-config
• At the end of Allwmake, ldd reports that there were undefined symbols (preCICE)
• Trying to run an OpenFOAM simulation, OpenFOAM cannot load the adapter, because it cannot resolve all symbols (Cannot find libprecice.so.2).
• OpenFOAM continues running without the adapter, which may be misleading (this is an OpenFOAM bug/feature).

In my view, the check in the adapter is working correctly: it gives a heads-up to the user that OpenFOAM will also not be able to use the adapter.

What I could imagine being wrong here is that OpenFOAM does not use pkg-config for resolving dependencies.

Do I misunderstand something? What would you suggest as next step/check?

edit: If OpenFOAM would complain about not finding the adapter and exit, I would be happy to completely remove this check from our Allwmake script. But with the current way things are, I find it crucial to give an error to the user, as this may easily lead to many issues later on (completely wrong results, the user tries to understand what went wrong in the config, support requests pop up, etc).