Problem linking adapted CalculiX against yaml-cpp (macOS)

Dear preCICE community,

I tried to build the adapted CalculiX on macOS. I successfully built CalculiX itself, but for some bizarre reason, it complains that it cannot link with yaml-cpp.

Here’s the output of the command:

mpif90 -fopenmp -Wall -O3 -o bin/ccx_preCICE bin/ccx_2.20.o bin/ccx_2.20.a /Volumes/SourceCode/software/CalculiX/ccx_2.20/ThirdParty/SPOOLES.2.2/spooles.a /Volumes/SourceCode/software/CalculiX/ccx_2.20/ThirdParty/SPOOLES.2.2/MT/src/spoolesMT.a -L/Users/ali/.local/lib -lprecice `pkg-config --libs yaml-cpp` -lstdc++ -L/opt/homebrew/Cellar/arpack/3.9.1_1/lib -larpack -llapack -lblas -lpthread -lm -lc
Undefined symbols for architecture arm64:
  "YAML::detail::node_data::set_scalar(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>> const&)", referenced from:
      YAML::detail::node& YAML::detail::node::get<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>>(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>> const&, std::shared_ptr<YAML::detail::memory_holder>) in ccx_2.20.a[1123](ConfigReader.o)
      YAML::detail::node& YAML::detail::node_data::get<int>(int const&, std::shared_ptr<YAML::detail::memory_holder>) in ccx_2.20.a[1123](ConfigReader.o)
  "YAML::detail::node_data::convert_to_map(std::shared_ptr<YAML::detail::memory_holder>)", referenced from:
      YAML::detail::node& YAML::detail::node::get<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>>(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>> const&, std::shared_ptr<YAML::detail::memory_holder>) in ccx_2.20.a[1123](ConfigReader.o)
      YAML::detail::node& YAML::detail::node_data::get<int>(int const&, std::shared_ptr<YAML::detail::memory_holder>) in ccx_2.20.a[1123](ConfigReader.o)
  "YAML::LoadFile(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>> const&)", referenced from:
      _ConfigReader_Read in ccx_2.20.a[1123](ConfigReader.o)
ld: symbol(s) not found for architecture arm64
collect2: error: ld returned 1 exit status

I tried using two different versions of yaml-cpp, but neither worked. The path to the header files and libraries was correct, as determined by pkg-config --libs yaml-cpp. Using LSP, I can jump to the declarations in the header files. Also, the shared library contains all these symbols, which I confirmed using nm -C /path/to/lib | grep symbolName. I also tried to put the link flag -lyaml-cpp at different orders, but it too didn’t help.

At this point, I’m not sure what I’m missing. I would greatly appreciate it if anyone could help me identify the issue.

System and tools information:

  • CalculiX: 2.20 (Using the one mentioned in the preCICE documentation)
  • Adapted CalculiX: The one that is currently mentioned in the docs (probably 2.20)
  • preCICE: v3.1.2
  • Operating system: macOS Sonoma 14.7.1
  • Installation method: Compilation from source
  • Dependency versions:
    • Homebrew GCC 14.2.0
    • Homebrew Clang 19.1.2
    • Open MPI: stable 5.0.6
    • PETSc: stable 3.22.2
    • yaml-cpp:
      • 0.8.0 (Homebrew)
      • 0.6.0 (built from source)

I vaguely remember similar issues many years ago with older GCC versions, on older systems. I think the main issue was that std::string had a breaking ABI change in C++11.

What is the default C++ standard assumed by your compiler? What happens if you set -std=c++11?

And… did you in the meantime manage to resolve this issue?

Thanks for your reply.

I compiled everything in C++1: precice (-DCMAKE_CXX_STANDARD=11), yaml-cpp (-DCMAKE_CXX_STANDARD=11), and also passed -std=c++11 in the adaptor’s makefile. So far, no luck.

Note that I had to add these flags to CFLAGS as well: -Wno-implicit-function-declaration -Wno-incompatible-pointer-types.

Thanks for the reports!

I guess a reasonable next step would be to find out if you can link a minimal yaml-cpp example to yaml-cpp, independent of CalculiX and preCICE. There are some examples here: Tutorial · jbeder/yaml-cpp Wiki · GitHub

Aha. It only links with clang++. So, I used clang++ and linked with libc++ instead of libstdc++ and the adaptor linked against libyaml-cpp without any error. If you like, I can send a patch or a PR.

