Undefined symbols while builidng OpenFoam adapter

Official adapters and tutorials
1

Hi. I have issues building the OpenFOAM adapter on Fedora 34. I downloaded the 2106 compatible version. The building stops with this message:

Everything looks fine in wmake.log.
=== ERROR: Building completed with linking problems: there were undefined symbols. ===
Possible causes:
Is preCICE discoverable at runtime? Check the content of ADAPTER_PKG_CONFIG_LIBS above.
See wmake.log and ldd.log for more details.

I installed preCICE 2.3.0 in a non-standard path but I included it in my LD_LIBRARY_PATH. I’m attaching the ldd.log and wmake.log files.

Thanks!
ldd.log (10.3 KB)
wmake.log (39.1 KB)

2

Are you sure that your LD_LIBRARY_PATH is set to the correct value? Are you able to compile other code with preCICE, for example, the solver dummies of preCICE?

1 Like
3

Hi Alex. Yes, I was able to compile the solver dummies (I tried C++ and Python). There were no problems with them.
In trying to fix my problem, I also compiled again OpenFOAM, since the later version that I had was compiled with a different g++ version (different from the g++ version I used to compile the OpenFOAM adapter). Now they both are compiled with the same g++ version. But, sadly, this didn’t resolve my problem.

4

Do you still get the same error message? I assume you also checked the ADAPTER_PKG_CONFIG_LIBS variable that is in the error message you have in the first post?

1 Like
5

Yes I still get the same message. My variable points to:

$ echo $ADAPTER_PKG_CONFIG_LIBS
$ -L/home/hgcastro/precice/lib64 -lprecice

which is where I have libprecice.so

6

This sounds a bit mysterious. What is the output of

nm -D /home/hgcastro/precice/lib64/libprecice.so | grep precice15SolverInterface

This will you a longer cryptic output looking similar to this (but more output):

000000000036e830 T _ZN7precice15SolverInterface10initializeEv
000000000036e9f0 T _ZN7precice15SolverInterface11setMeshEdgeEiii
000000000036ea20 T _ZN7precice15SolverInterface11setMeshQuadEiiiii
000000000036ea40 T _ZN7precice15SolverInterface13mapReadDataToEi
000000000036e9a0 T _ZN7precice15SolverInterface13setMeshVertexEiPKd
000000000036e840 T _ZN7precice15SolverInterface14initializeDataEv
000000000036ea00 T _ZN7precice15SolverInterface15setMeshTriangleEiiii
000000000036e9c0 T _ZN7precice15SolverInterface15setMeshVerticesEiiPKdPi
000000000036ea90 T _ZN7precice15SolverInterface15writeScalarDataEiid
000000000036ea70 T _ZN7precice15SolverInterface15writeVectorDataEiiPKd
000000000036ea50 T _ZN7precice15SolverInterface16mapWriteDataFromEi
000000000036e8d0 T _ZN7precice15SolverInterface19markActionFulfilledERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
000000000036ea30 T _ZN7precice15SolverInterface20setMeshQuadWithEdgesEiiiii
000000000036ea80 T _ZN7precice15SolverInterface20writeBlockScalarDataEiiPKiPKd
000000000036ea60 T _ZN7precice15SolverInterface20writeBlockVectorDataEiiPKiPKd
000000000036ea10 T _ZN7precice15SolverInterface24setMeshTriangleWithEdgesEiiii
000000000036e850 T _ZN7precice15SolverInterface7advanceEd
000000000036e860 T _ZN7precice15SolverInterface8finalizeEv

It would be interesting to see whether the missing symbol _ZN7precice15SolverInterfaceC1ERKSsS2_ii (as mentionde in the ldd.log) is indeed missing.

Currently, my best guess would be that the compilers are still somehow mixed up as in this older forum post.

1 Like
7

The output is the following:

