c#: DllNotFoundException on net 6 runtime with alpine 3.15

[akryvasheyeu]

Used official docker image mcr.microsoft.com/dotnet/aspnet:6.0.3-alpine3.15 with glibc 2.30-r0

Any attempt to use Decimal64 fails with:

# dotnet TestDfp.dll
Unhandled exception. System.DllNotFoundException: Unable to load shared library 'ddfp0x11x25' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: Error loading shared library libddfp0x11x25: No such file or directory
   at EPAM.Deltix.DFP.NativeImplImport.ddfp0x11x25_subtract(UInt64 a, UInt64 b)
   at EPAM.Deltix.DFP.NativeImplObj.ddfp0x11x25_subtract(UInt64 a, UInt64 b)
   at EPAM.Deltix.DFP.NativeImpl.subtract(UInt64 a, UInt64 b)
   at EPAM.Deltix.DFP.Decimal64.op_Subtraction(Decimal64 a, Decimal64 b)
   at Program.<Main>$(String[] args)

but file /tmp/EPAM.Deltix/DFP/0.11.25.0/amd64/libddfp0x11x25.so exists

[agdavydov81]

Similar reproduced with DFP 0.10.24:

Unhandled exception. System.TypeInitializationException: The type initializer for 'Deltix.DFP.NativeImpl' threw an exception.
 ---> System.DllNotFoundException: Unable to load shared library 'DecimalNative2' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: Error loading shared library libDecimalNative2: No such file or directory
   at Deltix.DFP.NativeImports.version()
   at Deltix.DFP.NativeImports.VerifyVersion()
   at Deltix.DFP.NativeImportsWrapper.VerifyVersion()
   at Deltix.DFP.NativeImpl..cctor()
   --- End of inner exception stack trace ---
   at Deltix.DFP.NativeImpl.subtract(UInt64 a, UInt64 b)
   at Deltix.DFP.Decimal64.op_Subtraction(Decimal64 a, Decimal64 b)
   at Program.<Main>$(String[] args) in /home/user/TestDfp/Program.cs:line 9

Also, the native part looks unpacked OK:

# ldd /usr/share/.rtmath/dfp/0.10.24.0/64/libDecimalNative2.so 
	/lib/ld-musl-x86_64.so.1 (0x7f2504402000)
	libm.so.6 => /lib/ld-musl-x86_64.so.1 (0x7f2504402000)
	libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7f2503f98000)
	libc.so.6 => /lib/ld-musl-x86_64.so.1 (0x7f2504402000)
	ld-linux-x86-64.so.2 => /lib/ld-linux-x86-64.so.2 (0x7f2503f6d000)
	libdl.so.2 => /lib/ld-musl-x86_64.so.1 (0x7f2504402000)

[akryvasheyeu]

@agdavydov81 can you check version 0.10.6? this is version that was used by our net.core app before (with net 5 runtime + alpine.3.14 )

[agdavydov81]

@akryvasheyeu Same result with 0.10.6:

/home/user/TestDfp # /root/.dotnet/dotnet run
Unhandled exception. System.TypeInitializationException: The type initializer for 'Deltix.DFP.NativeImpl' threw an exception.
 ---> System.DllNotFoundException: Unable to load shared library 'DecimalNative2' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: Error loading shared library libDecimalNative2: No such file or directory
   at Deltix.DFP.NativeImports.version()
   at Deltix.DFP.NativeImports.VerifyVersion()
   at Deltix.DFP.NativeImportsWrapper.VerifyVersion()
   at Deltix.DFP.NativeImpl..cctor()
   --- End of inner exception stack trace ---
   at Deltix.DFP.NativeImpl.subtract(UInt64 a, UInt64 b)
   at Deltix.DFP.Decimal64.op_Subtraction(Decimal64 a, Decimal64 b)
   at Program.<Main>$(String[] args) in /home/user/TestDfp/Program.cs:line 9

/home/user/TestDfp # ls -l /usr/share/.rtmath/dfp/0.10.6.0/64
total 2404
-rw-r--r--    1 root     root       2459720 Apr  6 09:28 libDecimalNative2.so

[agdavydov81]

Seems this is only .NET problem.
Java version works fine.

[agdavydov81]

The switch to the old NativeUtils do not resolved this problem.

Was tests on the NativeUtils
Revision: 911d947d96910259f02f4a94c69b3e5fd29eb461
Date: 11/1/2018 19:28:08

[agdavydov81]

I stop wasting time on musl statically linking.
If anyone knows how to do this - write to me.

Latest try was:
Inside Alpine docker container:
gcc -DDECIMAL_CALL_BY_REFERENCE=0 -DDECIMAL_GLOBAL_EXCEPTION_FLAGS=1 -DDECIMAL_GLOBAL_ROUNDING=1 -DLINUX -DUSE_COMPILER_F128_TYPE=0 -DUSE_COMPILER_F80_TYPE=0 -DUSE_NATIVE_QUAD_TYPE=0 -Defi2 -Dlinux -O3 -DNDEBUG -fPIC -I/dockerVolume/DFP-epamHub/thirdparty/IntelRDFPMathLib20U2/LIBRARY/src -shared NativeImpl.c -Wl,--whole-archive ./build/LIBRARY/libbid.a

-static-pie argument does not helps

Seems this can help
https://habr.com/ru/post/591979/

[agdavydov81]

The workaround is published on 0.12.3:

You can specify unpack root environmental variables.
For example: DFP_UNPACK_ROOT=/usr/lib and DFPMATH_UNPACK_ROOT=/usr/lib
So, at first the loader will fail to find the library in the list of the process loaded libraries.
But than it will find the library inside one of the standard libraries folder (/usr/lib in the example).

Of course, this is not a fix, but it can slightly mitigate the problem.