Re: [CRYPTO] Problem with JNA on macOS and Windows

2022-06-30 Thread Bernd Eckenfels 
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 
Gesendet: Friday, July 1, 2022 4:26:33 AM
An: Commons Developers List 
Betreff: Re: [CRYPTO] Problem with JNA on macOS and Windows



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: 0x2000

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 
wrote:

> Le jeu. 30 juin 2022 à 23:35, sebb  a écrit :
> >
> > On Thu, 30 Jun 2022 at 16:21, Alex Remily  wrote:
> > >
> > >  > > 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
>
>

Re: [collections] JMH results for IndexedLinkedList

2022-06-30 Thread Matt Juntunen 
Hello rodde,

Thank you for sending me a reminder on this. Unfortunately, I haven't
had time to look at the code yet. Gilles suggestions are something I
would like to see as well. Having tables of JMH results for the
different algorithms at different sizes would be very helpful.

Regards,
Matt J

On Thu, Jun 30, 2022 at 11:34 AM Gilles Sadowski  wrote:
>
> Hello.
>
> Le jeu. 30 juin 2022 à 07:54, Rodion Efremov  a écrit :
> >
> > Hi Matt and community,
> >
> > Have you take a look at my work? If so, what do you think?
>
> Perhaps you missed that feedback:
>   https://markmail.org/message/y3tozjdke2ivz3dr
>
> >
> > Best regards,
> > rodde
> >
> > to 23.6.2022 klo 19.06 Matt Juntunen  kirjoitti:
> >
> > > Hello,
> > >
> > > Thanks for providing the data here. I will hopefully have time to take
> > > a look at this over the weekend. Send me a ping here on the dev list
> > > if you don't hear back from me (or someone else) within a week.
> > >
> > > Regards,
> > > Matt J
> > >
> > > On Tue, Jun 21, 2022 at 7:22 AM Rodion Efremov 
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > Data structure: IndexedLinkedList
> > > > 
> > > > Benchmark: IndexedLinkedListBenchmark
> > > > 
> > > >
> > > > Benchmark output:
> > > > https://github.com/coderodde/indexedLinkedList/#benchmark-output
> > > >
> > > > From the benchmark output, we can judge that IndexedLinkedList
> > > outperforms
> > > > both java.util.LinkedList and the Apache Commons Collections TreeList.
> > > It,
> > > > however, does not seem to supersede the java.util.ArrayList.
> > > >
> > > > Basically, I would expect the IndexedLinkedList to beat the ArrayList
> > > where
> > > > we have a lot of following operations:
> > > >
> > > >- addFirst(E)
> > > >- add(int, E)
> > > >- remove(int)
> > > >
> > > > So, what do you think? I am getting anywhere with that?
> > > >
> > > > Best regards,
> > > > rodde
>
> -
> 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

Re: [CRYPTO] Problem with JNA on macOS and Windows

2022-06-30 Thread Alex Remily 
I tinkered with the same issues today and have come to the
same conclusion.  We may want to consider optionally prepending a path to
the COMMONS_CRYPTO_OPENSSL_LIBRARY to specify a specific libcrypto.

On Thu, Jun 30, 2022 at 5:35 PM sebb  wrote:

> On Thu, 30 Jun 2022 at 16:21, Alex Remily  wrote:
> >
> >  > 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.
>
> If you use getenv within the JNI C code, it does not see any of the
> library-related environment variables.
>
> It looks like DYLD_* is dropped, along with LD_LIBRARY_PATH.
>
> There is some strange behaviour with export as well.
> Try the following:
>
> export LD_LIBRART_PATH=/usr/lib
> export LD_LIBRARY_PATH=/usr/lib
> env | grep LIBRAR
>
> I get:
>
> LD_LIBRART_PATH=/usr/lib
>
> Similarly with DYLD_*
>
> I think we may need to allow the user to provide the full path name to
> the crypto library.
>
> > On Thu, Jun 30, 2022 at 9:39 AM sebb  wrote:
> >
> > > I've started copying bits of the C code to create a standalone tool to
> > > load the dll and report some info.
> > >
> > > No idea why yet, but it behaves differently from basically the same
> > > code when run via JNI.
> > >
> > > For example, the standalone code takes note of LD_LIBRARY_PATH when
> > > loading the dll, whereas Java apparently does not.
> > >
> > > On Thu, 30 Jun 2022 at 13:22, Alex Remily 
> wrote:
> > > >
> > > > I also get the "Error looking up function 'ENGINE_load_rdrand'" when
> I
> > > run
> > > > the Jna test class from the command line.  Interesting.  dlopen
> finds the
> > > > LibreSSL when run from the CLI.
> > > >
> > > > On Thu, Jun 30, 2022 at 8:02 AM sebb  wrote:
> > > >
> > > > > That looks fine, however I don't see the same, and nor does GH.
> > > > >
> > > > > What version of macOS are you using?
> > > > >
> > > > > On Thu, 30 Jun 2022 at 12:52, Gary Gregory  >
> > > wrote:
> > > > > >
> > > > > > With the 1.1.0 tagm I get:
> > > > > >
> > > > > >  garydgregory@xxx  ~/git/commons-crypto  ➦ 3b2561b  java -cp
> > > > > > target/classes org.apache.commons.crypto.Crypto
> > > > > > Apache Commons Crypto 1.1.0
> > > > > > Native code loaded OK: 1.1.0
> > > > > > Native name: Apache Commons Crypto
> > > > > > Native built: Jun 30 2022
> > > > > > OpenSSL library loaded OK, version: 0x1010107f
> > > > > > OpenSSL library info: OpenSSL 1.1.1g  21 Apr 2020
> > > > > > Random instance created OK:
> > > > > > org.apache.commons.crypto.random.OpenSslCryptoRandom@266474c2
> > > > > > Cipher AES/CTR/NoPadding instance created OK:
> > > > > > org.apache.commons.crypto.cipher.OpenSslCipher@66d3c617
> > > > > > Additional OpenSSL_version(n) details:
> > > > > > 1: compiler: clang -fPIC -arch x86_64 -O3 -Wall -DL_ENDIAN
> > > > > > -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2
> > > > > > -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5
> -DOPENSSL_BN_ASM_GF2m
> > > > > > -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM
> > > > > > -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
> > > > > > -DX25519_ASM -DPOLY1305_ASM -D_REENTRANT -DNDEBUG
> > > > > > 2: built on: Tue Apr 21 13:30:00 2020 UTC
> > > > > > 3: platform: darwin64-x86_64-cc
> > > > > > 4: OPENSSLDIR: "/usr/local/etc/openssl@1.1"
> > > > > > 5: ENGINESDIR: "/usr/local/Cellar/openssl@1.1
> > > /1.1.1g/lib/engines-1.1"
> > > > > >
> > > > > > and
> > > > > >
> > > > > >  garydgregory@xxx ~/git/commons-crypto  ➦ 3b2561b  mvn -q
> > > exec:java
> > > > > > -D"exec.mainClass=org.apache.commons.crypto.jna.OpenSslJna"
> > > > > > isEnabled(): true
> > > > > > initialisationError(): null
> > > > > >
> > > > > > Gary
> > > > > >
> > > > > > On Thu, Jun 30, 2022 at 7:18 AM sebb  wrote:
> > > > > > >
> > > > > > > Yes, 1.1.0 builds OK on macOS, but the sample classes fail.
> > > > > > >
> > > > > > > As previously noted, please try:
> > > > > > > java -cp target/classes org.apache.commons.crypto.Crypto
> > > > > > > and
> > > > > > > mvn -q exec:java
> > > > > -D"exec.mainClass=org.apache.commons.crypto.jna.OpenSslJna"
> > > > > > >
> > > > > > > See the GH run I linked yesterday:
> > > > > > >
> https://github.com/apache/commons-crypto/actions/runs/2586011129
> > > > > > >
> > > > > > > I just noticed also that 'openssl version' shows 1.1.1p but the
> > > Crypto
> > > > > > > class shows
> > > > > > > OpenSSL library info: LibreSSL 2.2.9 (on current code; the
> 1.11.0
> > > code
> > > > > crashes)
> > > > > > >
> > > > > > > Something strange is going on; it looks like dlopen is finding
> a
> > > > > > > different version of the dynamic library

