Fedora package interferes with OS pacakges

[LecrisUT]

Try the following dockerfile:

```dockerfile

FROM fedora:40

COPY <<EOF /etc/yum.repos.d/oneAPI.repo
[oneAPI]
name=Intel(R) oneAPI repository
baseurl=https://yum.repos.intel.com/oneapi
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://yum.repos.intel.com/intel-gpg-keys/GPG-PUB-KEY-INTEL-SW-PRODUCTS.PUB
EOF

RUN dnf install -y \
g++
RUN dnf install -y \
intel-oneapi-compiler-dpcpp-cpp
RUN dnf install -y \
openmpi-devel

RUN <<EOF
set -e
source /etc/profile.d/modules.sh
module load mpi/openmpi
mpicxx --version
EOF

```

This gives the error

```

mpicxx: error while loading shared libraries: libhwloc.so.15: cannot open shared object file: No such file or directory

```

even though it should be using `g++` and `openmpi` there. If we switch the installation of `openmpi-devel` to be above the intel packages than it works fine again. This issue is most likely in the scriplets that are executed.

[Vipin_S_Intel]

Hi Crisian, Could you please share the below details with us?

• Exact name of the Intel® Toolkit along with its build version.
• Build version of Operating System (Fedora) on which you're installing the product.
• Other versions of Intel® Parallel Studio XE or Intel® oneAPI already installed on the system.
• Is the installer an online or an offline package? 
• Screenshot (if any)

To assist you further, we would require these details.

[LecrisUT]

I have already provided you with a reproducable environment. Please build the dockerfile as instructed. If you pay atention, all of the answers to your questions are there:
- latest version available in https://yum.repos.intel.com/oneapi. Try playing around with the dockerfile and you would see it is reproducible with any version
- fedora:40
- it's a clean container, so of course not
- rpm repo
- just build the dockerfile and take whatever screenshots you want

I have put the effort to minimize the reproducable environment to a simple containerfile, the least you could do is return the courtesy of not replying with a copy-pasted request for more information, when all of the information is evidently in the first comment.

[Vipin_S_Intel]

Hi Cristian,

Thank you so much for your efforts in minimizing the reproducible environment to a simple container file. However, we would like to inform you that we are unable to open the Docker file, as it results in an error. This is why we requested that you share the details.

We appreciate your continued cooperation and look forward to assisting you further.

Thanks! Have a great day ahead!

[LecrisUT]

Again, please read and take my issue seriously. The error in the build process *IS* the issue that I am reporting on. The issue is that depending on the order of installations, intel packages affect system packages, in this case, after installing `intel-oneapi-compiler-dpcpp-cpp` (in step 3), system packages like`openmpi` are affected (in step 4), as shown in step 5 where we try to load the openmpi, but fail with cannot open `libhwloc.so.15`.

And again, I've said from the beginning that this is order dependent and you can simply swap step 3 and step 4 to get a working environment to debug, i.e.:

```dockerfile

FROM fedora:40

COPY <<EOF /etc/yum.repos.d/oneAPI.repo
[oneAPI]
name=Intel(R) oneAPI repository
baseurl=https://yum.repos.intel.com/oneapi
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://yum.repos.intel.com/intel-gpg-keys/GPG-PUB-KEY-INTEL-SW-PRODUCTS.PUB
EOF

RUN dnf install -y \
    g++
RUN dnf install -y \
    openmpi-devel
RUN dnf install -y \
    intel-oneapi-compiler-dpcpp-cpp

RUN <<EOF
set -e
source /etc/profile.d/modules.sh
module load mpi/openmpi
mpicxx --version
EOF

```

[Luis_at_Intel]

Hi Cristian,

I am able to reproduce the issue you describe, openmpi-devel depends on Hwloc library which it cannot locate after installation of intel-oneapi-compiler-dpcpp-cpp as per the original Dockerfile. Please try exporting the setupvars.sh script before loading the openmpi module as described in https://www.intel.com/content/www/us/en/docs/oneapi/programming-guide/2025-0/use-the-setvars-and-oneapi-vars-scripts-with-linux.html, let us know if the issue is resolved on your end. Hope this helps!

# dockerfile snippet
RUN <<EOF
set -e
source /opt/intel/oneapi/setvars.sh
source /etc/profile.d/modules.sh
module load mpi/openmpi
mpicxx --version
EOF

[LecrisUT]

@Luis_at_Intel 

I did not get to reply to this issue, so do not close it prematurely.

The issue is that the installation of a package should **NOT** cause other packages to misbehave. Evidently there is something wrong with the scriplets in the intel spec file that are patching non-intel packages as well. The suggestion of using `setupvars.sh` is inappropriate because it does not make it load gcc's `hwloc` for which it was built and tested on, potentially causing unnecessary issues being filed to Fedora downstream when in fact the issue is that the user installed intel packages.

If possible to share the spec file or srpm file used, maybe we can tackle it from the Fedora side as well.

[Luis_at_Intel]

This thread will no longer be monitored since we have provided a solution. If you need any additional information from Intel, please submit a new question.

[Juhi_B_Intel]

@LecrisUT

I apologize on Luis's behalf for closing this issue, I am checking with our team if we can share those files with you or not. If we cannot then we might need to debug this internally. I will post here and let you know how that goes.

[Juhi_B_Intel · Accepted solution]

@Lecris

This issue happening because the openmpi-devel doesn't install the "hwlock-libs" packages because the intel-oneapi-tcm-1.2, the "intel-oneapi-compiler-dpcpp-cpp"'s dependency is already provides the "libhwloc.so.15()(64bit)"

To avoid the issue, you may either install the "hwloc-libs" additionally or source the oneAPI environment.

This is nothing to do with the packages specs. oneAPI packages doesn't modify any other packages files and configurations but if you still want to check install scriplets in oneAPI rpm packages, then you need to download rpms and extract spec-files from them (rpm -qp --scripts rpm.rpm)

[LecrisUT]

Thank you for investigating, but that actually highlights the issue in the packaging. oneAPI packages MUST NOT emit a `Provides: libhwloc.so.15()(64bit)` because it does not provide it for all libraries by default either in `/usr/lib64` or `/etc/ld.so.conf.d/` etc. It is only made available after running `module load` or sourcing the `setvars.sh`. Instead you should look at how `openmpi` based packages are used, where it provides `(openmpi)` variants of the libraries, e.g.:

```console

$ fedrq pkgs hdf5 -F provides
libhdf5.so.310()(64bit)

$ fedrq pkgs hdf5-openmpi -F provides
libhdf5.so.310()(64bit)(openmpi-x86_64)

```

Precisely how this is done, I am not quite sure, but I can ping some involved people over in the Fedora matrix channels (https://matrix.to/#/#devel:fedoraproject.org). You can also ping me there as @Lecris:matrix.org