1 Like

As we’re here, I want to also mention that in “Breaking dam with flexible pillar 2D” example, I get the following error for the solid case:

$ ./run.sh
Started on: Sun, 30 Mar 2025 06:22:49 +0330

************************************************************

CalculiX Version 2.20, Copyright(C) 1998-2022 Guido Dhondt
CalculiX comes with ABSOLUTELY NO WARRANTY. This is free
software, and you are welcome to redistribute it under
certain conditions, see gpl.htm

************************************************************

You are using an executable made on Sun Jul 31 18:08:37 CEST 2022

  The numbers below are estimated upper bounds

  number of:

   nodes:         1470
   elements:          244
   one-dimensional elements:            0
   two-dimensional elements:            0
   integration points per element:           27
   degrees of freedom per node:            3
   layers per element:            1

   distributed facial loads:            0
   distributed volumetric loads:            0
   concentrated loads:         1482
   single point constraints:          756
   multiple point constraints:            1
   terms in all multiple point constraints:            1
   tie constraints:            0
   dependent nodes tied by cyclic constraints:            0
   dependent nodes in pre-tension constraints:            0

   sets:            4
   terms in all sets:         2220

   materials:            1
   constants per material and temperature:            2
   temperature points per material:            1
   plastic data points per material:            0

   orientations:            0
   amplitudes:            3
   data points in all amplitudes:            3
   print requests:            0
   transformations:            0
   property cards:            0

 *INFO reading *STEP: nonlinear geometric
       effects are turned on


 STEP            1

 Dynamic analysis was selected

 Newton-Raphson iterative procedure is active

 Nonlinear geometric effects are taken into account

 Decascading the MPC's

 Determining the structure of the matrix:
 Using up to 1 cpu(s) for setting up the structure of the matrix.
 number of equations
 3660
 number of nonzero lower triangular matrix elements
 63428

Starting FSI analysis via preCICE using the geometrically non-linear CalculiX solver...
 Using up to 1 cpu(s) for the stress calculation.

 Using up to 1 cpu(s) for the energy calculation.

 Using up to 1 cpu(s) for the symmetric stiffness/mass contributions.

 Factoring the system of equations using the symmetric spooles solver
 Using up to 1 cpu(s) for spooles.

 Using up to 1 cpu(s) for the stress calculation.

 Using up to 1 cpu(s) for the energy calculation.

Setting up preCICE participant Solid, using config file: config.yml
[temple.local:59980] shmem: mmap: an error occurred while determining whether or not /var/folders/1t/mjqc57nd6jq91gb0_jb143w80000gn/T//ompi.temple.501/jf.0/2796027904/sm_segment.temple.501.a6a80000.0 could be created.
---[precice]  This is preCICE version 3.1.2
---[precice]  Revision info: v3.1.2-299-gfc0cff1b
---[precice]  Build type: Release (without debug log)
---[precice]  Working directory "/Volumes/code/opt/precice/tutorials/breaking-dam-2d/solid-calculix"
---[precice]  Configuring preCICE with configuration "../precice-config.xml"
---[precice]  I am participant "Solid"
Using quasi 2D-3D coupling
Set ID Found
2D-3D mapping results in a 2D mesh of size 247 from the 494 points in 3D space.
Read data 'Force' found.
Write data 'Displacement' found.
---[precice]  Setting up primary communication to coupling partner/s

Specifically this one:

[temple.local:59980] shmem: mmap: an error occurred while determining whether or not /var/folders/1t/mjqc57nd6jq91gb0_jb143w80000gn/T//ompi.temple.501/jf.0/2796027904/sm_segment.temple.501.a6a80000.0 could be created.

and then simulation is stuck here

---[precice]  Setting up primary communication to coupling partner/s

With printf-debugging I found out that it happens here:

  printf("Setting up preCICE participant %s, using config file: %s\n", participantName, configFilename);
  fflush(stdout);   <<<

from adapter/PreciceInterface.c.

LLM suggested passing --mca shmem mmap to mpirun; I edited the run.sh per below and that fixed the shmem error.

mpirun -np 1 --mca shmem mmap ccx_preCICE -i flap -precice-participant Solid

However, still the simulation is stuck at the last line I mentioned. I’m not sure whether that’s the intended behaviour.

Yes, please, submit a PR (or two, for the second issue) if you can, that would be great! :hugs:

Let’s continue the discussion in a new topic for each new problem.

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.