Unresolved soname dependencies in x11-drivers/nvidia-drivers

[stefan11111]

See: https://forums.gentoo.org/viewtopic-t-1164119.html
Ionen has explained it there better than I can.

[orbea]

I have AMD so correct me if I'm mistaken, but Nividia's drivers are a proprietary blob and unless Nvidia want's to provide the source or a version compiled against LibreSSL this is impossible to support?

[stefan11111]

Can't a compatibility library be written?

$ nm -D /usr/lib64/libnvidia-pkcs11.so.535.54.03
00000000002020d8 B __bss_start
00000000000013a0 T C_GetFunctionList
                 U CRYPTO_free@OPENSSL_1_1_0
                 U CRYPTO_malloc@OPENSSL_1_1_0
                 w __cxa_finalize
00000000002020d8 D _edata
0000000000202330 B _end
                 U EVP_aes_128_ctr@OPENSSL_1_1_0
                 U EVP_aes_256_gcm@OPENSSL_1_1_0
                 U EVP_CIPHER_CTX_ctrl@OPENSSL_1_1_0
                 U EVP_CIPHER_CTX_free@OPENSSL_1_1_0
                 U EVP_CIPHER_CTX_key_length@OPENSSL_1_1_0
                 U EVP_CIPHER_CTX_new@OPENSSL_1_1_0
                 U EVP_DecryptFinal_ex@OPENSSL_1_1_0
                 U EVP_DecryptInit_ex@OPENSSL_1_1_0
                 U EVP_DecryptUpdate@OPENSSL_1_1_0
                 U EVP_EncryptFinal_ex@OPENSSL_1_1_0
                 U EVP_EncryptInit_ex@OPENSSL_1_1_0
                 U EVP_EncryptUpdate@OPENSSL_1_1_0
                 U EVP_sha256@OPENSSL_1_1_0
0000000000001524 T _fini
                 w __gmon_start__
                 U HMAC@OPENSSL_1_1_0
                 U HMAC_CTX_free@OPENSSL_1_1_0
                 U HMAC_CTX_new@OPENSSL_1_1_0
                 U HMAC_CTX_reset@OPENSSL_1_1_0
                 U HMAC_Final@OPENSSL_1_1_0
                 U HMAC_Init_ex@OPENSSL_1_1_0
                 U HMAC_Update@OPENSSL_1_1_0
0000000000000b38 T _init
                 w _ITM_deregisterTMCloneTable
                 w _ITM_registerTMCloneTable
                 U OPENSSL_init_crypto@OPENSSL_1_1_0

Maybe also remove the fallback as Ionen described.

[orbea]

Can't a compatibility library be written?

To be forward I would not know how.

Maybe also remove the fallback as Ionen described.

My guess would be that subtle differences between LibreSSL and OpenSSL would be problematic here, but would need someone with Nvidia hardware to test it out and submit the fix. If you or someone else can figure it out PRs would be welcome. Unfortunately I don't think I can be very helpful here...

[stefan11111]

I will try to do something, but for the next few weeks I will be mostly away.

[stefan11111]

Don't know if you followed what was said on the linked topic and the changes to the ebuild.
Now, the ebuild unconditionally depends on openssl:0/3

!!! All ebuilds that could satisfy "dev-libs/openssl:0/3" have been masked.
!!! One of the following masked packages is required to complete your request:
- dev-libs/openssl-3.1.2::gentoo (masked by: package.mask)

This can be fixed either by maintaining yet another ebuild in this overlay, or by adding dev-libs/openssl-3.1.2
to package.provided.
I thought you should know about how the situation developed.

Also, maybe you can help me properly fixing this.

# nm -D /usr/lib64/libnvidia-pkcs11-openssl3.so.535.104.05
0000000000202038 B __bss_start
0000000000000d70 T C_GetFunctionList
                 w __cxa_finalize
                 U dlclose@GLIBC_2.2.5
                 U dlopen@GLIBC_2.2.5
                 U dlvsym@GLIBC_2.2.5
0000000000202038 D _edata
0000000000202350 B _end
0000000000001304 T _fini
                 w __gmon_start__
0000000000000580 T _init
                 w _ITM_deregisterTMCloneTable
                 w _ITM_registerTMCloneTable

I don't see any undefined symbols regarding openssl.

[orbea]

Thanks for the update.

This can be fixed either by maintaining yet another ebuild in this overlay, or by adding dev-libs/openssl-3.1.2
to package.provided.

