gomp lib installed in multiple places in container

[yaswant]

Describe the bug
While configuring a projects using JEDI container/environment a lot of CMake warnings resulting due to GOMP installed in multiple implicit directories.

CMake Warning at /opt/views/._view/cimg64v3ckgivk7zqxf3vyx3wfc3nvek/share/ecbuild/cmake/ecbuild_add_test.cmake:316 (add_executable):
  Cannot generate a safe runtime search path for target
  test_l95_identitymodel because files in some directories may conflict with
  libraries in implicit directories:

    runtime library [libgomp.so.1] in /usr/lib/gcc/x86_64-linux-gnu/9 may be hidden by files in:
      /opt/views/view/lib

To Reproduce
See any build output from CI runs.
For example:
https://jedi-ci-build-public-logs.s3.us-east-2.amazonaws.com/oops-2714-21aeb2c-gnu-C76RNTWN.html

Expected behavior
A safe runtime search path is desirable. The current behaviour kind of defeats the whole purpose of containerised environment.

[climbfuji]

In /opt/views/view/lib the gomp library should be a symbolic link to the file in the actual spack install directory, not a copy?

[yaswant]

@climbfuji it is indeed, in fact almost everything is symbolically linked in /opt/views/view. Is there any particular reason for this?

[climbfuji]

@climbfuji it is indeed, in fact almost everything is symbolically linked in /opt/views/view. Is there any particular reason for this?

This is on purpose (by the spack developers). You shouldn't have to point cmake to anything else than /opt/views/view and/or set the environment variables PATH, LD_LIBRARY_PATH, ..., accordingly.

[yaswant]

In that case, perhaps setting CMAKE_PREFIX_PATH to /opt/views/view will help reduce ~8000 lines of cmake warning pollution?

[climbfuji]

Yes, that is my guess

[eap]

I am actively working on this since it has affecged my container updates. For the GNU container I can simply remove an unnecessary package that installs libgomp. I'm unsure if that strategy will work for the intel and clang images. If it turns out that we need it installed due to a dependency issue, we can probably just configure it as an external package... yes?

[eap]

This is resolved by adding an external / buildable:false spec to the container. In my draft PR #1239 which also updates gcc to v12, I was able to use this spec to fix the issue.

  gcc-runtime:
      buildable: false
      externals:
      - spec: [email protected]