Re: [CRYPTO] Problem with JNA on macOS and Windows

2022-06-30 Thread Alex Remily 


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: 0x2000

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 
wrote:

> Le jeu. 30 juin 2022 à 23:35, sebb  a écrit :
> >
> > On Thu, 30 Jun 2022 at 16:21, Alex Remily  wrote:
> > >
> > >  > > 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
>
>

Re: [CRYPTO] Problem with JNA on macOS and Windows

2022-06-30 Thread Gilles Sadowski 
Le jeu. 30 juin 2022 à 23:35, sebb  a écrit :
>
> On Thu, 30 Jun 2022 at 16:21, Alex Remily  wrote:
> >
> >  > 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

Re: [CRYPTO] Problem with JNA on macOS and Windows

2022-06-30 Thread sebb 
On Thu, 30 Jun 2022 at 16:21, Alex Remily  wrote:
>
>  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.

If you use getenv within the JNI C code, it does not see any of the
library-related environment variables.

It looks like DYLD_* is dropped, along with LD_LIBRARY_PATH.

There is some strange behaviour with export as well.
Try the following:

export LD_LIBRART_PATH=/usr/lib
export LD_LIBRARY_PATH=/usr/lib
env | grep LIBRAR

I get:

LD_LIBRART_PATH=/usr/lib

Similarly with DYLD_*

I think we may need to allow the user to provide the full path name to
the crypto library.

> On Thu, Jun 30, 2022 at 9:39 AM sebb  wrote:
>
> > I've started copying bits of the C code to create a standalone tool to
> > load the dll and report some info.
> >
> > No idea why yet, but it behaves differently from basically the same
> > code when run via JNI.
> >
> > For example, the standalone code takes note of LD_LIBRARY_PATH when
> > loading the dll, whereas Java apparently does not.
> >
> > On Thu, 30 Jun 2022 at 13:22, Alex Remily  wrote:
> > >
> > > I also get the "Error looking up function 'ENGINE_load_rdrand'" when I
> > run
> > > the Jna test class from the command line.  Interesting.  dlopen finds the
> > > LibreSSL when run from the CLI.
> > >
> > > On Thu, Jun 30, 2022 at 8:02 AM sebb  wrote:
> > >
> > > > That looks fine, however I don't see the same, and nor does GH.
> > > >
> > > > What version of macOS are you using?
> > > >
> > > > On Thu, 30 Jun 2022 at 12:52, Gary Gregory 
> > wrote:
> > > > >
> > > > > With the 1.1.0 tagm I get:
> > > > >
> > > > >  garydgregory@xxx  ~/git/commons-crypto  ➦ 3b2561b  java -cp
> > > > > target/classes org.apache.commons.crypto.Crypto
> > > > > Apache Commons Crypto 1.1.0
> > > > > Native code loaded OK: 1.1.0
> > > > > Native name: Apache Commons Crypto
> > > > > Native built: Jun 30 2022
> > > > > OpenSSL library loaded OK, version: 0x1010107f
> > > > > OpenSSL library info: OpenSSL 1.1.1g  21 Apr 2020
> > > > > Random instance created OK:
> > > > > org.apache.commons.crypto.random.OpenSslCryptoRandom@266474c2
> > > > > Cipher AES/CTR/NoPadding instance created OK:
> > > > > org.apache.commons.crypto.cipher.OpenSslCipher@66d3c617
> > > > > Additional OpenSSL_version(n) details:
> > > > > 1: compiler: clang -fPIC -arch x86_64 -O3 -Wall -DL_ENDIAN
> > > > > -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2
> > > > > -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
> > > > > -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM
> > > > > -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
> > > > > -DX25519_ASM -DPOLY1305_ASM -D_REENTRANT -DNDEBUG
> > > > > 2: built on: Tue Apr 21 13:30:00 2020 UTC
> > > > > 3: platform: darwin64-x86_64-cc
> > > > > 4: OPENSSLDIR: "/usr/local/etc/openssl@1.1"
> > > > > 5: ENGINESDIR: "/usr/local/Cellar/openssl@1.1
> > /1.1.1g/lib/engines-1.1"
> > > > >
> > > > > and
> > > > >
> > > > >  garydgregory@xxx ~/git/commons-crypto  ➦ 3b2561b  mvn -q
> > exec:java
> > > > > -D"exec.mainClass=org.apache.commons.crypto.jna.OpenSslJna"
> > > > > isEnabled(): true
> > > > > initialisationError(): null
> > > > >
> > > > > Gary
> > > > >
> > > > > On Thu, Jun 30, 2022 at 7:18 AM sebb  wrote:
> > > > > >
> > > > > > Yes, 1.1.0 builds OK on macOS, but the sample classes fail.
> > > > > >
> > > > > > As previously noted, please try:
> > > > > > java -cp target/classes org.apache.commons.crypto.Crypto
> > > > > > and
> > > > > > mvn -q exec:java
> > > > -D"exec.mainClass=org.apache.commons.crypto.jna.OpenSslJna"
> > > > > >
> > > > > > See the GH run I linked yesterday:
> > > > > > https://github.com/apache/commons-crypto/actions/runs/2586011129
> > > > > >
> > > > > > I just noticed also that 'openssl version' shows 1.1.1p but the
> > Crypto
> > > > > > class shows
> > > > > > OpenSSL library info: LibreSSL 2.2.9 (on current code; the 1.11.0
> > code
> > > > crashes)
> > > > > >
> > > > > > Something strange is going on; it looks like dlopen is finding a
> > > > > > different version of the dynamic library from the default CLI.
> > > > > > I have the same issue on my mac.
> > > > > >
> > > > > > On Thu, 30 Jun 2022 at 01:50, Gary Gregory  > >
> > > > wrote:
> > > > > > >
> > > > > > > FWIW, I just checked out the rel/commons-crypto-1.1.0 on macOS
> > and
> > > > ran
> > > > > > > 'mvn clean verify' and everything built just fine.
> > > > > > >
> > > > > > > The Maven ant-run output was:
> > > > > > >
> > > > > > > [INFO] --- maven-antrun-plugin:1.8:run (make) @ commons-crypto
> > ---
> > > > >

Re: [collections] JMH results for IndexedLinkedList

2022-06-30 Thread Gilles Sadowski 
Hello.

Le jeu. 30 juin 2022 à 07:54, Rodion Efremov  a écrit :
>
> Hi Matt and community,
>
> Have you take a look at my work? If so, what do you think?

Perhaps you missed that feedback:
  https://markmail.org/message/y3tozjdke2ivz3dr

>
> Best regards,
> rodde
>
> to 23.6.2022 klo 19.06 Matt Juntunen  kirjoitti:
>
> > Hello,
> >
> > Thanks for providing the data here. I will hopefully have time to take
> > a look at this over the weekend. Send me a ping here on the dev list
> > if you don't hear back from me (or someone else) within a week.
> >
> > Regards,
> > Matt J
> >
> > On Tue, Jun 21, 2022 at 7:22 AM Rodion Efremov 
> > wrote:
> > >
> > > Hi,
> > >
> > > Data structure: IndexedLinkedList
> > > 
> > > Benchmark: IndexedLinkedListBenchmark
> > > 
> > >
> > > Benchmark output:
> > > https://github.com/coderodde/indexedLinkedList/#benchmark-output
> > >
> > > From the benchmark output, we can judge that IndexedLinkedList
> > outperforms
> > > both java.util.LinkedList and the Apache Commons Collections TreeList.
> > It,
> > > however, does not seem to supersede the java.util.ArrayList.
> > >
> > > Basically, I would expect the IndexedLinkedList to beat the ArrayList
> > where
> > > we have a lot of following operations:
> > >
> > >- addFirst(E)
> > >- add(int, E)
> > >- remove(int)
> > >
> > > So, what do you think? I am getting anywhere with that?
> > >
> > > Best regards,
> > > rodde

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [CRYPTO] Problem with JNA on macOS and Windows

2022-06-30 Thread Alex Remily 


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.

On Thu, Jun 30, 2022 at 9:39 AM sebb  wrote:

