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

BinaryProvider doesn't detect that FreeBSD already has what's needed for CodecXz #106

Open
ko56 opened this Issue Aug 24, 2018 · 7 comments

Comments

Projects
None yet
3 participants
@ko56
Copy link

ko56 commented Aug 24, 2018

(Related to issues #32 and #57)
My suggestion is to have the build.jl script, here we're using CodecXz as an example, somehow check whether the library it's looking for already exists on the system, and if so, proceed directly to creating the deps.jl file. In this specific case, FreeBSD has /usr/lib/liblzma.so.

I made CodecXz work by manually creating a deps.jl file with the right path to the library.

@ararslan

This comment has been minimized.

Copy link
Member

ararslan commented Aug 24, 2018

This is expected, since it's how BinaryProvider is designed to work.

For some background, one problem you run into when using system libraries instead of building the libraries yourself is versioning: the version of a particular library installed on the system may be very old or otherwise mismatched/incompatible with what you're building for other systems, which can cause differences in the behavior of the Julia package which calls it across systems. That's part of the motivation for BinaryBuilder and BinaryProvider, that system libraries should be avoided. It's easier and more consistent to just let the builder build for FreeBSD.

@ko56

This comment has been minimized.

Copy link

ko56 commented Aug 24, 2018

I understand your point about versions. However, (a) sometimes building a package for a particular OS requires specific tricks, and I don't know how BinaryProvider deals with that, and (b) in this, the CodecXz case, the builder responds that FreeBSD is an unknown platform.

@ararslan

This comment has been minimized.

Copy link
Member

ararslan commented Aug 24, 2018

CodecXz likely just needs a new tag then, since XzBuilder has been updated to support FreeBSD: bicycle1885/XzBuilder@82d8f6d#diff-2567705d891d25120e6ea4ca97383113R34

@klpn

This comment has been minimized.

Copy link

klpn commented Aug 29, 2018

In some cases, this avoidance of system libraries gives rise to new problems with versioning. For example, Arch Linux repos provide both Julia and Arpack, compiled with the version of GCC in the Arch repos (GCC 8). But if you try to install Arpack.jl, the build tries to download and use a version of Arpack created with GCC 7, which does not work with the GCC 8-compiled Julia. As I described under Arpack.jl #5, it is possible to get around the problem by manually copying the Arpack system library into the build directory, but this is not a very attractive solution. Perhaps, the build.jl could some decision method like Pypandoc which uses the previously installed Pandoc if it is not older than the provided Pandoc. One could also argue that the build_tarballs.jl scripts generated by BinaryBuilder should use static linking as far as possible.

@ko56

This comment has been minimized.

Copy link

ko56 commented Aug 29, 2018

I think this is a good suggestion "Perhaps, the build.jl could some decision method like Pypandoc which uses the previously installed Pandoc if it is not older than the provided Pandoc".
It would also mitigate the tendency to create an "overly fat" Julia installation.

@ararslan

This comment has been minimized.

Copy link
Member

ararslan commented Aug 29, 2018

Arch Linux repos provide both Julia and Arpack

We always recommend using official Julia binaries over ones provided by system package managers. That's mentioned in Julia's README.

@klpn

This comment has been minimized.

Copy link

klpn commented Aug 30, 2018

Yes, it says:

Although some system package managers provide Julia, such installations are neither maintained nor endorsed by the Julia project. They may be outdated and/or unmaintained.

In the case with Arch, however, the package manager provides the latest released version of Julia built with the latest released version of the GCC toolchain. I was wondering how the build should behave in such cases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment