Julia fails to build on on aarch64 because libquadmath.so is not available #41613

ggardet · 2021-07-16T08:15:16Z

Julia fails to build on aarch64 because libquadmath.so is not available on this arch.
Log:

[ 4706s] ln -sf /lib64/libgfortran.so.5 /home/abuild/rpmbuild/BUILD/julia-1.6.1/usr/lib/julia/libgfortran.so.5
[ 4706s] System library symlink failure: Unable to locate libquadmath.so.0 on your system!
[ 4706s] make[1]: *** [Makefile:206: /home/abuild/rpmbuild/BUILD/julia-1.6.1/usr/lib/julia/libquadmath.so.0] Error 1
[ 4706s] make[1]: Leaving directory '/home/abuild/rpmbuild/BUILD/julia-1.6.1/base'
[ 4706s] make: *** [Makefile:63: julia-base] Error 2

The text was updated successfully, but these errors were encountered:

Seelengrab · 2021-07-16T09:36:05Z

Are you sure you have all required dependencies installed? There's also #36617. What system are you trying to build on?

ggardet · 2021-07-16T09:51:51Z

I am trying to build on openSUSE Tumbleweed aarch64, with GCC11. libquadmath is available on other archs, but not on aarch64.

Seelengrab · 2021-07-16T13:06:44Z

I just noticed you're trying to build 1.6.1 - I don't think 1.6.1 had even build support on aarch64. The issue I linked is about getting it to work in the future (motivated by Apple's recent move to that architecture) and has only recently begun to work. Do the official 1.7 beta binaries work? If so, you can try building 1.7 from source, which will probably work better than 1.6.1.

Seelengrab · 2021-07-16T13:12:34Z

Fiddling around with the download links on julialang.org/downloads, there were binaries available for aarch64 and 1.6.1, so I suspect there's something going on with your setup. Perhaps the libraries are in a non-standard place, making julia unable to find them?

giordano · 2021-07-16T20:55:53Z

with GCC11

Any chance to try with GCC 9 or 10? Also, why don't you simply use the official binaries (aarch64 is Tier 1, since it's also tested in CI)?

ggardet · 2021-07-20T07:44:23Z

with GCC11

Any chance to try with GCC 9 or 10? Also, why don't you simply use the official binaries (aarch64 is Tier 1, since it's also tested in CI)?

The policy of the Linux distribution is to rebuild from sources, not using pre-built binaries.
I may try an older GCC.

ggardet · 2021-11-23T12:49:22Z

It also fails with GCC7

giordano · 2021-11-23T13:29:22Z

What if you remove line

julia/base/Makefile

Line 213 in 8c97995

$(eval $(call symlink_system_library,CSL,libquadmath,0))

? But I'm confused, because this platform is Tier 1 and tested regularly 😕

imciner2 · 2021-11-23T13:51:49Z

From some digging, I don't think libquadmath is supposed to exist on aarch64 platforms. At first glance, checking the Fedora GCC builds shows that libquadmath is only enabled on x86_64/ppc64le/ia64:


%ifarch %{ix86} x86_64 ia64 ppc64le
%global build_libquadmath 1
%else
%global build_libquadmath 0
%endif

Second, there was this somewhat recent bug in upstream GCC (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96016) that says libquadmath fails to configure on aarch64 because it tries to detect if __float128 is a supported type on the architecture - and it isn't for aarch64.

This begs the question, what is different about the CI builds for aarch64 and the original reporter's build? @ggardet can you please post your entire configure line so we can see the options you are building with?

ggardet · 2021-11-23T13:56:39Z

%ifarch aarch64
  %define julia_march armv8-a
%endif

# We need these compilation flags to avoid error when building MBEDTLS with
# GCC-11.
# Ref.: https://build.opensuse.org/package/show/security:tls/mbedtls
export CFLAGS="%{optflags} -Wno-stringop-overflow -Wno-maybe-uninitialized"
export CXXLAGS="%{optflags} -Wno-stringop-overflow -Wno-maybe-uninitialized"

%define julia_builddir %{_builddir}/%{name}/
make %{?_smp_mflags} \
                     MARCH=%{julia_march} \
%ifarch aarch64
                     JULIA_CPU_TARGET="generic" \
%endif
                     prefix=%{_prefix} \
                     bindir=%{_bindir} \
                     libdir=%{_libdir} \
                     libexecdir=%{_libexecdir} \
                     datarootdir=%{_datarootdir} \
                     includedir=%{_includedir} \
                     sysconfdir=%{_sysconfdir} \
                     %{juliabuildopts} \
                     release debug

With juliabuildopts being:

BUNDLE_DEBUG_LIBS=1 \
NO_GIT=1 \
USE_SYSTEM_LLVM=0 \
USE_SYSTEM_LIBUNWIND=1 \
USE_SYSTEM_READLINE=1 \
USE_SYSTEM_PCRE=1 \
USE_SYSTEM_LIBM=0 \
USE_SYSTEM_OPENLIBM=0 \
USE_SYSTEM_OPENSPECFUN=1 \
USE_SYSTEM_DSFMT=0 \
USE_SYSTEM_BLAS=1 \
LIBBLAS=-lopenblas \
LIBBLASNAME=libopenblas \
USE_SYSTEM_LAPACK=1 \
LIBLAPACK=-libopenblas \
LIBLAPACKNAME=libopenblas \
USE_SYSTEM_FFTW=1 \
LIBFFTWNAME=libfftw3_threads.so.3 \
LIBFFTWFNAME=libfftw3f_threads.so.3 \
USE_SYSTEM_GMP=1 \
USE_SYSTEM_MPFR=1 \
USE_SYSTEM_ARPACK=1 \
USE_SYSTEM_SUITESPARSE=1 \
USE_SYSTEM_ZLIB=1 \
USE_SYSTEM_GRISU=1 \
USE_SYSTEM_LIBUV=0 \
USE_SYSTEM_UTF8PROC=0 \
USE_SYSTEM_PATCHELF=1 \
USE_SYSTEM_P7ZIP=1 \
USE_SYSTEM_MBEDTLS=0 \
USE_SYSTEM_LIBSSH2=1 \
USE_SYSTEM_LIBGIT2=0 \
USE_SYSTEM_CURL=1 \
USE_SYSTEM_NGHTTP2=1 \
USE_SYSTEM_CSL=1 \
USE_MKL=0 \
USE_BLAS64=0 \
USE_LLVM_SHLIB=1 \
VERBOSE=1 \
USECLANG=0 \
USE_BINARYBUILDER=0

ggardet · 2021-11-23T16:24:37Z

What if you remove line

julia/base/Makefile

Line 213 in 8c97995

$(eval $(call symlink_system_library,CSL,libquadmath,0))

? But I'm confused, because this platform is Tier 1 and tested regularly 😕

If I drop this line, the build of julia 1.6.3 succeeds on aarch64 as well as on x86_64.

giordano · 2021-11-23T16:33:56Z

And what if you replace that line with

$(eval $(call symlink_system_library,CSL,libquadmath,0,ALLOW_FAILURE))

? Allowing the library not to be there is used in

julia/base/Makefile

Lines 215 to 218 in 8c97995

    
           # We allow libssp, libatomic and libgomp to fail as they are not available on all systems 
        
           $(eval $(call symlink_system_library,CSL,libssp,0,ALLOW_FAILURE)) 
        
           $(eval $(call symlink_system_library,CSL,libatomic,1,ALLOW_FAILURE)) 
        
           $(eval $(call symlink_system_library,CSL,libgomp,1,ALLOW_FAILURE))

which are other libraries which are not available on all platforms. Again, no idea how the build bot currently works at all.

imciner2 · 2021-11-23T19:01:17Z

It is probably succeeding on the buildbot because the official packaging is using the BinaryBuilder-provided CSL, which is automatically extracted into the local lib directory. The build showing the issue is using the system CSL (it defines USE_SYSTEM_CSL=1 on the build options), so the makefile then tries to make a symlink in the local library directory to the system's version of libquadmath. So the buildbot build step isn't actually doing this linking.