> I've started copying bits of the C code to create a standalone tool to
> load the dll and report some info.
>
> No idea why yet, but it behaves differently from basically the same
> code when run via JNI.
>
> For example, the standalone code takes note of LD_LIBRARY_PATH when
> loading the dll, whereas Java apparently does not.
>
> On Thu, 30 Jun 2022 at 13:22, Alex Remily  wrote:
> >
> > I also get the "Error looking up function 'ENGINE_load_rdrand'" when I
> run
> > the Jna test class from the command line.  Interesting.  dlopen finds the
> > LibreSSL when run from the CLI.
> >
> > On Thu, Jun 30, 2022 at 8:02 AM sebb  wrote:
> >
> > > That looks fine, however I don't see the same, and nor does GH.
> > >
> > > What version of macOS are you using?
> > >
> > > On Thu, 30 Jun 2022 at 12:52, Gary Gregory 
> wrote:
> > > >
> > > > With the 1.1.0 tagm I get:
> > > >
> > > >  garydgregory@xxx  ~/git/commons-crypto  ➦ 3b2561b  java -cp
> > > > target/classes org.apache.commons.crypto.Crypto
> > > > Apache Commons Crypto 1.1.0
> > > > Native code loaded OK: 1.1.0
> > > > Native name: Apache Commons Crypto
> > > > Native built: Jun 30 2022
> > > > OpenSSL library loaded OK, version: 0x1010107f
> > > > OpenSSL library info: OpenSSL 1.1.1g  21 Apr 2020
> > > > Random instance created OK:
> > > > org.apache.commons.crypto.random.OpenSslCryptoRandom@266474c2
> > > > Cipher AES/CTR/NoPadding instance created OK:
> > > > org.apache.commons.crypto.cipher.OpenSslCipher@66d3c617
> > > > Additional OpenSSL_version(n) details:
> > > > 1: compiler: clang -fPIC -arch x86_64 -O3 -Wall -DL_ENDIAN
> > > > -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2
> > > > -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
> > > > -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM
> > > > -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
> > > > -DX25519_ASM -DPOLY1305_ASM -D_REENTRANT -DNDEBUG
> > > > 2: built on: Tue Apr 21 13:30:00 2020 UTC
> > > > 3: platform: darwin64-x86_64-cc
> > > > 4: OPENSSLDIR: "/usr/local/etc/openssl@1.1"
> > > > 5: ENGINESDIR: "/usr/local/Cellar/openssl@1.1
> /1.1.1g/lib/engines-1.1"
> > > >
> > > > and
> > > >
> > > >  garydgregory@xxx ~/git/commons-crypto  ➦ 3b2561b  mvn -q
> exec:java
> > > > -D"exec.mainClass=org.apache.commons.crypto.jna.OpenSslJna"
> > > > isEnabled(): true
> > > > initialisationError(): null
> > > >
> > > > Gary
> > > >
> > > > On Thu, Jun 30, 2022 at 7:18 AM sebb  wrote:
> > > > >
> > > > > Yes, 1.1.0 builds OK on macOS, but the sample classes fail.
> > > > >
> > > > > As previously noted, please try:
> > > > > java -cp target/classes org.apache.commons.crypto.Crypto
> > > > > and
> > > > > mvn -q exec:java
> > > -D"exec.mainClass=org.apache.commons.crypto.jna.OpenSslJna"
> > > > >
> > > > > See the GH run I linked yesterday:
> > > > > https://github.com/apache/commons-crypto/actions/runs/2586011129
> > > > >
> > > > > I just noticed also that 'openssl version' shows 1.1.1p but the
> Crypto
> > > > > class shows
> > > > > OpenSSL library info: LibreSSL 2.2.9 (on current code; the 1.11.0
> code
> > > crashes)
> > > > >
> > > > > Something strange is going on; it looks like dlopen is finding a
> > > > > different version of the dynamic library from the default CLI.
> > > > > I have the same issue on my mac.
> > > > >
> > > > > On Thu, 30 Jun 2022 at 01:50, Gary Gregory  >
> > > wrote:
> > > > > >
> > > > > > FWIW, I just checked out the rel/commons-crypto-1.1.0 on macOS
> and
> > > ran
> > > > > > 'mvn clean verify' and everything built just fine.
> > > > > >
> > > > > > The Maven ant-run output was:
> > > > > >
> > > > > > [INFO] --- maven-antrun-plugin:1.8:run (make) @ commons-crypto
> ---
> > > > > > [INFO] Executing tasks
> > > > > >
> > > > > > make:
> > > > > >  [exec] "/usr/local/Cellar/openjdk@8/1.8.0+322/bin/javah"
> -force
> > > > > > -classpath target/classes -o
> > > > > >
> > >
> target/jni-classes/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.h
> > > > > > org.apache.commons.crypto.random.OpenSslCryptoRandomNative
> > > > > >  [exec] gcc -arch x86_64 -Ilib/inc_mac
> > > > > > -I"/usr/local/Cellar/openjdk@8/1.8.0+322/include" -O2 -fPIC
> > > > > > -mmacosx-version-min=10.7 -fvisibility=hidden
> -I/usr/local/include
> > > > > > -I/usr/local/opt/openssl/include -Ilib/include -I/usr/include
> > > > > > -I"src/main/native/org/apache/commons/crypto/"
> > > > > > -I"/usr/local/Cellar/openjdk@8
> > >

Re: [CRYPTO] Problem with JNA on macOS and Windows

2022-06-30 Thread sebb 
I've started copying bits of the C code to create a standalone tool to
load the dll and report some info.

No idea why yet, but it behaves differently from basically the same
code when run via JNI.

For example, the standalone code takes note of LD_LIBRARY_PATH when
loading the dll, whereas Java apparently does not.

