ffmpeg preset is linked against too recent GLIBC_2.17 #22
Comments
|
btw there is debootstrap, a nice debian command line utility that allows quick and easy setup of older debian chroot environments. I guess we need to build the libs on the oldest, supported platform... |
|
Do you know of an equivalent for CentOS under Fedora? I was thinking of making builds with CentOS, but that adds complexity when I do a release, so I am sort of waiting for someone to share the load a bit :) Let me know if you would be interested in making the builds with Debootstrap or whatever works, thanks |
|
I have implemented it at https://github.com/jjYBdx4IL/javacpp-presets You can do the builds using the free, public travis ci. See https://travis-ci.org/jjYBdx4IL/javacpp-presets I have added a module with basic tests there. Currently only ffmpeg and opencv get built, so that needs to be extended and the ffmpeg test that is currently failing needs fixing, too. I can do most of it, but I don't think I can fix the test failure (SIGSEGV) as shown at the end of the travis build logs. https://api.travis-ci.org/jobs/39567132/log.txt?deansi=true Regarding the release complexity, I really think we should merge all those jars into a single one. If you are OK with that idea, I will give it a try. |
|
Thanks for trying things out! Does the test SIGSEGV because the build is bad? Or does it just fail because Travis CI won't let it run properly? Sure, please do try to merge everything in one JAR. I'm sure some people would like to be able to build it that way. |
|
It does the same on my desktop. |
|
Ok, so your test is bad? Or is this caused by a bug in my code somewhere? |
|
It fails when trying to instantiate FFmpegFrameRecorder at https://github.com/jjYBdx4IL/javacpp-presets/blob/master/tests/src/test/java/jjybdx4il/javacv/examples/FFmpegTest.java#L84 A detailed error dump was generated by the jvm and is available at the end of the travis build log: https://api.travis-ci.org/jobs/39654016/log.txt?deansi=true Here is an excerpt containing some of the relevant information: |
|
ok, I found the problem: the libav* libs depend on each other and the loading sequence seems to be random, so the system's native shared lib loader cannot resolve the shared libs' dependencies. Can we drop using our own javacpp.Loader that unpacks the shared objects and just require that the libs must be on the java library path? Using maven, the following approach should be ok when working with the mvn command: http://blog.dub.podval.org/2011/01/native-libraries-with-maven.html |
|
They don't get loaded in random order... BTW, could you try again with the Of course we can use libraries installed on the system, but the compiler needs to know where to find header files and linkable files. Those directories can be specified in the |
|
No, I'm not talking of using libs provided by the OS. The regular way to include shared libs with your java app is to put them into a directory and specify that dir via -Djava.library.path as demonstrated in https://github.com/jjYBdx4IL/javacpp-presets/blob/master/tests/pom.xml . I can see that there might be some fringe cases where dynamically extracting the libs from the jars may be useful, but I suggest making that behavior optional and off by default because it is non-standard and can be very tricky to resolve. btw. using the java.library.path solution made my tests work just fine. |
|
Regarding the original issue (libs not running on slightly older systems), I'll try to implement a maven plugin that will use kvm and prepared debian disk images to automatically create the entire build via a single command. It will basically copy the unbuilt source tree into the kvm guest, build and test it there, then pull the artifacts out of it in order to install and deploy them where the user has originally started the mvn command. |
|
Regarding the shared libs, how do you see this work for end users of applications not using Maven? Regarding the build system, we need something that works for Mac OS X and Windows as well, so please keep that in mind, thanks! |
|
The kvm solution would be optional for linux systems so you don't have to (manually) install old or different linux OSes in order to build the libs on them, it would work on-the-fly, not necessarily very fast, of course. That, of course, does not work with Mac and Windows because those systems are not freely available. Maybe I move the kvm build to another , independent module. Did you try cross-compilation for the non-free platforms? Any ideas? What would be your preferred way to build compatible linux libs? kvm would at least work on most linux systems and is way less intrusive than chroot solutions which require root privileges. (remark: personally, I would just drop support for non-free systems if you cannot cross-compile for them from a linux box. Offer it as a paid service instead. Too much hazzle, if it cannot be done automatically. If you have Mac OS and Windows disk images runnable inside kvm, you could of course, use them and make the build automatic for those platforms too) |
|
If we can use the Android NDK and MinGW-w64 on Travis CI, I'm pretty sure it would be feasible to makes builds for free for all platforms there, including Mac OS X, so let's concentrate on that. What do you say? |
|
I don't think travis ci is flexible enough and nobody knows how long the service will last. First of all they don't provide caching and AFAIK Mac/windows are only or paid subscribers. They don't even provide a generic http/ftp proxy. Then there is the problem that they only provide one linux system and have a build time limit of 50 minutes. Currently, bootstrapping older Linux OSes on the travis machines is working, but I doubt that it is supported in any way so it could stop working every day. I think kvm is the most flexible solution and computational-wise it is nearly 100% efficient, though often disk speed is lacking. They may provide Mac/Windows for free some day, but even then it is likely not the correct version and could render the generated libs largely incompatible . |
|
I didn't try it, but I'm pretty sure Mac OS X builds are free on Travis CI for open source projects. Anyway, please do experiment with things that interest you, and let me know what works out in the end! Thanks |
* Build the Maven artifacts for Linux in a CentOS 6 Docker container, for maximum compatibility (issue #22)
|
The Linux binaries for version 1.1 were built in a CentOS 6 Docker container, so that should fix this issue. If these kinds of error messages still pop up though, please let me know! And thanks for reporting |
And therefore it does not load on Ubuntu 12.04. Tried to compile it on my system but that leads to SIGSEGV. Runnable example is https://github.com/jjYBdx4IL/misc/blob/master/src/test/java/jjybdx4il/javacv/examples/FFmpegTest.java at https://github.com/jjYBdx4IL/misc/ .
The text was updated successfully, but these errors were encountered: