[CRYPTO] Windows help finding OpenSSL library location
I don't currently have ready access to a Windows host, and have so far failed to find the correct setting of jn[ai].library.path required to cause OpenSSL to be loaded rather than the default which seems to be LibreSSL. So if anyone with Windows and OpenSSL 1.1.x can help that would be great! The following command can be used to load the library via JNI: mvn -q exec:java -D"exec.mainClass=org.apache.commons.crypto.Crypto" -D"jni.library.path=" Try it first without the jni.library.path define, and it should show the default library details. To find the path setting on macOS one can use the output from: $ openssl version -e ENGINESDIR: "/usr/local/lib/engines-1.1" The setting for jni.library.path on macOS is the ENGINESDIR without the 'engines-1.1' part. i.e. /usr/local/lib in this case. But my attempts to try the same approach using GH actions have so far failed. It always loads the default library. For loading via JNA, one can use the following to show the library details: mvn -q exec:java -D"exec.mainClass=org.apache.commons.crypto.jna.OpenSslJna" -D"jna.library.path=" (note the slightly different property name) The same path works for both JNI and JNA on macOS; I expect this will also be true on Windows. Note: to build the code, I've found the quickest is to use: mvn [clean] test -DskipTests This ensures the native files are built. Sebb - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [CRYPTO] Why does Makefile use CXX (C++) for linking?
I believe it is for cross compilation, owing to the comments in the makefile: # for cross-compilation on Ubuntu, install the g++-mingw-w64-x86-64 package # for cross-compilation on Ubuntu, install the g++-arm-linux-gnueabi package # for cross-compilation on Ubuntu, install the g++-arm-linux-gnueabihf package On Wed, Nov 1, 2023 at 11:17 AM sebb wrote: > On Wed, 1 Nov 2023 at 12:53, Gary Gregory wrote: > > > > Maybe there are cross compilation issues... I don't know for sure. > > But CXX is only used for the link phase. > > > What I > > do know is that it quite tricky and time consuming to get everything just > > right when I do a release from multiple machines to get macOS, Linux, and > > Windows binaries correctly compiled, linked, and packaged up. I hope > > nothing was broken in all the recent commits. > > I think there may need to be some more GH tests to check all the > combinations. > > > Gary > > > > On Wed, Nov 1, 2023, 8:45 AM sebb wrote: > > > > > Crypto currently only uses .c files, and the Makefile uses CC > > > throughout, except for creating the object output. [This has been the > > > case since the initial release.] > > > > > > Using CXX (C++) for the link does not make sense to me - surely CC can > > > create the object equally well? > > > > > > It would simplify builds (and especially docker builds) if C++ could be > > > dropped. > > > > > > But perhaps there is a good reason for using C++ for this step only? > > > > > > Sebb > > > > > > - > > > 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] Which native builds are supported in binary releases?
The supported architectures documentation is limited to the discussion on this distribution list. At least, that's my recollection and understanding. I agree that this should be documented at least in the release notes and web site. Users shouldn't need to crack open the jar to figure that out. Alex On Wed, Nov 1, 2023 at 11:36 AM sebb wrote: > The Crypto makefile includes a lot of different OS and architecture > combinations. > > Not all of these are included in the binary jar. > > I don't think we need to generate native binaries for all the > combinations, but I do think we need to document which ones are > included, and note that any others must be generated from source. > > So: what determines which combinations are supported in the binary, > and where is this documented? > > Sebb > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [ANNOUNCE] Apache Commons IO 2.15.0
On 26/10/2023 13:48, Gary Gregory wrote: Java 8 is required. This phrasing is somewhat confusing. "Java 8 or newer is required" would help clarify things. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[CRYPTO] Which native builds are supported in binary releases?
The Crypto makefile includes a lot of different OS and architecture combinations. Not all of these are included in the binary jar. I don't think we need to generate native binaries for all the combinations, but I do think we need to document which ones are included, and note that any others must be generated from source. So: what determines which combinations are supported in the binary, and where is this documented? Sebb - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [CRYPTO] Why does Makefile use CXX (C++) for linking?
On Wed, 1 Nov 2023 at 12:53, Gary Gregory wrote: > > Maybe there are cross compilation issues... I don't know for sure. But CXX is only used for the link phase. > What I > do know is that it quite tricky and time consuming to get everything just > right when I do a release from multiple machines to get macOS, Linux, and > Windows binaries correctly compiled, linked, and packaged up. I hope > nothing was broken in all the recent commits. I think there may need to be some more GH tests to check all the combinations. > Gary > > On Wed, Nov 1, 2023, 8:45 AM sebb wrote: > > > Crypto currently only uses .c files, and the Makefile uses CC > > throughout, except for creating the object output. [This has been the > > case since the initial release.] > > > > Using CXX (C++) for the link does not make sense to me - surely CC can > > create the object equally well? > > > > It would simplify builds (and especially docker builds) if C++ could be > > dropped. > > > > But perhaps there is a good reason for using C++ for this step only? > > > > Sebb > > > > - > > 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] Why does Makefile use CXX (C++) for linking?
Maybe there are cross compilation issues... I don't know for sure. What I do know is that it quite tricky and time consuming to get everything just right when I do a release from multiple machines to get macOS, Linux, and Windows binaries correctly compiled, linked, and packaged up. I hope nothing was broken in all the recent commits. Gary On Wed, Nov 1, 2023, 8:45 AM sebb wrote: > Crypto currently only uses .c files, and the Makefile uses CC > throughout, except for creating the object output. [This has been the > case since the initial release.] > > Using CXX (C++) for the link does not make sense to me - surely CC can > create the object equally well? > > It would simplify builds (and especially docker builds) if C++ could be > dropped. > > But perhaps there is a good reason for using C++ for this step only? > > Sebb > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
[CRYPTO] Why does Makefile use CXX (C++) for linking?
Crypto currently only uses .c files, and the Makefile uses CC throughout, except for creating the object output. [This has been the case since the initial release.] Using CXX (C++) for the link does not make sense to me - surely CC can create the object equally well? It would simplify builds (and especially docker builds) if C++ could be dropped. But perhaps there is a good reason for using C++ for this step only? Sebb - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