On Thu, 30 Jun 2022 at 13:22, Alex Remily  wrote:
>
> I also get the "Error looking up function 'ENGINE_load_rdrand'" when I run
> the Jna test class from the command line.  Interesting.  dlopen finds the
> LibreSSL when run from the CLI.
>
> On Thu, Jun 30, 2022 at 8:02 AM sebb  wrote:
>
> > That looks fine, however I don't see the same, and nor does GH.
> >
> > What version of macOS are you using?
> >
> > On Thu, 30 Jun 2022 at 12:52, Gary Gregory  wrote:
> > >
> > > With the 1.1.0 tagm I get:
> > >
> > >  garydgregory@xxx  ~/git/commons-crypto  ➦ 3b2561b  java -cp
> > > target/classes org.apache.commons.crypto.Crypto
> > > Apache Commons Crypto 1.1.0
> > > Native code loaded OK: 1.1.0
> > > Native name: Apache Commons Crypto
> > > Native built: Jun 30 2022
> > > OpenSSL library loaded OK, version: 0x1010107f
> > > OpenSSL library info: OpenSSL 1.1.1g  21 Apr 2020
> > > Random instance created OK:
> > > org.apache.commons.crypto.random.OpenSslCryptoRandom@266474c2
> > > Cipher AES/CTR/NoPadding instance created OK:
> > > org.apache.commons.crypto.cipher.OpenSslCipher@66d3c617
> > > Additional OpenSSL_version(n) details:
> > > 1: compiler: clang -fPIC -arch x86_64 -O3 -Wall -DL_ENDIAN
> > > -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2
> > > -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
> > > -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM
> > > -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
> > > -DX25519_ASM -DPOLY1305_ASM -D_REENTRANT -DNDEBUG
> > > 2: built on: Tue Apr 21 13:30:00 2020 UTC
> > > 3: platform: darwin64-x86_64-cc
> > > 4: OPENSSLDIR: "/usr/local/etc/openssl@1.1"
> > > 5: ENGINESDIR: "/usr/local/Cellar/openssl@1.1/1.1.1g/lib/engines-1.1"
> > >
> > > and
> > >
> > >  garydgregory@xxx ~/git/commons-crypto  ➦ 3b2561b  mvn -q exec:java
> > > -D"exec.mainClass=org.apache.commons.crypto.jna.OpenSslJna"
> > > isEnabled(): true
> > > initialisationError(): null
> > >
> > > Gary
> > >
> > > On Thu, Jun 30, 2022 at 7:18 AM sebb  wrote:
> > > >
> > > > Yes, 1.1.0 builds OK on macOS, but the sample classes fail.
> > > >
> > > > As previously noted, please try:
> > > > java -cp target/classes org.apache.commons.crypto.Crypto
> > > > and
> > > > mvn -q exec:java
> > -D"exec.mainClass=org.apache.commons.crypto.jna.OpenSslJna"
> > > >
> > > > See the GH run I linked yesterday:
> > > > https://github.com/apache/commons-crypto/actions/runs/2586011129
> > > >
> > > > I just noticed also that 'openssl version' shows 1.1.1p but the Crypto
> > > > class shows
> > > > OpenSSL library info: LibreSSL 2.2.9 (on current code; the 1.11.0 code
> > crashes)
> > > >
> > > > Something strange is going on; it looks like dlopen is finding a
> > > > different version of the dynamic library from the default CLI.
> > > > I have the same issue on my mac.
> > > >
> > > > On Thu, 30 Jun 2022 at 01:50, Gary Gregory 
> > wrote:
> > > > >
> > > > > FWIW, I just checked out the rel/commons-crypto-1.1.0 on macOS and
> > ran
> > > > > 'mvn clean verify' and everything built just fine.
> > > > >
> > > > > The Maven ant-run output was:
> > > > >
> > > > > [INFO] --- maven-antrun-plugin:1.8:run (make) @ commons-crypto ---
> > > > > [INFO] Executing tasks
> > > > >
> > > > > make:
> > > > >  [exec] "/usr/local/Cellar/openjdk@8/1.8.0+322/bin/javah" -force
> > > > > -classpath target/classes -o
> > > > >
> > target/jni-classes/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.h
> > > > > org.apache.commons.crypto.random.OpenSslCryptoRandomNative
> > > > >  [exec] gcc -arch x86_64 -Ilib/inc_mac
> > > > > -I"/usr/local/Cellar/openjdk@8/1.8.0+322/include" -O2 -fPIC
> > > > > -mmacosx-version-min=10.7 -fvisibility=hidden -I/usr/local/include
> > > > > -I/usr/local/opt/openssl/include -Ilib/include -I/usr/include
> > > > > -I"src/main/native/org/apache/commons/crypto/"
> > > > > -I"/usr/local/Cellar/openjdk@8
> > /1.8.0+322/libexec/openjdk.jdk/Contents/Home/include/darwin"
> > > > > -I"target/jni-classes/org/apache/commons/crypto/cipher"
> > > > > -I"target/jni-classes/org/apache/commons/crypto/random" -c
> > > > >
> > src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c
> > > > > -o target/commons-crypto-1.1.0-Mac-x86_64/OpenSslCryptoRandomNative.o
> > > > >  [exec] "/usr/local/Cellar/openjdk@8/1.8.0+322/bin/javah" -force
> > > > > -classpath target/classes -o
> > > > > target/jni-classes/org/apache/commons/crypto/cipher/OpenSslNative.h
> > > > > org.apache.commons.crypto.cipher.OpenSslNative
> > > > >  [exec] gcc -arch x86_64 -Ilib/inc_mac
> > > > > -I"/usr/local/Cellar/openjdk@8/1.8.0+322/include" -O2 -fPIC
> >

Re: [CRYPTO] Problem with JNA on macOS and Windows

2022-06-30 Thread Gary Gregory 
On Thu, Jun 30, 2022 at 8:02 AM sebb  wrote:
>
> That looks fine, however I don't see the same, and nor does GH.
>
> What version of macOS are you using?

uname says: Darwin xxx 21.5.0 Darwin Kernel Version 21.5.0: Tue Apr 26
21:08:22 PDT 2022; root:xnu-8020.121.3~4/RELEASE_X86_64 x86_64

UI says 12.4

Gary

>
> On Thu, 30 Jun 2022 at 12:52, Gary Gregory  wrote:
> >
> > With the 1.1.0 tagm I get:
> >
> >  garydgregory@xxx  ~/git/commons-crypto  ➦ 3b2561b  java -cp
> > target/classes org.apache.commons.crypto.Crypto
> > Apache Commons Crypto 1.1.0
> > Native code loaded OK: 1.1.0
> > Native name: Apache Commons Crypto
> > Native built: Jun 30 2022
> > OpenSSL library loaded OK, version: 0x1010107f
> > OpenSSL library info: OpenSSL 1.1.1g  21 Apr 2020
> > Random instance created OK:
> > org.apache.commons.crypto.random.OpenSslCryptoRandom@266474c2
> > Cipher AES/CTR/NoPadding instance created OK:
> > org.apache.commons.crypto.cipher.OpenSslCipher@66d3c617
> > Additional OpenSSL_version(n) details:
> > 1: compiler: clang -fPIC -arch x86_64 -O3 -Wall -DL_ENDIAN
> > -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2
> > -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
> > -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM
> > -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
> > -DX25519_ASM -DPOLY1305_ASM -D_REENTRANT -DNDEBUG
> > 2: built on: Tue Apr 21 13:30:00 2020 UTC
> > 3: platform: darwin64-x86_64-cc
> > 4: OPENSSLDIR: "/usr/local/etc/openssl@1.1"
> > 5: ENGINESDIR: "/usr/local/Cellar/openssl@1.1/1.1.1g/lib/engines-1.1"
> >
> > and
> >
> >  garydgregory@xxx ~/git/commons-crypto  ➦ 3b2561b  mvn -q exec:java
> > -D"exec.mainClass=org.apache.commons.crypto.jna.OpenSslJna"
> > isEnabled(): true
> > initialisationError(): null
> >
> > Gary
> >
> > On Thu, Jun 30, 2022 at 7:18 AM sebb  wrote:
> > >
> > > Yes, 1.1.0 builds OK on macOS, but the sample classes fail.
> > >
> > > As previously noted, please try:
> > > java -cp target/classes org.apache.commons.crypto.Crypto
> > > and
> > > mvn -q exec:java 
> > > -D"exec.mainClass=org.apache.commons.crypto.jna.OpenSslJna"
> > >
> > > See the GH run I linked yesterday:
> > > https://github.com/apache/commons-crypto/actions/runs/2586011129
> > >
> > > I just noticed also that 'openssl version' shows 1.1.1p but the Crypto
> > > class shows
> > > OpenSSL library info: LibreSSL 2.2.9 (on current code; the 1.11.0 code 
> > > crashes)
> > >
> > > Something strange is going on; it looks like dlopen is finding a
> > > different version of the dynamic library from the default CLI.
> > > I have the same issue on my mac.
> > >
> > > On Thu, 30 Jun 2022 at 01:50, Gary Gregory  wrote:
> > > >
> > > > FWIW, I just checked out the rel/commons-crypto-1.1.0 on macOS and ran
> > > > 'mvn clean verify' and everything built just fine.
> > > >
> > > > The Maven ant-run output was:
> > > >
> > > > [INFO] --- maven-antrun-plugin:1.8:run (make) @ commons-crypto ---
> > > > [INFO] Executing tasks
> > > >
> > > > make:
> > > >  [exec] "/usr/local/Cellar/openjdk@8/1.8.0+322/bin/javah" -force
> > > > -classpath target/classes -o
> > > > target/jni-classes/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.h
> > > > org.apache.commons.crypto.random.OpenSslCryptoRandomNative
> > > >  [exec] gcc -arch x86_64 -Ilib/inc_mac
> > > > -I"/usr/local/Cellar/openjdk@8/1.8.0+322/include" -O2 -fPIC
> > > > -mmacosx-version-min=10.7 -fvisibility=hidden -I/usr/local/include
> > > > -I/usr/local/opt/openssl/include -Ilib/include -I/usr/include
> > > > -I"src/main/native/org/apache/commons/crypto/"
> > > > -I"/usr/local/Cellar/openjdk@8/1.8.0+322/libexec/openjdk.jdk/Contents/Home/include/darwin"
> > > > -I"target/jni-classes/org/apache/commons/crypto/cipher"
> > > > -I"target/jni-classes/org/apache/commons/crypto/random" -c
> > > > src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c
> > > > -o target/commons-crypto-1.1.0-Mac-x86_64/OpenSslCryptoRandomNative.o
> > > >  [exec] "/usr/local/Cellar/openjdk@8/1.8.0+322/bin/javah" -force
> > > > -classpath target/classes -o
> > > > target/jni-classes/org/apache/commons/crypto/cipher/OpenSslNative.h
> > > > org.apache.commons.crypto.cipher.OpenSslNative
> > > >  [exec] gcc -arch x86_64 -Ilib/inc_mac
> > > > -I"/usr/local/Cellar/openjdk@8/1.8.0+322/include" -O2 -fPIC
> > > > -mmacosx-version-min=10.7 -fvisibility=hidden -I/usr/local/include
> > > > -I/usr/local/opt/openssl/include -Ilib/include -I/usr/include
> > > > -I"src/main/native/org/apache/commons/crypto/"
> > > > -I"/usr/local/Cellar/openjdk@8/1.8.0+322/libexec/openjdk.jdk/Contents/Home/include/darwin"
> > > > -I"target/jni-classes/org/apache/commons/crypto/cipher"
> > > > -I"target/jni-classes/org/apache/commons/crypto/random" -c
> > > > src/main/native/org/apache/commons/crypto/cipher/OpenSslNative.c -o
> > > > target/commons-crypto-1.1.0-Mac-x86_64/OpenSslNative.o
> > > >  [exec]