The way to fix this would be to guard this line inside an exclusion for aarch64 (I don't think we want to unconditionally make it allowed to fail, since in all other cases it being missing is probably a problem).

julia/base/Makefile

Line 213 in 8c97995

$(eval $(call symlink_system_library,CSL,libquadmath,0))

And now that I think about it some more, shouldn't that line be inside this check as well?

julia/base/Makefile

Line 210 in 8c97995

ifneq (,$(LIBGFORTRAN_VERSION))

Since I think libquadmath is only available if gfortran is available (or at least it is packaged in the gfortran CSL tar).

And as a note, this line should probably get a different comment (since it currently reads that the libquadmath is available on all platforms).

julia/deps/csl.mk

Lines 64 to 65 in 27c0291

    
           # These are all libraries that we should always have 
        
           $(eval $(call copy_csl,$(call versioned_libname,libquadmath,0)))

giordano · 2021-11-23T19:05:06Z

It is probably succeeding on the buildbot because the official packaging is using the BinaryBuilder-provided CSL

But CSL doesn't provide libquadmath for aarch64

imciner2 · 2021-11-23T19:13:31Z

It is probably succeeding on the buildbot because the official packaging is using the BinaryBuilder-provided CSL

But CSL doesn't provide libquadmath for aarch64

Yes, but because the build isn't being told to use the system version (via USE_SYSTEM_CSL=1), the symlink step of the build is never getting run. If you trace through the makefile, you find that the line

julia/base/Makefile

Line 213 in 8c97995

$(eval $(call symlink_system_library,CSL,libquadmath,0))

will only be run when this condition is satisfied, with $1 being CSL for libquadmath - making this line only run when the variable USE_SYSTEM_CSL is not equal to 0.

julia/base/Makefile

Lines 183 to 185 in 8c97995

    
           ifneq ($$(USE_SYSTEM_$1),0) 
        
           SYMLINK_SYSTEM_LIBRARIES += symlink_$2 
        
           endif

Because that line actually adds the symlink target to the list of targets to run in the full symlink target here

julia/base/Makefile

Line 268 in 8c97995

symlink_system_libraries: $(SYMLINK_SYSTEM_LIBRARIES)

So because USE_SYSTEM_CSL=1 is given in the build options, the symlink_system_libraries step of the build will try to symlink libquadmath.so into the local directory. On the buildbot version though, USE_SYSTEM_CSL=0 is used, so symlink_system_libraries will not try to make a symlink.

ggardet · 2021-11-24T08:14:07Z

And what if you replace that line with
$(eval $(call symlink_system_library,CSL,libquadmath,0,ALLOW_FAILURE))
? Allowing the library not to be there is used in

julia/base/Makefile

Lines 215 to 218 in 8c97995

# We allow libssp, libatomic and libgomp to fail as they are not available on all systems

$(eval $(call symlink_system_library,CSL,libssp,0,ALLOW_FAILURE))

$(eval $(call symlink_system_library,CSL,libatomic,1,ALLOW_FAILURE))

$(eval $(call symlink_system_library,CSL,libgomp,1,ALLOW_FAILURE))

which are other libraries which are not available on all platforms. Again, no idea how the build bot currently works at all.

Build also succeeds with ALLOW_FAILURE.

imciner2 · 2021-11-25T15:47:45Z

I should have some time to pull out my aarch64 board and make the needed changes to the makefile this weekend and will submit a PR after that.

giordano · 2021-11-25T15:50:35Z

Might also be good to look into #43071 🙂

imciner2 · 2021-11-25T16:05:53Z

Might also be good to look into #43071 slightly_smiling_face

That one seems to have been fixed by a clean checkout of the branch, so it probably was just a weird state issue. Were you thinking of a different issue?

giordano · 2021-11-25T16:11:41Z

That one seems to have been fixed by a clean checkout of the branch

...and manually setting override HAVE_SSP := 0. It appears libssp is also required on that platform, which is another library which isn't actually there:

julia/Make.inc

Lines 888 to 894 in f458b07

    
           # If we are running on aarch64 (e.g. ARMv8 or ARM64), set certain options automatically 
        
           ifneq (,$(findstring aarch64,$(ARCH))) 
        
           OPENBLAS_DYNAMIC_ARCH:=0 
        
           OPENBLAS_TARGET_ARCH:=ARMV8 
        
           USE_BLAS64:=1 
        
           BINARY:=64 
        
           HAVE_SSP:=1

CoelacanthusHex · 2023-04-25T14:55:37Z

Second, there was this somewhat recent bug in upstream GCC (gcc.gnu.org/bugzilla/show_bug.cgi?id=96016) that says libquadmath fails to configure on aarch64 because it tries to detect if __float128 is a supported type on the architecture - and it isn't for aarch64.

As mention in upstream report above, libquadmath is only used in the situation which has no 128bit long double type. In Aarch64 and riscv, it has 128bit long double type. So julia shouldn't use libquadmath on these architectures. It can be detected by check sizeof(long double) == 8.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96016#c1

ViralBShah · 2023-06-09T21:14:41Z

@ggardet Are you able to try with 1.9.1 or master?

ggardet · 2023-06-12T09:44:42Z

@ggardet Are you able to try with 1.9.1 or master?

Still the same error with julia 1.9.1 and gcc13, built for openSUSE Tumbleweed aarch64.

ViralBShah · 2023-07-19T03:29:26Z

We have been reliably building on aarch64 for a while now. Please reopen if still an issue with the latest release or master.

uncomfyhalomacro · 2024-05-12T14:30:56Z

@ggardet this might be too late but i found out that the gcc specfile in opensuse disabled quadmath... i am currently forcing julia to use the patched libraries so i can update it to 1.10.3. Unfortunately, like i mentioned, aarch64 will be disabled :)