I believe you might be misunderstanding the error, it seems to be depending on the slot version 0/3 used by the openssl package in ::gentoo while in the ::libressl overlay the fake openssl package uses the same slot as libressl which is currently 0/54. This makes me wonder if it really needs to be like this and perhaps it would be more compatible if the fake openssl package used the same slot as openssl in ::gentoo? I'll let you know when I have a chance to test this out.

[orbea]

Actually now that I slept on it my idea is flawed, we will need to change the slot on the fake openssl package everytime the libressl API changes requiring other packages to be rebuilt which makes it impossible to match the package in ::gentoo...

I also believe package.provided is only on the user's local system, but please correct me if I am mistaken?

This leaves the solution is to add nvidia to the overlay and then sync it every time it updates in ::gentoo, but that will be very tedious and I personally can't test that, but PRs welcome.

Bluntly this is one of the reasons why it would be much easier if libressl was still in the ::gentoo repo, just getting rid of the fake openssl package would make integration much easier....

[stefan11111]

Actually now that I slept on it my idea is flawed, we will need to change the slot on the fake openssl package everytime the libressl API changes requiring other packages to be rebuilt which makes it impossible to match the package in ::gentoo...

I also believe package.provided is only on the user's local system, but please correct me if I am mistaken?

It was once possible to use package.provided in profiles.
See: https://forums.gentoo.org/viewtopic-t-1136862.html

Note that using package.provided like this seems to cause problems:

$ doas emerge -cav openssl

Calculating dependencies... done!
>>> Calculating removal order...

>>> These are the packages that would be unmerged:

 dev-libs/openssl
    selected: 3.8.1
   protected: none
     omitted: none

This is the dev-libs/openssl::libressl being slated for removal.

This leaves the solution is to add nvidia to the overlay and then sync it every time it updates in ::gentoo, but that will be very tedious and I personally can't test that, but PRs welcome.

Openssl 1.1 is on the chopping block, so maybe we can get the slot dependency to be relaxed.

Bluntly this is one of the reasons why it would be much easier if libressl was still in the ::gentoo repo, just getting rid of the fake openssl package would make integration much easier....

But we can't do that for whatever reason.

[orbea]

Note that using package.provided like this seems to cause problems:

Yea, that should of been obvious in retrospect...again this doesn't seem to be the right approach because we need the dummy openssl to trigger rebuilds for libressl API changes.

Openssl 1.1 is on the chopping block, so maybe we can get the slot dependency to be relaxed.

I would suspect that would be acceptable for ::gentoo when openssl 1.1 is finally removed.

Until then I think the easiest is to just edit the nvidia ebuild.

[stefan11111]

After looking further into this(mostly reading error messages), It seems that cs2(formerly cs:go) needs this.
Proton also may or may not need this in order to work, but lists the unresolved soname dependency as a warning.

I decided to make this small "repo": https://github.com/stefan11111/libcrypto-compat
Using this, I got cs:2 to start when it previously didn't.
I also made an ebuild for it: https://github.com/stefan11111/stefan_overlay/blob/main/dev-libs/libcrypto-compat/libcrypto-compat-1.0.ebuild

Using this, the unresolved soname dependency error from portage is gone.
I know that I'm repeating myself, but I really don't see any undefined symbols that need defining.
Is there any way to test that?

However, there seems to be a better solution to all this:

$ equery b libcrypto.so
 * Searching for libcrypto.so ...
dev-libs/libcrypto-compat-1.0 (/lib64/libcrypto.so -> libcrypto.so.3)
dev-libs/libressl-3.8.2 (/usr/lib64/libcrypto.so -> libcrypto.so.52.0.0)

So libressl does have that library, but it has a different soname:

$ readelf -d /usr/lib64/libcrypto.so

Dynamic section at offset 0x2783e8 contains 24 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000000e (SONAME)             Library soname: [libcrypto.so.52]

In that case, the best way to fix this is to somehow build/make a copy of libcrypto.so and give it a different soname. Any idea how to do that?

[orbea]

Sorry, I'm not really sure, but maybe LD_PRELOAD is the right thing to use here?

[stefan11111]

I found a way to properly solve this with a hook:

$ cat /etc/portage/env/dev-libs/libcrypto-compat
post_pkg_postinst() {
        cp /usr/lib64/libcrypto.so /lib64/libcrypto.so.3
        ln -rsf /lib64/libcrypto.so.3 /lib64/libcrypto.so
        patchelf --set-soname libcrypto.so.3 /lib64/libcrypto.so
}

I still can't get rid of that dummy package and put the hook directly on libressl or openssl because portage doesn't see it and throws that warning.
But this is good enough.