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

WIP: julia: update to 1.7.1. #35270

Closed
wants to merge 1 commit into from
Closed

Conversation

non-Jedi
Copy link
Contributor

Still need to finish building/testing locally and separating out into logical commits, but I thought I should put this here to make sure there's no duplicated effort since I'm not sure when I'll finish this up, and libblastrampoline was annoying to get to build correctly.

[ci skip] for building llvm.

Testing the changes

  • I tested the changes in this PR: YES|briefly|NO

@kwshi
Copy link
Contributor

kwshi commented Jan 30, 2022

thanks for doing the hard work on this, as a void julia user, i appreciate it! ❤️

@Piraty
Copy link
Member

Piraty commented Jan 30, 2022

please take care of #35270

@Piraty Piraty mentioned this pull request Jan 30, 2022
10 tasks
@Piraty
Copy link
Member

Piraty commented Jan 30, 2022

libblastrampoline's tests require julia which would result in cyclic dependency, maybe put a comment ?

@Piraty
Copy link
Member

Piraty commented Jan 30, 2022

also, JuliaLinearAlgebra/libblastrampoline@39d859e is interesting (though appears not entirely correct for the static lib)

@non-Jedi
Copy link
Contributor Author

please take care of #35270

Looks like you linked the wrong issue/PR.

@non-Jedi
Copy link
Contributor Author

non-Jedi commented Feb 4, 2022

Where I'm stuck at with this right now is that julia's build system seems to want to build all dependencies regardless of which USE_SYSTEM_* flags are set. This of course means that it tries to build libblastrampoline as a vendored dep which isn't successful without the flags I have set in the template for that package, so I haven't gotten julia 1.7 to successfully build at all yet. I'm going to ask around; feel like I must be doing something wrong.

@non-Jedi non-Jedi force-pushed the julia-1.7.1 branch 2 times, most recently from cb575ac to 72a45c9 Compare February 5, 2022 04:51
This needs to be separated out into two commits: one for the new libblastrampoline package.
@non-Jedi
Copy link
Contributor Author

non-Jedi commented Feb 5, 2022

This appears to be some sort of issue with an interaction between the xbps-src system and julia's build system. Invoking make manually with the value of make_build_args causes only the desired libraries to be built, but when run from the build phase, it attempts to build all vedored dependencies entirely ignoring the USE_SYSTEM_* flags. Any ideas on this would be appreciated as I'm getting close to the end of my ability to debug this.

Any thoughts @ahesford since you have some level of familiarity with this template?

@kwshi
Copy link
Contributor

kwshi commented Feb 5, 2022

I've attempted to take a look at this and tried to build it by hand (manually running make from the cloned source with correct arguments set). Curiously, I seem to be running into a separate issue wherein the make build script is attempting but failing to detect/load/symlink the libblastrampoline.so library, even after I built and installed the libblastrampoline package included in this PR.

I'm not sure why--my best attempt at reading the Makefile to figure out what's happening seems to point to it using libwhich to locate libraries; when I try to manually run libwhich -p libblastrampoline.so, I get

failed to open library: /usr/lib/libblastrampoline.so: undefined symbol: f2c_sdot_64_

which suggests something additionally may be broken with the current state of the libblastrampoline package. I doubt that's the same issue @non-Jedi you're facing with the USE_* variables getting ignored, but it seems to be yet another barrier in getting things to build correctly. Have you encountered this?

Copy link
Member

@ahesford ahesford left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately, I haven't had any time to look at the build problems here and am not sure when I'll have some spare time to dig in. The few points I make below are based just on reading the template and not actually trying to build it.

make_install_args="$make_build_args"
make_check_args="$make_build_args"
make_check_target=testall
conf_files="/etc/julia/startup.jl"
hostmakedepends="pkg-config perl cmake python gcc-fortran patchelf which tar xz"
hostmakedepends="pkg-config perl cmake python3 gcc-fortran patchelf which tar xz libwhich"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if libwhich here is complicating the search for libraries in a way that triggers vendored builds of libraries you've installed in makedepends.

makedepends="p7zip pcre2-devel mpfr-devel libgit2-devel libcurl-devel nghttp2-devel
libssh2-devel mbedtls-devel libatomic-devel zlib-devel libunwind-devel
libutf8proc-devel"
libutf8proc-devel libblastrampoline-devel openblas-devel"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You mentioned "vendored builds" below; what is the purpose for pulling openblas-devel here if a vendored build will be done?

nocross="build system is a mess"
noverifyrdeps="Julia doesn't need to depend on system llvm/openblas with vendored builds in /usr/lib/julia/"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a pretty big hammer and can often lead to dependency problems. Can this be replaced with a skiprdeps list that explicitly exempts only those files that trigger erroneous dependency resolution?

@Rabioli
Copy link

Rabioli commented Feb 25, 2022

I was messing with julia on musl, I don't know what you guys are using but, at least for me, the void package appears to work but doesn't (it segfaults when trying to add new julia packages).

So I tried their official musl binary that doesn't even work either until I settled for compiling it myself which has given me the best result so far I haven't run into any issue with dependent on julia.

The relevancy into this issue is one, there is already a 1.7.2 release and soon to come out 1.8.0 and second could it be possible to export or reverse engineer the flags used by make "by default" so we can use them for the template?

I also attempted to make a template, but it just didn't work at all, like just changing the version and the checksums broke it all.

@Piraty
Copy link
Member

Piraty commented Apr 21, 2022

oh, i meant to link #34387

@Piraty
Copy link
Member

Piraty commented Jul 6, 2022

ping

@github-actions
Copy link

github-actions bot commented Oct 5, 2022

Pull Requests become stale 90 days after last activity and are closed 14 days after that. If this pull request is still relevant bump it or assign it.

@github-actions github-actions bot added the Stale label Oct 5, 2022
Piraty added a commit to Piraty/void-packages that referenced this pull request Oct 12, 2022
* FTBFS: void-linux#34387
* unmaintained: void-linux#35270
* blocks libgit2 update
Piraty added a commit to Piraty/void-packages that referenced this pull request Oct 12, 2022
* FTBFS: void-linux#34387
* unmaintained: void-linux#35270
* blocks libgit2 update
@Piraty Piraty mentioned this pull request Oct 12, 2022
@Piraty
Copy link
Member

Piraty commented Oct 13, 2022

closing, see #39919

@Piraty Piraty closed this Oct 13, 2022
Piraty added a commit that referenced this pull request Oct 13, 2022
* FTBFS: #34387
* unmaintained: #35270
* blocks libgit2 update
pfpulux pushed a commit to pfpulux/void-packages that referenced this pull request Oct 25, 2022
* FTBFS: void-linux#34387
* unmaintained: void-linux#35270
* blocks libgit2 update
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants