Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Direct download to native libraries and explanations #1103

Closed
oliviercailloux opened this issue Mar 2, 2019 · 4 comments
Closed

Direct download to native libraries and explanations #1103

oliviercailloux opened this issue Mar 2, 2019 · 4 comments
Assignees
Labels
Feature Request Missing Feature/Wrapper Lang: Java Java wrapper issue OS: Linux GNU/Linux OS OS: Mac MacOS OS: Windows Windows OS
Milestone

Comments

@oliviercailloux
Copy link

Please consider providing a direct link to download the native libraries (dll, so) for use with Java for the main platforms supported by Google OR-Tools.

I have provided a Maven library for Google OR-Tools (here, see issue #202). To use it, users have to add the native library for their platform. Currently it is not easy, as they have to download the zipped whole distribution for Google OR-Tools and extract the required files from it. It would be much easier if I could simply provide them with a link.

To make it worse, I ignore to which extent a native library compiled on some linux version is useable on some other linux version. Can I provide a single version of the native libraries (say, the Ubuntu 18.10 one) and suggest to linux users to use this one? Or should I insist that they each go download the one version for their specific variant?

@Mizux Mizux added Feature Request Missing Feature/Wrapper OS: Windows Windows OS OS: Linux GNU/Linux OS OS: Mac MacOS Lang: Java Java wrapper issue labels Mar 4, 2019
@Mizux
Copy link
Collaborator

Mizux commented Mar 4, 2019

For python we use the manylinux official docker image which is an "old" Centos:5 IIRC so or-tools python NATIVE package is built against a glibc 2.12 which should provide maximum compatibility for most linux distro (according to Python).
see: https://www.python.org/dev/peps/pep-0513/
I guess for java you should use the same binaries, using an ubuntu 18.10 you are pretty sure it won't for any previous version like the 16.04 LTS or 18.04 LTS...

@oliviercailloux
Copy link
Author

Thanks for the help. Let me check if I understood correctly.

I understand that picking a native library built for a recent OS is a bad idea as it generally won’t run on an OS using older system (or shared) native libraries. As I understand it, you suggest to me to rather point, for a general linux audience, to the native library version that is built by Google OR Tools on a platform specifically designed for maximal compatibility, namely, a CentOS 5 based one (as explained in the referenced PEP), labelled as manylinux1.

BUT, downloading and opening the file ortools-7.0.6546-cp37-cp37m-manylinux1_x86_64.whl, I can’t find the libraries I need for Java (understandably, as it is a release file for Python). All files in the release page that are labeled manylinux seem to be Python wheels package; and I see no library in the Java download page built for CentOS 5 or marked as manylinux.

Do I understand correctly that manylinux distribution is provided only for Python packages, and not currently provided for Java consumption? If so, is this expected in the future?

@Mizux
Copy link
Collaborator

Mizux commented Apr 30, 2019

Yes, you are right.

If you look at tools/docker directory you can see:

  1. We provide a "Manylinux" python only package using the container provided by the python community which is call manylinux2010, and it is based on a Centos 7 image -> Yes it is used for python package so there is no the necessary Java tools directly available
  2. Several dockers for few majors distro

We drop our Centos5/6 containers since they don't work with a recent Linux distro (TL;DR they use a now forbidden vsyscall that any recent kernel don't have anymore).
ref: https://mail.python.org/pipermail/wheel-builders/2016-December/000239.html

For Java/.Net I would use a Centos 7 based container to have the maximum compatibility out there.

see the glibc currently used by few distros:
Packaging status

@lperron
Copy link
Collaborator

lperron commented Jul 19, 2019

I assume we have nothing more to do.
I do not want to add another binary artifact, but with the centos7 linux build, you only need to incorporate 3 native libraries in your build.

@lperron lperron closed this as completed Jul 19, 2019
@Mizux Mizux added this to the v8.0 milestone Feb 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature Request Missing Feature/Wrapper Lang: Java Java wrapper issue OS: Linux GNU/Linux OS OS: Mac MacOS OS: Windows Windows OS
Projects
None yet
Development

No branches or pull requests

3 participants