ggardet · 2024-05-27T07:25:22Z

This is still broken with 1.10.3:

[15962s] '/home/abuild/rpmbuild/BUILD/julia-1.10.3/build/usr/bin/7z' -> '/usr/bin/7z'
[15962s] ln -sf /usr/lib64/libopenlibm.so.4 /home/abuild/rpmbuild/BUILD/julia-1.10.3/build/usr/lib64/julia/libopenlibm.so
[15962s] ln -sf /usr/lib64/libgcc_s.so.1 /home/abuild/rpmbuild/BUILD/julia-1.10.3/build/usr/lib64/julia/libgcc_s.so.1
[15962s] ln -sf /usr/lib64/libgfortran.so.5 /home/abuild/rpmbuild/BUILD/julia-1.10.3/build/usr/lib64/julia/libgfortran.so.5
[15962s] System library symlink failure: Unable to locate libquadmath.so.0 on your system!
[15962s] make[1]: *** [Makefile:246: /home/abuild/rpmbuild/BUILD/julia-1.10.3/build/usr/lib64/julia/libquadmath.so.0] Error 1
[15962s] make: *** [Makefile:82: julia-base] Error 2
[15962s] make: *** Waiting for unfinished jobs....

But I cannot re-open.

uncomfyhalomacro · 2024-05-27T23:54:20Z

This is still broken with 1.10.3:

[15962s] '/home/abuild/rpmbuild/BUILD/julia-1.10.3/build/usr/bin/7z' -> '/usr/bin/7z'
[15962s] ln -sf /usr/lib64/libopenlibm.so.4 /home/abuild/rpmbuild/BUILD/julia-1.10.3/build/usr/lib64/julia/libopenlibm.so
[15962s] ln -sf /usr/lib64/libgcc_s.so.1 /home/abuild/rpmbuild/BUILD/julia-1.10.3/build/usr/lib64/julia/libgcc_s.so.1
[15962s] ln -sf /usr/lib64/libgfortran.so.5 /home/abuild/rpmbuild/BUILD/julia-1.10.3/build/usr/lib64/julia/libgfortran.so.5
[15962s] System library symlink failure: Unable to locate libquadmath.so.0 on your system!
[15962s] make[1]: *** [Makefile:246: /home/abuild/rpmbuild/BUILD/julia-1.10.3/build/usr/lib64/julia/libquadmath.so.0] Error 1
[15962s] make: *** [Makefile:82: julia-base] Error 2
[15962s] make: *** Waiting for unfinished jobs....

But I cannot re-open.

I think you should open a ticket to the openSUSE bugzilla. like i said, libquadmath is disabled in opensuse aarch64 of gcc. check out the specfile

EDIT: see https://build.opensuse.org/projects/devel:gcc/packages/gcc13/files/gcc13.spec?expand=1 line 50

imciner2 · 2024-05-28T00:24:22Z

I think you should open a ticket to the openSUSE bugzilla. like i said, libquadmath is disabled in opensuse aarch64 of gcc. check out the specfile

