> If the only concern is the file signatures, I'm almost sure that the > maven build will pick up native libraries you drop in some directory > and include them in the jar, regardless of whether they're for the > current architecture. Then you'd get the jar with all native libraries > and the right signature.
Yes, I've seen the same thing when producing a Jar of commons-crypto with both x86 and AArch64 native libraries. Just create the proper dirs for the final build and sign. With travis, there is a way to save off the artifacts: https://docs.travis-ci.com/user/uploading-artifacts/. It may be something to consider to auto-generate releases as Travis does support Linux on arm, and x86 (though only ubuntu which should be fine for building and linking). -Geoff On Sun, Apr 12, 2020 at 10:03 PM Marcelo Vanzin <van...@gmail.com> wrote: > > On Sun, Apr 12, 2020 at 6:13 PM Gary Gregory <garydgreg...@gmail.com> wrote: > > > I can do the 64 bit builds on Mac, Linux and Windows, so I'm happy to > > > provide whichever of those is required. It seems that Geoff can do the > > > arm64 build. Do we even bother supporting 32 bit architectures at this > > > point? > > > > Unfortunately, we cannot just pick up bits from folks here and there. It > > all has to be buildable from Maven by the release manager in order to > > generate the file signatures properly. > > If the only concern is the file signatures, I'm almost sure that the > maven build will pick up native libraries you drop in some directory > and include them in the jar, regardless of whether they're for the > current architecture. Then you'd get the jar with all native libraries > and the right signature. > > $ mkdir -p target/classes/org/apache/commons/crypto/native/Linux/x86 > $ touch !$/fake.so > touch target/classes/org/apache/commons/crypto/native/Linux/x86/fake.so > $ mvn package > $ jar tf target/commons-crypto-1.1.0-SNAPSHOT.jar | grep fake.so > org/apache/commons/crypto/native/Linux/x86/fake.so > > Frankly, given you need things built on different platforms, that > seems like the easiest way to get a jar with multiple native libraries > - setting up cross-compilers would be kind of a pain. > > Now if the requirement is that the release manager needs to build > everything himself, then that makes it a little more complicated. > > -- > Marcelo Vanzin > van...@gmail.com > "Life's too short to drink cheap beer" > > --------------------------------------------------------------------- > 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