Re: [CRYPTO] Problem with JNA on macOS and Windows

2022-06-30 Thread Alex Remily 
I also get the "Error looking up function 'ENGINE_load_rdrand'" when I run
the Jna test class from the command line.  Interesting.  dlopen finds the
LibreSSL when run from the CLI.

On Thu, Jun 30, 2022 at 8:02 AM sebb  wrote:

> That looks fine, however I don't see the same, and nor does GH.
>
> What version of macOS are you using?
>
> On Thu, 30 Jun 2022 at 12:52, Gary Gregory  wrote:
> >
> > With the 1.1.0 tagm I get:
> >
> >  garydgregory@xxx  ~/git/commons-crypto  ➦ 3b2561b  java -cp
> > target/classes org.apache.commons.crypto.Crypto
> > Apache Commons Crypto 1.1.0
> > Native code loaded OK: 1.1.0
> > Native name: Apache Commons Crypto
> > Native built: Jun 30 2022
> > OpenSSL library loaded OK, version: 0x1010107f
> > OpenSSL library info: OpenSSL 1.1.1g  21 Apr 2020
> > Random instance created OK:
> > org.apache.commons.crypto.random.OpenSslCryptoRandom@266474c2
> > Cipher AES/CTR/NoPadding instance created OK:
> > org.apache.commons.crypto.cipher.OpenSslCipher@66d3c617
> > Additional OpenSSL_version(n) details:
> > 1: compiler: clang -fPIC -arch x86_64 -O3 -Wall -DL_ENDIAN
> > -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2
> > -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
> > -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM
> > -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
> > -DX25519_ASM -DPOLY1305_ASM -D_REENTRANT -DNDEBUG
> > 2: built on: Tue Apr 21 13:30:00 2020 UTC
> > 3: platform: darwin64-x86_64-cc
> > 4: OPENSSLDIR: "/usr/local/etc/openssl@1.1"
> > 5: ENGINESDIR: "/usr/local/Cellar/openssl@1.1/1.1.1g/lib/engines-1.1"
> >
> > and
> >
> >  garydgregory@xxx ~/git/commons-crypto  ➦ 3b2561b  mvn -q exec:java
> > -D"exec.mainClass=org.apache.commons.crypto.jna.OpenSslJna"
> > isEnabled(): true
> > initialisationError(): null
> >
> > Gary
> >
> > On Thu, Jun 30, 2022 at 7:18 AM sebb  wrote:
> > >
> > > Yes, 1.1.0 builds OK on macOS, but the sample classes fail.
> > >
> > > As previously noted, please try:
> > > java -cp target/classes org.apache.commons.crypto.Crypto
> > > and
> > > mvn -q exec:java
> -D"exec.mainClass=org.apache.commons.crypto.jna.OpenSslJna"
> > >
> > > See the GH run I linked yesterday:
> > > https://github.com/apache/commons-crypto/actions/runs/2586011129
> > >
> > > I just noticed also that 'openssl version' shows 1.1.1p but the Crypto
> > > class shows
> > > OpenSSL library info: LibreSSL 2.2.9 (on current code; the 1.11.0 code
> crashes)
> > >
> > > Something strange is going on; it looks like dlopen is finding a
> > > different version of the dynamic library from the default CLI.
> > > I have the same issue on my mac.
> > >
> > > On Thu, 30 Jun 2022 at 01:50, Gary Gregory 
> wrote:
> > > >
> > > > FWIW, I just checked out the rel/commons-crypto-1.1.0 on macOS and
> ran
> > > > 'mvn clean verify' and everything built just fine.
> > > >
> > > > The Maven ant-run output was:
> > > >
> > > > [INFO] --- maven-antrun-plugin:1.8:run (make) @ commons-crypto ---
> > > > [INFO] Executing tasks
> > > >
> > > > make:
> > > >  [exec] "/usr/local/Cellar/openjdk@8/1.8.0+322/bin/javah" -force
> > > > -classpath target/classes -o
> > > >
> target/jni-classes/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.h
> > > > org.apache.commons.crypto.random.OpenSslCryptoRandomNative
> > > >  [exec] gcc -arch x86_64 -Ilib/inc_mac
> > > > -I"/usr/local/Cellar/openjdk@8/1.8.0+322/include" -O2 -fPIC
> > > > -mmacosx-version-min=10.7 -fvisibility=hidden -I/usr/local/include
> > > > -I/usr/local/opt/openssl/include -Ilib/include -I/usr/include
> > > > -I"src/main/native/org/apache/commons/crypto/"
> > > > -I"/usr/local/Cellar/openjdk@8
> /1.8.0+322/libexec/openjdk.jdk/Contents/Home/include/darwin"
> > > > -I"target/jni-classes/org/apache/commons/crypto/cipher"
> > > > -I"target/jni-classes/org/apache/commons/crypto/random" -c
> > > >
> src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c
> > > > -o target/commons-crypto-1.1.0-Mac-x86_64/OpenSslCryptoRandomNative.o
> > > >  [exec] "/usr/local/Cellar/openjdk@8/1.8.0+322/bin/javah" -force
> > > > -classpath target/classes -o
> > > > target/jni-classes/org/apache/commons/crypto/cipher/OpenSslNative.h
> > > > org.apache.commons.crypto.cipher.OpenSslNative
> > > >  [exec] gcc -arch x86_64 -Ilib/inc_mac
> > > > -I"/usr/local/Cellar/openjdk@8/1.8.0+322/include" -O2 -fPIC
> > > > -mmacosx-version-min=10.7 -fvisibility=hidden -I/usr/local/include
> > > > -I/usr/local/opt/openssl/include -Ilib/include -I/usr/include
> > > > -I"src/main/native/org/apache/commons/crypto/"
> > > > -I"/usr/local/Cellar/openjdk@8
> /1.8.0+322/libexec/openjdk.jdk/Contents/Home/include/darwin"
> > > > -I"target/jni-classes/org/apache/commons/crypto/cipher"
> > > > -I"target/jni-classes/org/apache/commons/crypto/random" -c
> > > > src/main/native/org/apache/commons/crypto/cipher/OpenSslNative.c -o
> > > > target/commons-crypto-1.1.0-Mac-x86_64/OpenSslNative.o
> > > >

Re: [CRYPTO] Problem with JNA on macOS and Windows

2022-06-30 Thread sebb 
That looks fine, however I don't see the same, and nor does GH.

What version of macOS are you using?

