# Problem linking adapted CalculiX against yaml-cpp (macOS)

**URL:** <https://precice.discourse.group/t/problem-linking-adapted-calculix-against-yaml-cpp-macos/2264>\
**Category:** Official adapters and tutorials\
**Tags:** adapters, calculix, macos\
**Created:** [December 11, 2024, 10:31pm UTC](https://precice.discourse.group/t/problem-linking-adapted-calculix-against-yaml-cpp-macos/2264 "2024-12-11T22:31:26Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![abzrg](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/abzrg/32/2697_2.png) [@abzrg](https://precice.discourse.group/u/abzrg)\
**Post date:** [December 11, 2024, 10:31pm UTC](https://precice.discourse.group/t/problem-linking-adapted-calculix-against-yaml-cpp-macos/2264/1 "2024-12-11T22:31:26Z")

</div>

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)

---

<div class="post-metadata">

**Author:** ![Makis](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/makis/32/25_2.png) [@Makis](https://precice.discourse.group/u/Makis)\
**Post date:** [March 21, 2025, 5:18pm UTC](https://precice.discourse.group/t/problem-linking-adapted-calculix-against-yaml-cpp-macos/2264/2 "2025-03-21T17:18:50Z")

</div>

I vaguely remember [similar issues](https://github.com/precice/openfoam-adapter/issues/83#issuecomment-558622094) 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?

---

<div class="post-metadata">

**Author:** ![abzrg](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/abzrg/32/2697_2.png) [@abzrg](https://precice.discourse.group/u/abzrg)\
**Post date:** [March 29, 2025, 3:52am UTC](https://precice.discourse.group/t/problem-linking-adapted-calculix-against-yaml-cpp-macos/2264/3 "2025-03-29T03:52:41Z")

</div>

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`.

---

<div class="post-metadata">

**Author:** ![Makis](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/makis/32/25_2.png) [@Makis](https://precice.discourse.group/u/Makis)\
**Post date:** [March 29, 2025, 5:48pm UTC](https://precice.discourse.group/t/problem-linking-adapted-calculix-against-yaml-cpp-macos/2264/4 "2025-03-29T17:48:30Z")

</div>

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](https://github.com/jbeder/yaml-cpp/wiki/Tutorial)

---

<div class="post-metadata">

**Author:** ![abzrg](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/abzrg/32/2697_2.png) [@abzrg](https://precice.discourse.group/u/abzrg)\
**Post date:** [March 30, 2025, 1:58am UTC](https://precice.discourse.group/t/problem-linking-adapted-calculix-against-yaml-cpp-macos/2264/5 "2025-03-30T01:58:46Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![abzrg](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/abzrg/32/2697_2.png) [@abzrg](https://precice.discourse.group/u/abzrg)\
**Post date:** [March 30, 2025, 3:26am UTC](https://precice.discourse.group/t/problem-linking-adapted-calculix-against-yaml-cpp-macos/2264/6 "2025-03-30T03:26:58Z")

</div>

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:

```cpp
  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.

```sh
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.

---

<div class="post-metadata">

**Author:** ![Makis](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/makis/32/25_2.png) [@Makis](https://precice.discourse.group/u/Makis)\
**Post date:** [March 30, 2025, 7:59am UTC](https://precice.discourse.group/t/problem-linking-adapted-calculix-against-yaml-cpp-macos/2264/7 "2025-03-30T07:59:14Z")

</div>

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

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

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/free1/uploads/precice/original/1X/67d2a5fa6f80e597e2267ff17fa8c1673cd11caa.svg) [@system](https://precice.discourse.group/u/system)\
**Post date:** [April 2, 2025, 8:00am UTC](https://precice.discourse.group/t/problem-linking-adapted-calculix-against-yaml-cpp-macos/2264/8 "2025-04-02T08:00:05Z")

</div>

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