As I said above, I don't think libquadmath is supported for aarch64, so our linking to it is the error here, not the fact it is missing in the distros.

(I can't find anything that seems to say for certain that aarch64 isn't supported with libquadmath, so maybe @fxcoudert can comment on that?)

uncomfyhalomacro · 2024-05-28T00:51:12Z

i am not saying that libquadmath isn't supported. it's that it's disabled in opensuse so i suggested to open a ticket to opensuse bugzilla. you can see the line 50 from the link I posted, aarch64 was not added as the libquadmath_arch. since it's disabled, it also means Julia can't build because it can't locate a non-existing libquadmath.so.

I maintain both julia and juliaup in openSUSE. you can see why I disabled aarch64 starting from line 264 https://build.opensuse.org/projects/openSUSE:Factory/packages/julia/files/julia.spec?expand=1

EDIT: I still hope I am wrong but I am not too hopeful because that line 50 from the gcc link is why. I don't know when that happened tbh.

ViralBShah · 2024-05-28T03:29:59Z

How do we build Julia on aarch64 linux in our build infrastructure (presumably which is ubuntu)?

DilumAluthge · 2024-05-28T03:39:01Z

USE_BINARYBUILDER=0

In the Base Julia Buildkite CI, we do not have this flag set. Thus, our CI uses BinaryBuilder to provide various binary dependencies.

ggardet · 2024-05-28T08:32:32Z

According to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96016 libquadmath is not supported on aarch64. libquadmath is not enabled on aarch64 within Fedora and Debian either.

uncomfyhalomacro · 2024-05-28T09:19:53Z

According to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96016 libquadmath is not supported on aarch64. libquadmath is not enabled on aarch64 within Fedora and Debian either.

I guess it won't be a surprise that openSUSE have the same idea and also disabled libquadmath on aarch64. I guess this means we really cannot fix this issue then by ourselves and hope that one day libquadmath is properly supported (?).

BUT, this comment from the discussion is interesting https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96016#c1

If long double is 128bit fp already, then glibc has full support of it. So you dont need libquadmath at all. It is only there if long double is not 128bit long double and glibc does not have support for the __float128 type.

Does this mean that we don't really need libquadmath???

I will open a ticket to bugzilla and confirm if that's the case or might open a question to https://forums.opensuse.org

imciner2 · 2024-05-28T09:27:59Z

I guess this means we really cannot fix this issue then by ourselves and hope that one day libquadmath is properly supported (?).

No, as I said earlier in the thread during the analysis of the issue, the problem lies inside the Julia Makefiles/build system. The error is occurring when trying to make symlinks to the libraries, not when doing any actual building.

fxcoudert · 2024-05-28T09:28:23Z

On aarch64-linux, the 128-bit floating-point type is long double. Therefore, libquadmath is not built because it is not necessary, the libc (usually glibc) is in charge of providing runtime support for math and I/O on this type, because it is a standard type.

On aarch64-darwin, long double is the same as double (64-bit fp type), and the compiler does supports __float128 as a 128-bit floating-point type. It then provides runtime support through libquadmath.

On other aarch64 targets, I do not know.

ViralBShah · 2024-05-28T15:56:22Z

No, as I said earlier in the thread during the analysis of the issue, the problem lies inside the Julia Makefiles/build system. The error is occurring when trying to make symlinks to the libraries, not when doing any actual building.

But how come it doesn't break in CI, since we regularly build aarch64 linux builds?

giordano · 2024-05-28T16:00:37Z

That has been answered three years ago already: we don't touch that code path in our builds.

fxcoudert · 2024-05-28T16:09:10Z

A logical fix would be this:

diff --git a/base/Makefile b/base/Makefile
index 9a6c0d0d03..febee53a9d 100644
--- a/base/Makefile
+++ b/base/Makefile
@@ -249,12 +249,12 @@ endif
 ifneq (,$(LIBGFORTRAN_VERSION))
 $(eval $(call symlink_system_library,CSL,libgfortran,$(LIBGFORTRAN_VERSION)))
 endif
-$(eval $(call symlink_system_library,CSL,libquadmath,0))
 $(eval $(call symlink_system_library,CSL,libstdc++,6))
