On Fri, 1 Jul 2022 at 04:16, Bernd Eckenfels <e...@zusammenkunft.net> wrote: > > 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.
According to dlopen(3) it does not search PATH, instead it uses LD_LIBRARY_PATH, and some DYLD_* paths. > 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?) It's not possible in general to put the required version first, so I agree an (optional) override is needed. I don't think it would do any harm. BTW I'm working on code to show the actual path that was loaded; this will be shown in the Crypto main output. > 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? Not sure that would make a difference here. > Whats the lib filename constant in above line in your case? > > Gruss > Bernd > -- > http://bernd.eckenfels.net > ________________________________ > Von: Alex Remily <alex.rem...@gmail.com> > Gesendet: Friday, July 1, 2022 4:26:33 AM > An: Commons Developers List <dev@commons.apache.org> > 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 <gillese...@gmail.com> > wrote: > > > Le jeu. 30 juin 2022 à 23:35, sebb <seb...@gmail.com> a écrit : > > > > > > On Thu, 30 Jun 2022 at 16:21, Alex Remily <alex.rem...@gmail.com> 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: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