On Thu, 30 Jun 2022 at 12:52, Gary Gregory  wrote:
>
> With the 1.1.0 tagm I get:
>
>  garydgregory@xxx  ~/git/commons-crypto  ➦ 3b2561b  java -cp
> target/classes org.apache.commons.crypto.Crypto
> Apache Commons Crypto 1.1.0
> Native code loaded OK: 1.1.0
> Native name: Apache Commons Crypto
> Native built: Jun 30 2022
> OpenSSL library loaded OK, version: 0x1010107f
> OpenSSL library info: OpenSSL 1.1.1g  21 Apr 2020
> Random instance created OK:
> org.apache.commons.crypto.random.OpenSslCryptoRandom@266474c2
> Cipher AES/CTR/NoPadding instance created OK:
> org.apache.commons.crypto.cipher.OpenSslCipher@66d3c617
> Additional OpenSSL_version(n) details:
> 1: compiler: clang -fPIC -arch x86_64 -O3 -Wall -DL_ENDIAN
> -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2
> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM
> -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
> -DX25519_ASM -DPOLY1305_ASM -D_REENTRANT -DNDEBUG
> 2: built on: Tue Apr 21 13:30:00 2020 UTC
> 3: platform: darwin64-x86_64-cc
> 4: OPENSSLDIR: "/usr/local/etc/openssl@1.1"
> 5: ENGINESDIR: "/usr/local/Cellar/openssl@1.1/1.1.1g/lib/engines-1.1"
>
> and
>
>  garydgregory@xxx ~/git/commons-crypto  ➦ 3b2561b  mvn -q exec:java
> -D"exec.mainClass=org.apache.commons.crypto.jna.OpenSslJna"
> isEnabled(): true
> initialisationError(): null
>
> Gary
>
> On Thu, Jun 30, 2022 at 7:18 AM sebb  wrote:
> >
> > Yes, 1.1.0 builds OK on macOS, but the sample classes fail.
> >
> > As previously noted, please try:
> > java -cp target/classes org.apache.commons.crypto.Crypto
> > and
> > mvn -q exec:java -D"exec.mainClass=org.apache.commons.crypto.jna.OpenSslJna"
> >
> > See the GH run I linked yesterday:
> > https://github.com/apache/commons-crypto/actions/runs/2586011129
> >
> > I just noticed also that 'openssl version' shows 1.1.1p but the Crypto
> > class shows
> > OpenSSL library info: LibreSSL 2.2.9 (on current code; the 1.11.0 code 
> > crashes)
> >
> > Something strange is going on; it looks like dlopen is finding a
> > different version of the dynamic library from the default CLI.
> > I have the same issue on my mac.
> >
> > On Thu, 30 Jun 2022 at 01:50, Gary Gregory  wrote:
> > >
> > > FWIW, I just checked out the rel/commons-crypto-1.1.0 on macOS and ran
> > > 'mvn clean verify' and everything built just fine.
> > >
> > > The Maven ant-run output was:
> > >
> > > [INFO] --- maven-antrun-plugin:1.8:run (make) @ commons-crypto ---
> > > [INFO] Executing tasks
> > >
> > > make:
> > >  [exec] "/usr/local/Cellar/openjdk@8/1.8.0+322/bin/javah" -force
> > > -classpath target/classes -o
> > > target/jni-classes/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.h
> > > org.apache.commons.crypto.random.OpenSslCryptoRandomNative
> > >  [exec] gcc -arch x86_64 -Ilib/inc_mac
> > > -I"/usr/local/Cellar/openjdk@8/1.8.0+322/include" -O2 -fPIC
> > > -mmacosx-version-min=10.7 -fvisibility=hidden -I/usr/local/include
> > > -I/usr/local/opt/openssl/include -Ilib/include -I/usr/include
> > > -I"src/main/native/org/apache/commons/crypto/"
> > > -I"/usr/local/Cellar/openjdk@8/1.8.0+322/libexec/openjdk.jdk/Contents/Home/include/darwin"
> > > -I"target/jni-classes/org/apache/commons/crypto/cipher"
> > > -I"target/jni-classes/org/apache/commons/crypto/random" -c
> > > src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c
> > > -o target/commons-crypto-1.1.0-Mac-x86_64/OpenSslCryptoRandomNative.o
> > >  [exec] "/usr/local/Cellar/openjdk@8/1.8.0+322/bin/javah" -force
> > > -classpath target/classes -o
> > > target/jni-classes/org/apache/commons/crypto/cipher/OpenSslNative.h
> > > org.apache.commons.crypto.cipher.OpenSslNative
> > >  [exec] gcc -arch x86_64 -Ilib/inc_mac
> > > -I"/usr/local/Cellar/openjdk@8/1.8.0+322/include" -O2 -fPIC
> > > -mmacosx-version-min=10.7 -fvisibility=hidden -I/usr/local/include
> > > -I/usr/local/opt/openssl/include -Ilib/include -I/usr/include
> > > -I"src/main/native/org/apache/commons/crypto/"
> > > -I"/usr/local/Cellar/openjdk@8/1.8.0+322/libexec/openjdk.jdk/Contents/Home/include/darwin"
> > > -I"target/jni-classes/org/apache/commons/crypto/cipher"
> > > -I"target/jni-classes/org/apache/commons/crypto/random" -c
> > > src/main/native/org/apache/commons/crypto/cipher/OpenSslNative.c -o
> > > target/commons-crypto-1.1.0-Mac-x86_64/OpenSslNative.o
> > >  [exec] "/usr/local/Cellar/openjdk@8/1.8.0+322/bin/javah" -force
> > > -classpath target/classes -o
> > > target/jni-classes/org/apache/commons/crypto/OpenSslInfoNative.h
> > > org.apache.commons.crypto.OpenSslInfoNative
> > >  [exec] gcc -arch x86_64 -Ilib/inc_mac
> > > -I"/usr/local/Cellar/openjdk@8/1.8.0+322/include" -O2 -fPIC
> > > -mmacosx-version-min=10.7 -fvisibility=hidden -I/usr/local/include
> > >

Re: [CRYPTO] Problem with JNA on macOS and Windows

2022-06-30 Thread Gary Gregory 
With the 1.1.0 tagm I get:

 garydgregory@xxx  ~/git/commons-crypto  ➦ 3b2561b  java -cp
target/classes org.apache.commons.crypto.Crypto
Apache Commons Crypto 1.1.0
Native code loaded OK: 1.1.0
Native name: Apache Commons Crypto
Native built: Jun 30 2022
OpenSSL library loaded OK, version: 0x1010107f
OpenSSL library info: OpenSSL 1.1.1g  21 Apr 2020
Random instance created OK:
org.apache.commons.crypto.random.OpenSslCryptoRandom@266474c2
Cipher AES/CTR/NoPadding instance created OK:
org.apache.commons.crypto.cipher.OpenSslCipher@66d3c617
Additional OpenSSL_version(n) details:
1: compiler: clang -fPIC -arch x86_64 -O3 -Wall -DL_ENDIAN
-DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM
-DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
-DX25519_ASM -DPOLY1305_ASM -D_REENTRANT -DNDEBUG
2: built on: Tue Apr 21 13:30:00 2020 UTC
3: platform: darwin64-x86_64-cc
4: OPENSSLDIR: "/usr/local/etc/openssl@1.1"
5: ENGINESDIR: "/usr/local/Cellar/openssl@1.1/1.1.1g/lib/engines-1.1"

and

 garydgregory@xxx ~/git/commons-crypto  ➦ 3b2561b  mvn -q exec:java
-D"exec.mainClass=org.apache.commons.crypto.jna.OpenSslJna"
isEnabled(): true
initialisationError(): null

Gary