000000000035dcc0 T _ZN7precice15SolverInterface10initializeEv
000000000035de50 T _ZN7precice15SolverInterface11setMeshEdgeEiii
000000000035de80 T _ZN7precice15SolverInterface11setMeshQuadEiiiii
000000000035dea0 T _ZN7precice15SolverInterface13mapReadDataToEi
000000000035de00 T _ZN7precice15SolverInterface13setMeshVertexEiPKd
000000000035dcd0 T _ZN7precice15SolverInterface14initializeDataEv
000000000035de60 T _ZN7precice15SolverInterface15setMeshTriangleEiiii
000000000035de20 T _ZN7precice15SolverInterface15setMeshVerticesEiiPKdPi
000000000035def0 T _ZN7precice15SolverInterface15writeScalarDataEiid
000000000035ded0 T _ZN7precice15SolverInterface15writeVectorDataEiiPKd
000000000035deb0 T _ZN7precice15SolverInterface16mapWriteDataFromEi
000000000035dd60 T _ZN7precice15SolverInterface19markActionFulfilledERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
000000000035de90 T _ZN7precice15SolverInterface20setMeshQuadWithEdgesEiiiii
000000000035dee0 T _ZN7precice15SolverInterface20writeBlockScalarDataEiiPKiPKd
000000000035dec0 T _ZN7precice15SolverInterface20writeBlockVectorDataEiiPKiPKd
000000000035de70 T _ZN7precice15SolverInterface24setMeshTriangleWithEdgesEiiii
000000000035dce0 T _ZN7precice15SolverInterface7advanceEd
000000000035dcf0 T _ZN7precice15SolverInterface8finalizeEv
000000000035da20 T _ZN7precice15SolverInterfaceC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES8_ii
000000000035db50 T _ZN7precice15SolverInterfaceC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES8_iiPv
000000000035da20 T _ZN7precice15SolverInterfaceC2ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES8_ii
000000000035db50 T _ZN7precice15SolverInterfaceC2ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES8_iiPv
000000000035dc90 T _ZN7precice15SolverInterfaceD1Ev
000000000035dc90 T _ZN7precice15SolverInterfaceD2Ev
000000000035dd90 T _ZNK7precice15SolverInterface10getMeshIDsEv
000000000035dd00 T _ZNK7precice15SolverInterface13getDimensionsEv
000000000035df30 T _ZNK7precice15SolverInterface14readScalarDataEiiRd
000000000035df10 T _ZNK7precice15SolverInterface14readVectorDataEiiPd
000000000035de30 T _ZNK7precice15SolverInterface15getMeshVerticesEiiPKiPd
000000000035dd50 T _ZNK7precice15SolverInterface16isActionRequiredERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
000000000035de10 T _ZNK7precice15SolverInterface17getMeshVertexSizeEi
000000000035dd10 T _ZNK7precice15SolverInterface17isCouplingOngoingEv
000000000035dd20 T _ZNK7precice15SolverInterface19isReadDataAvailableEv
000000000035dd30 T _ZNK7precice15SolverInterface19isWriteDataRequiredEd
000000000035df20 T _ZNK7precice15SolverInterface19readBlockScalarDataEiiPKiPd
000000000035df00 T _ZNK7precice15SolverInterface19readBlockVectorDataEiiPKiPd
000000000035df40 T _ZNK7precice15SolverInterface19setMeshAccessRegionEiPKd
000000000035dd40 T _ZNK7precice15SolverInterface20isTimeWindowCompleteEv
000000000035df50 T _ZNK7precice15SolverInterface21getMeshVerticesAndIDsEiiPiPd
000000000035ddf0 T _ZNK7precice15SolverInterface22hasToEvaluateFineModelEv
000000000035ddb0 T _ZNK7precice15SolverInterface26isMeshConnectivityRequiredEi
000000000035dde0 T _ZNK7precice15SolverInterface27hasToEvaluateSurrogateModelEv
000000000035de40 T _ZNK7precice15SolverInterface29getMeshVertexIDsFromPositionsEiiPKdPi
000000000035ddc0 T _ZNK7precice15SolverInterface7hasDataERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEi
000000000035dd70 T _ZNK7precice15SolverInterface7hasMeshERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
000000000035ddd0 T _ZNK7precice15SolverInterface9getDataIDERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEi
000000000035dd80 T _ZNK7precice15SolverInterface9getMeshIDERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
00000000003f4a30 W _ZNSt10unique_ptrIN7precice15SolverInterfaceESt14default_deleteIS1_EED1Ev
00000000003f4a30 W _ZNSt10unique_ptrIN7precice15SolverInterfaceESt14default_deleteIS1_EED2Ev

I will take a look at the post you mentioned.

8

In you output the symbol _ZN7precice15SolverInterfaceC1ERKSsS2_ii is indeed missing. Maybe it would be easiest to recompile preCICE once (with the same compiler as OpenFOAM) and then check the list of symbols again?

1 Like
9

I compiled preCICE again with the same OpenFOAM compiler. Sadly, I obtained the same error message. I checked the symbols and they are the same as before. Should I try a previous version of the OF adapter?

10

I am not an expert for the OpenFOAM adapter, but I guess trying an older version would not hurt.

However, I am still stuck on possibility of a compiler/library mismatch. You could check the compiler used for preCICE with

objdump -s --section .comment libprecice.so

which prints the following for me

libprecice.so:     file format elf64-x86-64

Contents of section .comment:
 0000 4743433a 20285562 756e7475 20392e33  GCC: (Ubuntu 9.3
 0010 2e302d31 37756275 6e747531 7e32302e  .0-17ubuntu1~20.
 0020 30342920 392e332e 3000               04) 9.3.0.

In my case the GCC compiler 9.3.0 was used. You could run the objdump -s --section .comment COMPILEDCODE command also on your OpenFOAM libraries or executables and check what compiler it prints there. Would you maybe also have some output of the OpenFOAM build process that show information what compilers/libraries where used?

1 Like
11

Thx for the tip Alex. I checked the compiler:

objdump -s --section .comment libprecice.so

which prints

libprecice.so:     file format elf64-x86-64

Contents of section .comment:
 0000 4743433a 2028474e 55292031 312e322e  GCC: (GNU) 11.2.
 0010 31203230 32313037 32382028 52656420  1 20210728 (Red 
 0020 48617420 31312e32 2e312d31 2900      Hat 11.2.1-1).

