On Fri, 1 Jul 2022 at 16:33, Alex Remily <[email protected]> wrote: > > <BTW I'm working on code to show the actual path that was loaded; this will > be shown in the Crypto main output.>
Now committed; seems to work on all 3 main OSes. > I like the approach. I wrote most of the version code that you're > touching, and your refactoring is more elegant. Thanks, but I'm not sure I have done that much. > I hadn't written much C > since school, so I kind of hacked my way through it. It works, but > definitely room for improvement. Likewise, it has been a while since I used C (probably on this project). > At first glance it appears that your > approach would be easier to build on when we start on OpenSSL 3.0 > support, which is an added benefit. If you are referring to the fallback name strategy that just seemed like a simple way to avoid having to check versions. But it only applies to the JNI code, and it only works where there is an equivalent function with a different name. That happens to be the case here currently. We shall have to see if it works for OpenSSL 3.0. I don't think a similar approach is possible for JNA because of the way the binding is done. > Alex > > On Fri, Jul 1, 2022 at 5:52 AM sebb <[email protected]> wrote: > > > On Fri, 1 Jul 2022 at 04:16, Bernd Eckenfels <[email protected]> > > 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 <[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] > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