On Thu, Jun 30, 2022 at 7:18 AM sebb  wrote:
>
> Yes, 1.1.0 builds OK on macOS, but the sample classes fail.
>
> As previously noted, please try:
> java -cp target/classes org.apache.commons.crypto.Crypto
> and
> mvn -q exec:java -D"exec.mainClass=org.apache.commons.crypto.jna.OpenSslJna"
>
> See the GH run I linked yesterday:
> https://github.com/apache/commons-crypto/actions/runs/2586011129
>
> I just noticed also that 'openssl version' shows 1.1.1p but the Crypto
> class shows
> OpenSSL library info: LibreSSL 2.2.9 (on current code; the 1.11.0 code 
> crashes)
>
> Something strange is going on; it looks like dlopen is finding a
> different version of the dynamic library from the default CLI.
> I have the same issue on my mac.
>
> On Thu, 30 Jun 2022 at 01:50, Gary Gregory  wrote:
> >
> > FWIW, I just checked out the rel/commons-crypto-1.1.0 on macOS and ran
> > 'mvn clean verify' and everything built just fine.
> >
> > The Maven ant-run output was:
> >
> > [INFO] --- maven-antrun-plugin:1.8:run (make) @ commons-crypto ---
> > [INFO] Executing tasks
> >
> > make:
> >  [exec] "/usr/local/Cellar/openjdk@8/1.8.0+322/bin/javah" -force
> > -classpath target/classes -o
> > target/jni-classes/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.h
> > org.apache.commons.crypto.random.OpenSslCryptoRandomNative
> >  [exec] gcc -arch x86_64 -Ilib/inc_mac
> > -I"/usr/local/Cellar/openjdk@8/1.8.0+322/include" -O2 -fPIC
> > -mmacosx-version-min=10.7 -fvisibility=hidden -I/usr/local/include
> > -I/usr/local/opt/openssl/include -Ilib/include -I/usr/include
> > -I"src/main/native/org/apache/commons/crypto/"
> > -I"/usr/local/Cellar/openjdk@8/1.8.0+322/libexec/openjdk.jdk/Contents/Home/include/darwin"
> > -I"target/jni-classes/org/apache/commons/crypto/cipher"
> > -I"target/jni-classes/org/apache/commons/crypto/random" -c
> > src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c
> > -o target/commons-crypto-1.1.0-Mac-x86_64/OpenSslCryptoRandomNative.o
> >  [exec] "/usr/local/Cellar/openjdk@8/1.8.0+322/bin/javah" -force
> > -classpath target/classes -o
> > target/jni-classes/org/apache/commons/crypto/cipher/OpenSslNative.h
> > org.apache.commons.crypto.cipher.OpenSslNative
> >  [exec] gcc -arch x86_64 -Ilib/inc_mac
> > -I"/usr/local/Cellar/openjdk@8/1.8.0+322/include" -O2 -fPIC
> > -mmacosx-version-min=10.7 -fvisibility=hidden -I/usr/local/include
> > -I/usr/local/opt/openssl/include -Ilib/include -I/usr/include
> > -I"src/main/native/org/apache/commons/crypto/"
> > -I"/usr/local/Cellar/openjdk@8/1.8.0+322/libexec/openjdk.jdk/Contents/Home/include/darwin"
> > -I"target/jni-classes/org/apache/commons/crypto/cipher"
> > -I"target/jni-classes/org/apache/commons/crypto/random" -c
> > src/main/native/org/apache/commons/crypto/cipher/OpenSslNative.c -o
> > target/commons-crypto-1.1.0-Mac-x86_64/OpenSslNative.o
> >  [exec] "/usr/local/Cellar/openjdk@8/1.8.0+322/bin/javah" -force
> > -classpath target/classes -o
> > target/jni-classes/org/apache/commons/crypto/OpenSslInfoNative.h
> > org.apache.commons.crypto.OpenSslInfoNative
> >  [exec] gcc -arch x86_64 -Ilib/inc_mac
> > -I"/usr/local/Cellar/openjdk@8/1.8.0+322/include" -O2 -fPIC
> > -mmacosx-version-min=10.7 -fvisibility=hidden -I/usr/local/include
> > -I/usr/local/opt/openssl/include -Ilib/include -I/usr/include
> > -I"src/main/native/org/apache/commons/crypto/"
> > -I"/usr/local/Cellar/openjdk@8/1.8.0+322/libexec/openjdk.jdk/Contents/Home/include/darwin"
> > -I"target/jni-classes/org/apache/commons/crypto/cipher"
> > -I"target/jni-classes/org/apache/commons/crypto/random"
> > -DVERSION='"1.1.0"' -DPROJECT_NAME='"Apache

Re: [CRYPTO] Problem with JNA on macOS and Windows

2022-06-30 Thread sebb 
On Thu, 30 Jun 2022 at 02:03, Alex Remily  wrote:
>
> Which Mac OS version did you use?  Since I upgraded to BigSur (OS 11) my
> Commons Crypto builds fail.  I think Apple moved a bunch of the developer
> libraries, but I haven't taken the time to troubleshoot.

Note that GH Action macos-latest uses OS 11.6.6 and that compiles the
current code fine.
https://github.com/apache/commons-crypto/actions/runs/2586011129

> On Wed, Jun 29, 2022 at 8:55 PM Gary Gregory  wrote:
>
> > Arg, idiotic line wrapping removed: https://pastebin.com/raw/nPczrrd8
> >
> > Gary
> >
> > On Wed, Jun 29, 2022 at 8:49 PM Gary Gregory 
> > wrote:
> > >
> > > FWIW, I just checked out the rel/commons-crypto-1.1.0 on macOS and ran
> > > 'mvn clean verify' and everything built just fine.
> > >
> > > The Maven ant-run output was:
> > >
> > > [INFO] --- maven-antrun-plugin:1.8:run (make) @ commons-crypto ---
> > > [INFO] Executing tasks
> > >
> > > make:
> > >  [exec] "/usr/local/Cellar/openjdk@8/1.8.0+322/bin/javah" -force
> > > -classpath target/classes -o
> > >
> > target/jni-classes/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.h
> > > org.apache.commons.crypto.random.OpenSslCryptoRandomNative
> > >  [exec] gcc -arch x86_64 -Ilib/inc_mac
> > > -I"/usr/local/Cellar/openjdk@8/1.8.0+322/include" -O2 -fPIC
> > > -mmacosx-version-min=10.7 -fvisibility=hidden -I/usr/local/include
> > > -I/usr/local/opt/openssl/include -Ilib/include -I/usr/include
> > > -I"src/main/native/org/apache/commons/crypto/"
> > > -I"/usr/local/Cellar/openjdk@8
> > /1.8.0+322/libexec/openjdk.jdk/Contents/Home/include/darwin"
> > > -I"target/jni-classes/org/apache/commons/crypto/cipher"
> > > -I"target/jni-classes/org/apache/commons/crypto/random" -c
> > >
> > src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c
> > > -o target/commons-crypto-1.1.0-Mac-x86_64/OpenSslCryptoRandomNative.o
> > >  [exec] "/usr/local/Cellar/openjdk@8/1.8.0+322/bin/javah" -force
> > > -classpath target/classes -o
> > > target/jni-classes/org/apache/commons/crypto/cipher/OpenSslNative.h
> > > org.apache.commons.crypto.cipher.OpenSslNative
> > >  [exec] gcc -arch x86_64 -Ilib/inc_mac
> > > -I"/usr/local/Cellar/openjdk@8/1.8.0+322/include" -O2 -fPIC
> > > -mmacosx-version-min=10.7 -fvisibility=hidden -I/usr/local/include
> > > -I/usr/local/opt/openssl/include -Ilib/include -I/usr/include
> > > -I"src/main/native/org/apache/commons/crypto/"
> > > -I"/usr/local/Cellar/openjdk@8
> > /1.8.0+322/libexec/openjdk.jdk/Contents/Home/include/darwin"
> > > -I"target/jni-classes/org/apache/commons/crypto/cipher"
> > > -I"target/jni-classes/org/apache/commons/crypto/random" -c
> > > src/main/native/org/apache/commons/crypto/cipher/OpenSslNative.c -o
> > > target/commons-crypto-1.1.0-Mac-x86_64/OpenSslNative.o
> > >  [exec] "/usr/local/Cellar/openjdk@8/1.8.0+322/bin/javah" -force
> > > -classpath target/classes -o
> > > target/jni-classes/org/apache/commons/crypto/OpenSslInfoNative.h
> > > org.apache.commons.crypto.OpenSslInfoNative
> > >  [exec] gcc -arch x86_64 -Ilib/inc_mac
> > > -I"/usr/local/Cellar/openjdk@8/1.8.0+322/include" -O2 -fPIC
> > > -mmacosx-version-min=10.7 -fvisibility=hidden -I/usr/local/include
> > > -I/usr/local/opt/openssl/include -Ilib/include -I/usr/include
> > > -I"src/main/native/org/apache/commons/crypto/"
> > > -I"/usr/local/Cellar/openjdk@8
> > /1.8.0+322/libexec/openjdk.jdk/Contents/Home/include/darwin"
> > > -I"target/jni-classes/org/apache/commons/crypto/cipher"
> > > -I"target/jni-classes/org/apache/commons/crypto/random"
> > > -DVERSION='"1.1.0"' -DPROJECT_NAME='"Apache Commons Crypto"'
> > > -I"target/jni-classes/org/apache/commons/crypto" -c
> > > src/main/native/org/apache/commons/crypto/OpenSslInfoNative.c -o
> > > target/commons-crypto-1.1.0-Mac-x86_64/OpenSslInfoNative.o
> > >  [exec] gcc -arch x86_64 -Ilib/inc_mac
> > > -I"/usr/local/Cellar/openjdk@8/1.8.0+322/include" -O2 -fPIC
> > > -mmacosx-version-min=10.7 -fvisibility=hidden -I/usr/local/include
> > > -I/usr/local/opt/openssl/include -Ilib/include  -I/usr/include
> > > -I"/usr/local/Cellar/openjdk@8
> > /1.8.0+322/libexec/openjdk.jdk/Contents/Home/include/darwin"
> > > -I"target/jni-classes/org/apache/commons/crypto/cipher"
> > > -I"target/jni-classes/org/apache/commons/crypto/random" -o
> > > target/commons-crypto-1.1.0-Mac-x86_64/libcommons-crypto.jnilib
> > > target/commons-crypto-1.1.0-Mac-x86_64/OpenSslCryptoRandomNative.o
> > > target/commons-crypto-1.1.0-Mac-x86_64/OpenSslNative.o
> > > target/commons-crypto-1.1.0-Mac-x86_64/OpenSslInfoNative.o -dynamiclib
> > > -L/usr/local/lib
> > >  [exec] strip -x
> > > target/commons-crypto-1.1.0-Mac-x86_64/libcommons-crypto.jnilib
> > >  [exec] cp
> > target/commons-crypto-1.1.0-Mac-x86_64/libcommons-crypto.jnilib
> > >
> > target/classes/org/apache/commons/crypto/native/Mac/x86_64/libcommons-crypto.jnilib
> > >  [exec] cp
> > target/commons-crypto-1.1.0-Mac-x86_64/libcommons-crypto.jnilib
>

