julia: build on ARM

[fxcoudert]

Julia 1.7.x supports Apple Silicon

[carlocab]

  System library symlink failure: Unable to locate libgcc_s.1.dylib on your system!

This will need some inreplaces at least to avoid getting confused about libgcc_s.

[carlocab]

Going to try a fix -- not that I think these are necessarily mergeable, but I just want to help the build progress a little bit to try to reproduce the error that I saw before.

[carlocab]

This is the error I mentioned in Slack, @fxcoudert:

  error during bootstrap:
  LoadError(at "compiler/compiler.jl" line 3: LoadError(at "compiler/bootstrap.jl" line 8: BoundsError(a=Module, i=4294967296)))
  jl_bounds_error at /private/tmp/julia-20220303-14329-16dvxx4/julia-1.7.2/usr/lib/libjulia-internal.1.7.dylib (unknown line)
  get_fieldtype at /private/tmp/julia-20220303-14329-16dvxx4/julia-1.7.2/usr/lib/libjulia-internal.1.7.dylib (unknown line)

The C/C++ code compiles to build a julia executable to bootstrap with, but then fails to compile its own native julia code.

[carlocab]

Building Julia on ARM macOS from the tip of the master branch (JuliaLang/julia@dbb0e50) outside of Homebrew using

mkdir -p usr/lib/julia
for f in $(brew --prefix gcc)/lib/gcc/11/*; do ln -s $f usr/lib/julia; done
make USE_SYSTEM_CSL=1 LDFLAGS=-Wl,-rpath,$(brew --prefix gcc)/lib/gcc/11

works.

I suspect that brew install --HEAD julia after applying the changes in this PR should work. I'll give it a try later.

[carlocab]

I suspect that brew install --HEAD julia after applying the changes in this PR should work. I'll give it a try later.

No, this was a lie. After a few more adjustments for a HEAD build on ARM, this also fails with the same error. It may not be coming from GCC after all.

[carlocab]

These are also needed to build Julia from HEAD on ARM:

diff --git a/Formula/julia.rb b/Formula/julia.rb
index 3a02db432ad..f3d54a6e8b0 100644
--- a/Formula/julia.rb
+++ b/Formula/julia.rb
@@ -104,22 +104,22 @@ class Julia < Formula
 
   def install
     # Fix segfaults with Curl 7.81. Remove when this is resolved upstream.
-    srccache = buildpath/"stdlib/srccache"
-    srccache.install resource("curl-patch")
-
-    cd srccache do
-      tarball = Pathname.glob("Downloads-*.tar.gz").first
-      system "tar", "-xzf", tarball
-      extracted_dir = Pathname.glob("JuliaLang-Downloads.jl-*").first
-      to_patch = extracted_dir/"src/Curl/Multi.jl"
-      system "patch", to_patch, "julia-curl-7.81.patch"
-      system "tar", "-czf", tarball, extracted_dir
-
-      md5sum = Digest::MD5.file(tarball).hexdigest
-      sha512sum = Digest::SHA512.file(tarball).hexdigest
-      (buildpath/"deps/checksums"/tarball/"md5").atomic_write md5sum
-      (buildpath/"deps/checksums"/tarball/"sha512").atomic_write sha512sum
-    end
+    # srccache = buildpath/"stdlib/srccache"
+    # srccache.install resource("curl-patch")
+
+    # cd srccache do
+    #   tarball = Pathname.glob("Downloads-*.tar.gz").first
+    #   system "tar", "-xzf", tarball
+    #   extracted_dir = Pathname.glob("JuliaLang-Downloads.jl-*").first
+    #   to_patch = extracted_dir/"src/Curl/Multi.jl"
+    #   system "patch", to_patch, "julia-curl-7.81.patch"
+    #   system "tar", "-czf", tarball, extracted_dir
+
+    #   md5sum = Digest::MD5.file(tarball).hexdigest
+    #   sha512sum = Digest::SHA512.file(tarball).hexdigest
+    #   (buildpath/"deps/checksums"/tarball/"md5").atomic_write md5sum
+    #   (buildpath/"deps/checksums"/tarball/"sha512").atomic_write sha512sum
+    # end
 
     # Build documentation available at
     # https://github.com/JuliaLang/julia/blob/v#{version}/doc/build/build.md
@@ -165,7 +165,7 @@ class Julia < Formula
     else
       Hardware.oldest_cpu
     end
-    args << "MARCH=#{march}"
+    # args << "MARCH=#{march}"
 
     cpu_targets = ["generic"]
     cpu_targets += if Hardware::CPU.arm?

[fxcoudert]

Upstream does not support building against unpatched LLVM, so we should allow it to build its own modified version. Trying to see if this works on 1.8.0-beta1.

[fxcoudert]

Two new upstream issues: JuliaLang/julia#44584 and JuliaLang/julia#44585

[Bo98]

JuliaLang/julia#44585

What does Julia's fork do? Can we not use our libuv like we do for other deps?

[giordano]

What does Julia's fork do?

Julia needs a bunch of patches that never got accepted upstream: libuv/libuv@libuv:cd7b338...JuliaLang:c2d8a53. Note that a core Julia developer is also a maintainer of libuv, so the situation is very well known upstream.

Can we not use our libuv like we do for other deps?

Julia is rather picky about binary dependencies. For most of them it's actually fine to use system libraries (as long as you match the tested version numbers), but libuv and llvm are somewhat heavily patched (not that heavily, but also not trivial patches). You could use a system libuv, but it's likely users will encounter problems.

[cho-m]

For zlib that is being built, it is setting DESTDIR at the end of install command to some usr-staging path

/Applications/Xcode.app/Contents/Developer/usr/bin/make -C scratch/zlib-cacf7f1d4e3d44d871b605da3b647f07d718623f install DESTDIR="" prefix=/private/tmp/julia-20220311-20258-ie1m3j/julia-1.8.0-beta1/usr bindir=/private/tmp/julia-20220311-20258-ie1m3j/julia-1.8.0-beta1/usr/tools libdir=/private/tmp/julia-20220311-20258-ie1m3j/julia-1.8.0-beta1/usr/lib shlibdir=/private/tmp/julia-20220311-20258-ie1m3j/julia-1.8.0-beta1/usr/lib libexecdir=/private/tmp/julia-20220311-20258-ie1m3j/julia-1.8.0-beta1/usr/libexec datarootdir=/private/tmp/julia-20220311-20258-ie1m3j/julia-1.8.0-beta1/usr/share includedir=/private/tmp/julia-20220311-20258-ie1m3j/julia-1.8.0-beta1/usr/include sysconfdir=/private/tmp/julia-20220311-20258-ie1m3j/julia-1.8.0-beta1/usr/etc O= DESTDIR="/private/tmp/julia-20220311-20258-ie1m3j/julia-1.8.0-beta1/usr-staging/zlib-cacf7f1d4e3d44d871b605da3b647f07d718623f"

So it ends up installing libraries into wrong directory:

/usr/local/Cellar/cmake/3.22.3/bin/cmake -P cmake_install.cmake
  -- Install configuration: "Release"
  -- Installing: /private/tmp/julia-20220311-20258-ie1m3j/julia-1.8.0-beta1/usr-staging/zlib-cacf7f1d4e3d44d871b605da3b647f07d718623f/tmp/julia-20220311-20258-ie1m3j/julia-1.8.0-beta1/usr/lib/libz.1.2.11.dylib

Whether this should be using system libs is a separate question. Could be due to building LLVM, e.g.

LLVM_CMAKE += -DLLVM_ENABLE_ZLIB=ON -DZLIB_LIBRARY="$(build_prefix)/lib"

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.