-# We allow libssp, libatomic and libgomp to fail as they are not available on all systems
+# We allow libssp, libatomic, libgomp and libquadmath to fail as they are not available on all systems
 $(eval $(call symlink_system_library,CSL,libssp,0,ALLOW_FAILURE))
 $(eval $(call symlink_system_library,CSL,libatomic,1,ALLOW_FAILURE))
 $(eval $(call symlink_system_library,CSL,libgomp,1,ALLOW_FAILURE))
+$(eval $(call symlink_system_library,CSL,libquadmath,0,ALLOW_FAILURE))
 $(eval $(call symlink_system_library,PCRE,libpcre2-8))
 $(eval $(call symlink_system_library,DSFMT,libdSFMT))
 $(eval $(call symlink_system_library,LIBBLASTRAMPOLINE,libblastrampoline))

Edit: I see it was already proposed by @giordano at #41613 (comment)

uncomfyhalomacro · 2024-05-29T09:02:06Z

@ggardet Can you please test one of the binaries built in https://build.opensuse.org/projects/home:uncomfyhalomacro:branches:science/packages/julia/repositories/openSUSE_Tumbleweed/binaries ? I would really appreciate if you can test it. I don't own an aarch64 machine sadly.

ggardet · 2024-05-29T13:24:57Z

@ggardet Can you please test one of the binaries built in https://build.opensuse.org/projects/home:uncomfyhalomacro:branches:science/packages/julia/repositories/openSUSE_Tumbleweed/binaries ? I would really appreciate if you can test it. I don't own an aarch64 machine sadly.

Build works, but I get the following error on run:

ERROR: Unable to find compatible target in cached code image.
Target 0 (neoverse-n1): Rejecting this target due to use of runtime-disabled features

I guess the build machine is a neoverse-n1 while mine is not.

giordano · 2024-05-29T13:30:38Z

That's because the build system should set JULIA_CPU_TARGETS during the build, for example something like https://github.com/JuliaCI/julia-buildkite/blob/933c6d5fa18fe8168a1ec134d7cef82f8cfa5be0/utilities/build_envs.sh#L56-L70

JULIA_CPU_TARGETS="generic;cortex-a57;thunderx2t99;carmel,clone_all;apple-m1,base(3);neoverse-512tvb,base(3)"

See e.g. https://discourse.julialang.org/t/unexpected-precompilation-in-binder-based-on-docker-image/114473

ggardet · 2024-05-29T13:40:47Z

That's because the build system should set JULIA_CPU_TARGETS during the build, for example something like https://github.com/JuliaCI/julia-buildkite/blob/933c6d5fa18fe8168a1ec134d7cef82f8cfa5be0/utilities/build_envs.sh#L56-L70
JULIA_CPU_TARGETS="generic;cortex-a57;thunderx2t99;carmel,clone_all;apple-m1,base(3);neoverse-512tvb,base(3)"
See e.g. https://discourse.julialang.org/t/unexpected-precompilation-in-binder-based-on-docker-image/114473

I used JULIA_CPU_TARGET="generic;neoverse-n1" which was missing a S. Retrying.
And it worked on an AWS M6g machine as it is compatible with neoverse-n1.

uncomfyhalomacro · 2024-05-29T13:41:00Z

That's because the build system should set JULIA_CPU_TARGETS during the build, for example something like https://github.com/JuliaCI/julia-buildkite/blob/933c6d5fa18fe8168a1ec134d7cef82f8cfa5be0/utilities/build_envs.sh#L56-L70
JULIA_CPU_TARGETS="generic;cortex-a57;thunderx2t99;carmel,clone_all;apple-m1,base(3);neoverse-512tvb,base(3)"
See e.g. https://discourse.julialang.org/t/unexpected-precompilation-in-binder-based-on-docker-image/114473

Thanks for the heads up! I will update it.

uncomfyhalomacro · 2024-05-29T23:31:28Z

@ggardet we can finally close this right? see #54605

…54605) Fix #41613. Co-authored-by: FX Coudert <[email protected]> (cherry picked from commit e5549c2)

…uliaLang#54605) Fix JuliaLang#41613. Co-authored-by: FX Coudert <[email protected]>

ViralBShah added building Build system, or building Julia or its dependencies system:arm ARMv7 and AArch64 labels Feb 25, 2022

