musl support for Alpine Linux

[mrdziuban]

In the same vein as #697, I'm curious if you would consider building the native library for musl (in addition to glibc) so it can be used in Alpine Linux?

I have a repository (https://github.com/mblink/alpine-quantlib-java) that can successfully build the library in an Alpine Docker container for both amd64 and arm64 architectures, and is currently setup to upload the JAR and POM files to a release. If you're open to supporting musl, I'd be happy to help get it integrated into this repository.

[ralfkonrad]

In the same vein as #697, I'm curious if you would consider building the native library for musl (in addition to glibc) so it can be used in Alpine Linux?

Yes, extending the supported platforms in general is a good idea!

I have a repository (https://github.com/mblink/alpine-quantlib-java) that can successfully build the library in an Alpine Docker container for both amd64 and arm64 architectures, and is currently setup to upload the JAR and POM files to a release. If you're open to supporting musl, I'd be happy to help get it integrated into this repository.

I had a look at the build process in your repo. It is a smart solution using alpine docker builds.

However, from my point of view as the maintainer it has some disadvantages:

• IMO, using the same version for boost and swig across platform builds is essential to avoid compatibility issues. However, alpine's apk does not provide the latest versions and you are currently build them manually. So, as a maintainer I would become repsonsible for these builds -incl. their build flags etc.- rather than "outsourcing" it to a reliable package manager.

• the rest of the platform builds and tests are completely inside hosted GitHub runners, maintaining them is (mostly) straightforward. The docker based approach adds another layer which needs extra maintainance.

• More generally, QuantLib itself does not have builds and tests against alpine musl. So, there is no guarantee that it fully works in edge cases. But I guess have tested this in upfront?

So, I'm not sure if I really want to integrate and more importantly maintain it in the long run?! As I mention here this module is not really meant for production use which using it inside alpine is.

But as I said above, extending the supported platforms in general is a good idea. Perhaps you have good arguments to include it.

[mrdziuban]

Thanks for the response!

• IMO, using the same version for boost and swig across platform builds is essential to avoid compatibility issues. However, alpine's apk does not provide the latest versions and you are currently build them manually. So, as a maintainer I would become repsonsible for these builds -incl. their build flags etc.- rather than "outsourcing" it to a reliable package manager.

Agreed this is likely the biggest potential source of maintenance headaches. If you're willing to build with whichever boost and swig versions are available in Alpine, then the build script gets a good amount simpler. This limitation could be communicated to users via the README.

• the rest of the platform builds and tests are completely inside hosted GitHub runners, maintaining them is (mostly) straightforward. The docker based approach adds another layer which needs extra maintainance.

The Docker build would still run within GitHub actions, but I do understand the aversion to maintaining the Docker build itself and the extra complexity of the GH Actions workflow.

• More generally, QuantLib itself does not have builds and tests against alpine musl. So, there is no guarantee that it fully works in edge cases. But I guess have tested this in upfront?

That makes sense. I have confirmed that it works for my needs, but I definitely haven't done an exhaustive test of all features.

As I mention here this module is not really meant for production use which using it inside alpine is.

I don't have a great argument against this 🙂 I was planning to use it alongside a static analysis tool that would identify every call to an org.quantlib.* constructor so I could guarantee that memory was handled properly. Since creating this issue, however, I've actually migrated my code to use Strata thanks to your comment.

All that said, I'll accept whatever decision you make here. In case it's helpful, I took some time to demonstrate what a simplified version of my build script would look like in mblink/alpine-quantlib-java#1. It:

• Uses the boost and swig Alpine packages
• Removes the need to manually install maven
• Removes my Scala test script and code to run it

[ralfkonrad]

Agreed this is likely the biggest potential source of maintenance headaches. If you're willing to build with whichever boost and swig versions are available in Alpine, then the build script gets a good amount simpler. This limitation could be communicated to users via the README.

Using a different boost version might be okayish.

Swig is a different beast here: it generates all the Java classes in the package org.quantlib. Take a special look at org.quantlib.QuantLibJNI, it contains all the pointer handling to the native library. And it generates the corresponding c++ file it is linked against. Currently, this c++ files has 411,527 auto-genereted lines like this

SWIGEXPORT jboolean JNICALL Java_org_quantlib_QuantLibJNI_LocalVolTermStructureHandle_1empty(JNIEnv *jenv, jclass jcls, jlong jarg1, jobject jarg1_) {
  jboolean jresult = 0 ;
  Handle< LocalVolTermStructure > *arg1 = 0 ;
  bool result;
  
  (void)jenv;
  (void)jcls;
  (void)jarg1_;
  arg1 = *(Handle< LocalVolTermStructure > **)&jarg1; 
  {
    try {
      result = (bool)(arg1)->empty();
    } catch (std::out_of_range& e) {
      {
        SWIG_JavaException(jenv, SWIG_IndexError, const_cast<char*>(e.what())); return 0; 
      };
    } catch (std::exception& e) {
      {
        SWIG_JavaException(jenv, SWIG_RuntimeError, const_cast<char*>(e.what())); return 0; 
      };
    } catch (...) {
      {
        SWIG_JavaException(jenv, SWIG_UnknownError, "unknown error"); return 0; 
      };
    }
  }
  jresult = (jboolean)result; 
  return jresult;
}

As I expect improvements and bugfixes between swig versions I wouldn't count on compatibility between them. Using different swig versions in the build can be a dark path to go.

If Opengamma Strata provides you with (most) of the functionality you need, I would definitely recommend using it as it is pure java. We are also only use this one in unit tests to compare our results against it but never in a production environment.

[ralfkonrad]

This issue has been automatically marked as stale due to inactivity. It will be closed in two weeks if no further activity occurs.