and then

objdump -s --section .comment libfiniteVolume.so

which gives

libfiniteVolume.so:     file format elf64-x86-64

Contents of section .comment:
 0000 4743433a 2028474e 55292031 312e322e  GCC: (GNU) 11.2.
 0010 31203230 32313037 32382028 52656420  1 20210728 (Red 
 0020 48617420 31312e32 2e312d31 2900      Hat 11.2.1-1).

It appears to be the same info.

12

What a mystery. Maybe @Makis has any further ideas?

13

Wait. libfiniteVolume.so is a library. Now I tried the same thing with an OpenFOAM solver:

objdump -s --section .comment /OpenFOAM-v2106/platforms/linux64GccDPInt32Opt/bin/pimpleFoam

which prints

/OpenFOAM-v2106/platforms/linux64GccDPInt32Opt/bin/pimpleFoam:     file format elf64-x86-64

Contents of section .comment:
 0000 4743433a 2028474e 55292031 312e312e  GCC: (GNU) 11.1.
 0010 31203230 32313035 33312028 52656420  1 20210531 (Red 
 0020 48617420 31312e31 2e312d33 29004743  Hat 11.1.1-3).GC
 0030 433a2028 474e5529 2031312e 322e3120  C: (GNU) 11.2.1 
 0040 32303231 30373238 20285265 64204861  20210728 (Red Ha
 0050 74203131 2e322e31 2d312900           t 11.2.1-1).

I can see some differences now. Could this be the reason for the mismatch?

14

I guess it could be a reason. I don’t have full insight how the compilation process of OpenFOAM and the OpenFOAM adapter is working. It is puzzling though that different compilers have been used for different parts of the OpenFOAM. Especially as it seems to use the correct version for the C: part.

Did you compile OpenFOAM yourself? If yes, maybe your compiler was updated since OpenFOAM has been compiled the first time? You could try recompiling OpenFOAM and see if this changes anything.

1 Like
15

I did compile it myself. I’m not sure why this is happening. I will recompile it and I’ll get back to you ASAP.

16

No, please stick to the latest one, the version of the adapter should not be related and using an older version could only bring more incompatibility issues.

I wish I had… :confused:

I don’t think that mixing different minor versions of the same compiler could be an issue.

It hurts every time I read that you are recompiling OpenFOAM :see_no_evil:. I am so sorry you are going through this…

Are you really compiling manually, or using a package manager? Do the RPM packages of OpenFOAM not work for you? redhat · Wiki · Development / openfoam · GitLab (I have never tried them)

1 Like
17

I was just digging a bit more to understand what is going on by demangling the names in the library.

This is a function that is in your compiled preCICE library:

$ c++filt _ZN7precice15SolverInterfaceC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES8_ii
precice::SolverInterface::SolverInterface(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int, int)

This is the function the OpenFOAM adapter tries to find during compilation/linking

$ c++filt _ZN7precice15SolverInterfaceC1ERKSsS2_ii
precice::SolverInterface::SolverInterface(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int, int)

So the difference is actually (top is what is in the preCICE library, bottom is what is searched during adapter compilation)

- precice::SolverInterface::SolverInterface(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int, int)
+ precice::SolverInterface::SolverInterface(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int, int)

that the __cxx11 part is missing.

If I google for this I end up with information about the dual ABI of GCC and there are also some posts like this one or this one on Stack Overflow. The posts are all fairly old though.

Has there been any change in ABI definitions or how compilers work with that? Could this be a Fedora specific thing? Could it be that the adapter build system picks up something wrong?!

1 Like
18

Hi Gerasimos. Yes, indeed compiling OpenFOAM from source could be a headache. Anyway, I followed your hint about RPM packages (to see if that could work). Once installed, this is what I have:

$ objdump -s --section .comment /usr/lib/openfoam/openfoam2106/platforms/linux64GccDPInt32Opt/bin/pimpleFoam

/usr/lib/openfoam/openfoam2106/platforms/linux64GccDPInt32Opt/bin/pimpleFoam:     file format elf64-x86-64

Contents of section .comment:
 0000 4743433a 2028474e 55292031 312e312e  GCC: (GNU) 11.1.
 0010 31203230 32313035 33312028 52656420  1 20210531 (Red 
 0020 48617420 31312e31 2e312d33 29004743  Hat 11.1.1-3).GC
 0030 433a2028 474e5529 2031312e 322e3120  C: (GNU) 11.2.1 
 0040 32303231 30373238 20285265 64204861  20210728 (Red Ha
 0050 74203131 2e322e31 2d312900           t 11.2.1-1).

As you can see, the apparently mixed versions of the compiler persist.

19

Thank you for this info Alex. I will look into that. Maybe it is something specific to Fedora.

20

There was such a change, but much earlier, around GCC 4 or 5. I would not expect this to be an issue with GCC 11.

I don’t think that the mixed versions is an issue. I assume you can still not build the adapter correctly, right?

What exactly is currently installed on your system at the moment in terms of OpenFOAM and compilers?

1 Like