The Java.library.path controls the Java side loadLibrary() but that worked since it loaded the commons-crypto JNI lib.
The dlopen In that shim searches various places, including PATH. If you can’t put the OpenSSL variant first, then it might instead help to define the path with a absolute name instead (maybe make it configurable with env or system property?) https://github.com/apache/commons-crypto/blob/8539d5f09e483d8a01635df9df062e0a4972a71d/src/main/native/org/apache/commons/crypto/OpenSslInfoNative.c#L74 It might also help to remove the global flag to avoid re-exports? Whats the lib filename constant in above line in your case? Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: Alex Remily <[email protected]> Gesendet: Friday, July 1, 2022 4:26:33 AM An: Commons Developers List <[email protected]> Betreff: Re: [CRYPTO] Problem with JNA on macOS and Windows <Did you try with "java.library.path"> Yup. Still loads LibreSSL. Alex@Alexs-MacBook-Pro commons-crypto % java -Djava.library.path=/usr/local/opt/openssl/lib -cp target/classes org.apache.commons.crypto.Crypto Apache Commons Crypto 1.1.1-SNAPSHOT Native code loaded OK: 1.1.1-SNAPSHOT Native name: Apache Commons Crypto Native built: Jun 30 2022 OpenSSL library loaded OK, version: 0x20000000 OpenSSL library info: LibreSSL 2.2.9 Random instance created OK: org.apache.commons.crypto.random.OpenSslCryptoRandom@6442b0a6 Cipher AES/CTR/NoPadding instance created OK: org.apache.commons.crypto.cipher.OpenSslCipher@21bcffb5 Additional OpenSSL_version(n) details: 1: not available 2: compiler: information not available 3: built on: date not available 4: platform: information not available 5: OPENSSLDIR: "/private/etc/ssl" Alex@Alexs-MacBook-Pro commons-crypto % On Thu, Jun 30, 2022 at 6:16 PM Gilles Sadowski <[email protected]> wrote: > Le jeu. 30 juin 2022 à 23:35, sebb <[email protected]> a écrit : > > > > On Thu, 30 Jun 2022 at 16:21, Alex Remily <[email protected]> wrote: > > > > > > <For example, the standalone code takes note of LD_LIBRARY_PATH when > > > loading the dll, whereas Java apparently does not.> > > > > > > I experience the same behavior. What's more interesting is that when > I run > > > the main function from Eclipse as a Run Configuration with the > > > LD_LIBRARY_PATH set as an Environment variable appended to the native > > > environment, it runs as expected. As of yet I haven't found a way to > get > > > the java CLI to recognize the LD_LIBRARY_PATH environment variable, > even > > > though it echos out correctly when queried. Strange. > > Did you try with "java.library.path" (cf. [1])? > > Gilles > > [1] > https://stackoverflow.com/questions/27945268/difference-between-using-java-library-path-and-ld-library-path > > > [...] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