Re: [CRYPTO] Problem with JNA on macOS and Windows

2022-06-30 Thread sebb 
Yes, 1.1.0 builds OK on macOS, but the sample classes fail.

As previously noted, please try:
java -cp target/classes org.apache.commons.crypto.Crypto
and
mvn -q exec:java -D"exec.mainClass=org.apache.commons.crypto.jna.OpenSslJna"

See the GH run I linked yesterday:
https://github.com/apache/commons-crypto/actions/runs/2586011129

I just noticed also that 'openssl version' shows 1.1.1p but the Crypto
class shows
OpenSSL library info: LibreSSL 2.2.9 (on current code; the 1.11.0 code crashes)

Something strange is going on; it looks like dlopen is finding a
different version of the dynamic library from the default CLI.
I have the same issue on my mac.

On Thu, 30 Jun 2022 at 01:50, Gary Gregory  wrote:
>
> FWIW, I just checked out the rel/commons-crypto-1.1.0 on macOS and ran
> 'mvn clean verify' and everything built just fine.
>
> The Maven ant-run output was:
>
> [INFO] --- maven-antrun-plugin:1.8:run (make) @ commons-crypto ---
> [INFO] Executing tasks
>
> make:
>  [exec] "/usr/local/Cellar/openjdk@8/1.8.0+322/bin/javah" -force
> -classpath target/classes -o
> target/jni-classes/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.h
> org.apache.commons.crypto.random.OpenSslCryptoRandomNative
>  [exec] gcc -arch x86_64 -Ilib/inc_mac
> -I"/usr/local/Cellar/openjdk@8/1.8.0+322/include" -O2 -fPIC
> -mmacosx-version-min=10.7 -fvisibility=hidden -I/usr/local/include
> -I/usr/local/opt/openssl/include -Ilib/include -I/usr/include
> -I"src/main/native/org/apache/commons/crypto/"
> -I"/usr/local/Cellar/openjdk@8/1.8.0+322/libexec/openjdk.jdk/Contents/Home/include/darwin"
> -I"target/jni-classes/org/apache/commons/crypto/cipher"
> -I"target/jni-classes/org/apache/commons/crypto/random" -c
> src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c
> -o target/commons-crypto-1.1.0-Mac-x86_64/OpenSslCryptoRandomNative.o
>  [exec] "/usr/local/Cellar/openjdk@8/1.8.0+322/bin/javah" -force
> -classpath target/classes -o
> target/jni-classes/org/apache/commons/crypto/cipher/OpenSslNative.h
> org.apache.commons.crypto.cipher.OpenSslNative
>  [exec] gcc -arch x86_64 -Ilib/inc_mac
> -I"/usr/local/Cellar/openjdk@8/1.8.0+322/include" -O2 -fPIC
> -mmacosx-version-min=10.7 -fvisibility=hidden -I/usr/local/include
> -I/usr/local/opt/openssl/include -Ilib/include -I/usr/include
> -I"src/main/native/org/apache/commons/crypto/"
> -I"/usr/local/Cellar/openjdk@8/1.8.0+322/libexec/openjdk.jdk/Contents/Home/include/darwin"
> -I"target/jni-classes/org/apache/commons/crypto/cipher"
> -I"target/jni-classes/org/apache/commons/crypto/random" -c
> src/main/native/org/apache/commons/crypto/cipher/OpenSslNative.c -o
> target/commons-crypto-1.1.0-Mac-x86_64/OpenSslNative.o
>  [exec] "/usr/local/Cellar/openjdk@8/1.8.0+322/bin/javah" -force
> -classpath target/classes -o
> target/jni-classes/org/apache/commons/crypto/OpenSslInfoNative.h
> org.apache.commons.crypto.OpenSslInfoNative
>  [exec] gcc -arch x86_64 -Ilib/inc_mac
> -I"/usr/local/Cellar/openjdk@8/1.8.0+322/include" -O2 -fPIC
> -mmacosx-version-min=10.7 -fvisibility=hidden -I/usr/local/include
> -I/usr/local/opt/openssl/include -Ilib/include -I/usr/include
> -I"src/main/native/org/apache/commons/crypto/"
> -I"/usr/local/Cellar/openjdk@8/1.8.0+322/libexec/openjdk.jdk/Contents/Home/include/darwin"
> -I"target/jni-classes/org/apache/commons/crypto/cipher"
> -I"target/jni-classes/org/apache/commons/crypto/random"
> -DVERSION='"1.1.0"' -DPROJECT_NAME='"Apache Commons Crypto"'
> -I"target/jni-classes/org/apache/commons/crypto" -c
> src/main/native/org/apache/commons/crypto/OpenSslInfoNative.c -o
> target/commons-crypto-1.1.0-Mac-x86_64/OpenSslInfoNative.o
>  [exec] gcc -arch x86_64 -Ilib/inc_mac
> -I"/usr/local/Cellar/openjdk@8/1.8.0+322/include" -O2 -fPIC
> -mmacosx-version-min=10.7 -fvisibility=hidden -I/usr/local/include
> -I/usr/local/opt/openssl/include -Ilib/include  -I/usr/include
> -I"/usr/local/Cellar/openjdk@8/1.8.0+322/libexec/openjdk.jdk/Contents/Home/include/darwin"
> -I"target/jni-classes/org/apache/commons/crypto/cipher"
> -I"target/jni-classes/org/apache/commons/crypto/random" -o
> target/commons-crypto-1.1.0-Mac-x86_64/libcommons-crypto.jnilib
> target/commons-crypto-1.1.0-Mac-x86_64/OpenSslCryptoRandomNative.o
> target/commons-crypto-1.1.0-Mac-x86_64/OpenSslNative.o
> target/commons-crypto-1.1.0-Mac-x86_64/OpenSslInfoNative.o -dynamiclib
> -L/usr/local/lib
>  [exec] strip -x
> target/commons-crypto-1.1.0-Mac-x86_64/libcommons-crypto.jnilib
>  [exec] cp target/commons-crypto-1.1.0-Mac-x86_64/libcommons-crypto.jnilib
> target/classes/org/apache/commons/crypto/native/Mac/x86_64/libcommons-crypto.jnilib
>  [exec] cp target/commons-crypto-1.1.0-Mac-x86_64/libcommons-crypto.jnilib
> target/classes/org/apache/commons/crypto/native/Mac/x86_64/libcommons-crypto.jnilib
>
> Gary
>
> On Wed, Jun 29, 2022 at 8:48 PM Gary Gregory  wrote:
> >
> > I agree with Alex.
> >
> > Forget LibreSSL. Commons Crypto is for OpenSSL, nice,