<table border="1" cellspacing="0" cellpadding="8">
    <tr>
        <th>Issue</th>
        <td>
            <a href=https://github.com/llvm/llvm-project/issues/80750>80750</a>
        </td>
    </tr>

    <tr>
        <th>Summary</th>
        <td>
            libompd.so depends on libomp.so, but it should not
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            new issue
      </td>
    </tr>

    <tr>
      <th>Assignees</th>
      <td>
      </td>
    </tr>

    <tr>
      <th>Reporter</th>
      <td>
          jdelsign
      </td>
    </tr>
</table>

<pre>
    libompd.so depends on libomp.so, which I think is a bug, because it requires setting LD_LIBRARY_PATH for the debugger process so that the OMPD DLL dependency can be resolved by the dynamic linker.  Note that all of the LLVM clang-derived builds I checked have the same problem.

Here's an example of the dependency for Clang 17.0.1:

```
% readelf -d libompd.so | grep libomp
 0x0000000000000001 (NEEDED)             Shared library: [libomp.so]
 0x000000000000000e (SONAME)             Library soname: [libompd.so]
%
```

I think this is a problem because:

1. The debugger is not an OpenMP program, and therefore should not have one or more OMP libraries loaded as a side-effect of loading one or more OMPD libraries.
2. The dlopen() of the OMPD library fails unless the user sets LD_LIBRARY_PATH correctly or the debugger explicitly dlopens() the OMP library itself.
3. In a multi-process debugger, it is not possible to set LD_LIBRARY_PATH correctly if multiple processes are using different OMPD libraries.
4. The libomp.so dependency might bind to the wrong library.
 
For example, at LLNL with the CCE Clang  compiler, I see this:
```
    rzvernal10{jdelsign}:ldd ./libompd.so | grep libomp
 libomp.so => /lib64/libomp.so (0x0000155555029000)
 rzvernal10{jdelsign}:md5sum ./libomp.so /lib64/libomp.so
 4816b8452c002e798cf7e146e6f179e5  ./libomp.so
 222130624ee2119d7c446ec9138ba712  /lib64/libomp.so
 rzvernal10{jdelsign}:ls -l ./libomp.so /lib64/libomp.so
    -rwxr-xr-x 1 root root 1354120 Nov  7 14:49 ./libomp.so
    -rwxr-xr-x 1 root root 1018800 Jul 15  2023 /lib64/libomp.so
 rzvernal10{jdelsign}:
```
So, at LLNL there just so happens to be a libomp.so in /lib64, which is not the CCE Clang OMP library.

</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJycVl9vo7gX_TTOy1WQbSDAQx7SptX0p_SPZkY_aZ9GBl_AMwZnbdM2--lXBjKlnW53tCgiSq7vueden2MQzqmmR9yS9IKk-5UYfGvs9rtEHQKr0sjTVqvSdEcZOQMSj9hLB6aH6d_IGcIv4alVVQs34FvV_wDlQEA5NCFSYiUGh6A8WPxzUBYdOPRe9Q0c9t8ONxefd5__-Paw-_oJamPBtwgSy6Fp0MLRmgqdA2fAt8KPwfvbhz3sD4eZC_bVCSrRQ4lg0Rn9iBLK04Rz6kWnKtCq_4E2ArgzHickoTWYelx1OPz_Fiot-mYt0aoxf1BaOriBqsXqB0poxSOOi53oMNAqNXYRoXtCd9P9E1okPHMgesBn0R01ngssiIYOL0MpYFlEI0bi3RKEbOj8mX7yFCwKibqGtYTFPpDsEhqLx_m_aTnQZ_r6YkB4fnd1tb_aE17A8vrSCosjphX2ROIdkPTiZU_T_T9hYsD8cn-3u716i3mYwMCZXnT4ClMuQQlP3-93vJ9V5FvlJinN8z5r6c3QWARfl6JRDnrjwz7cH7G_fQjpjRVdUKPoZdgSi7WxCK41g5bj6nGDTY9gLHQhdn_7MA9HoQNthEQJIrBxSuIa6xorH3Y4hIKY3yTvX7JnnfCZpzZH7AnPw_RmhSzWn6AWSjsYeh2UH6KDQxs8434xTGWsxcrrE7x1Dj4ftapUCE0F3VxxLvezmvIOdT1TjCO46UFAN2iv1mf3nUHDAJU_z_donFOlRvAmkPuAm6onwGCJGRMdCBs6C5OTqq7RYu_fn1syze2nNpd-6lTTeihV2FYz9vZkTd-cu5sRYPq6NvZszVELHg6HuwM8Kd-OqZeXV7M5oTLdUemp5RtwiKMaX4T3WrdB-_avR7S90IyS7OJ8fpJsT-KdlhIiwq__1b8vLZJ4T-IrmJI2yc_kMcbzyZQsDRflBaWU8GIG-YBIJ1M3dAsuE9yvNWaoJGebMk9SXlHKMSvyqs6QJRvc1CwrMIXXUHMW55zFdMMTRM5YIbMqSTZYFSzOS5ExDh-V_GiMDtb698kDwNo-Pdt1-AADa4yfbixOE8Yp3JlHgAxYQuJdUrzbywcglOU5pfC_QQNLATjl8X9s7F1NfTFLjY5nFnwfnA_PwlYcg6OD5EsEsdCN6hcczo_l2bCvJb44A2aXrOQ2lkVciBVuWUYzlrGsSFftNuZ1kpc0r5EVLMO6itOEcillXnLGUlypLac8oZymnPOYpVGORU2RFkVaZ2mSb0hCsRNKR1o_dpGxzUo5N-A2p1lKV1qUqN34CsJ5j08wBgnn4Y3EbkPOuhwaRxKqlfPuBcUrr_F33k_KwYej6-XAXw1Wb1vvj6Op-TXh143y7VBGlenCCPXj-Sucg9-x8oRfj8Qc4dcj8b8DAAD__0jk43E">