jan-bar mentioned this issue Apr 27, 2023

Can gocv package OpenCV into a binary file through cgo? hybridgroup/gocv#1056

Open

ViralBShah closed this as completed Jul 19, 2023

giordano reopened this May 27, 2024

ViralBShah added the system:linux Affects only Linux label May 27, 2024

ViralBShah mentioned this issue May 28, 2024

Allow libquadmath to also fail as it is not available on all systems #54605

Merged

giordano closed this as completed in #54605 May 30, 2024

giordano closed this as completed in e5549c2 May 30, 2024

KristofferC pushed a commit that referenced this issue Jun 4, 2024

Allow libquadmath to also fail as it is not available on all systems (#…

9e2cb49

…54605) Fix #41613. Co-authored-by: FX Coudert <[email protected]> (cherry picked from commit e5549c2)

KristofferC pushed a commit that referenced this issue Jun 19, 2024

Allow libquadmath to also fail as it is not available on all systems (#…

7c22da6

…54605) Fix #41613. Co-authored-by: FX Coudert <[email protected]> (cherry picked from commit e5549c2)

lazarusA pushed a commit to lazarusA/julia that referenced this issue Jul 12, 2024

Allow libquadmath to also fail as it is not available on all systems (J…

ddd486b

…uliaLang#54605) Fix JuliaLang#41613. Co-authored-by: FX Coudert <[email protected]>

Julia fails to build on on aarch64 because libquadmath.so is not available #41613

Julia fails to build on on aarch64 because libquadmath.so is not available #41613

Comments

ggardet commented Jul 16, 2021

Seelengrab commented Jul 16, 2021 • edited Loading

ggardet commented Jul 16, 2021

Seelengrab commented Jul 16, 2021

Seelengrab commented Jul 16, 2021

giordano commented Jul 16, 2021

ggardet commented Jul 20, 2021

ggardet commented Nov 23, 2021

giordano commented Nov 23, 2021

imciner2 commented Nov 23, 2021

ggardet commented Nov 23, 2021

ggardet commented Nov 23, 2021

giordano commented Nov 23, 2021 • edited Loading

imciner2 commented Nov 23, 2021

giordano commented Nov 23, 2021

imciner2 commented Nov 23, 2021 • edited Loading

ggardet commented Nov 24, 2021

imciner2 commented Nov 25, 2021

giordano commented Nov 25, 2021

imciner2 commented Nov 25, 2021

giordano commented Nov 25, 2021

CoelacanthusHex commented Apr 25, 2023 • edited Loading

ViralBShah commented Jun 9, 2023

ggardet commented Jun 12, 2023

ViralBShah commented Jul 19, 2023

uncomfyhalomacro commented May 12, 2024

ggardet commented May 27, 2024

uncomfyhalomacro commented May 27, 2024 • edited Loading

imciner2 commented May 28, 2024

uncomfyhalomacro commented May 28, 2024 • edited Loading

ViralBShah commented May 28, 2024

DilumAluthge commented May 28, 2024

ggardet commented May 28, 2024

uncomfyhalomacro commented May 28, 2024 • edited Loading

imciner2 commented May 28, 2024

fxcoudert commented May 28, 2024

ViralBShah commented May 28, 2024 • edited Loading

giordano commented May 28, 2024

fxcoudert commented May 28, 2024 • edited Loading

uncomfyhalomacro commented May 29, 2024

ggardet commented May 29, 2024

giordano commented May 29, 2024 • edited Loading

ggardet commented May 29, 2024

uncomfyhalomacro commented May 29, 2024

uncomfyhalomacro commented May 29, 2024

Seelengrab commented Jul 16, 2021 •

edited

Loading

giordano commented Nov 23, 2021 •

edited

Loading

imciner2 commented Nov 23, 2021 •

edited

Loading

CoelacanthusHex commented Apr 25, 2023 •

edited

Loading

uncomfyhalomacro commented May 27, 2024 •

edited

Loading

uncomfyhalomacro commented May 28, 2024 •

edited

Loading

uncomfyhalomacro commented May 28, 2024 •

edited

Loading

ViralBShah commented May 28, 2024 •

edited

Loading

fxcoudert commented May 28, 2024 •

edited

Loading

giordano commented May 29, 2024 •

edited

Loading