libstdc++.so.6 is outdated and breaks RCall and others on recent Linux distros
laborg opened this issue · 38 comments
As discussed on slack with and discourse ( https://discourse.julialang.org/t/glibcxx-3-4-26-not-found-in-rcall/29113/2 ) the problem of an outdated, bundled libstdc++ (e.g. Julia 1.3.1) compared to the libstdc++ provided by the OS (e.g. Ubuntu 19.10) is that it breaks RCall.jl when Rcpp is in play due to missing GLIBCXX symbols.
I quote @staticfloat
So Ubuntu 19.10 is based on GCC 9, huh. We don't have a GCC 9 shard yet; we've been using GCC 7.2 on the buildbots (which correspondes to GLIBCXX_3.4.24), but there's no reason why we can't put our own libstdc++.so.6 into a julia binary-dist. Right now we've been bundling the libstdc++.so.6 that we get from the build environment, but it would be even better for us to just use an appropriate CompilerSupportLibraries_jll release, and craft those releases to be as compatible as possible (e.g. use the absolute newest libstdc++.so.6, the appropriate libgfortran.so.X, etc...)
An intermediate workaround is described here: https://discourse.julialang.org/t/glibcxx-3-4-26-not-found-in-rcall/29113/11?u=laborg
My plan to address this is:
- Add GCC 9 shard to BinaryBuilder (JuliaPackaging/Yggdrasil#358, JuliaPackaging/BinaryBuilder.jl#599)
- Alter CompilerSupportLibraries_jll to always ship the latest libstdc++, rather than an older one.
- Change the Julia
make binary-distroutine to ship CompilerSupportLibraries_jll alongside julia, rather than pulling the libraries that belong to the system compiler.
@staticfloat You already merged a couple PRs from your plan - how far are you away from completing this? Thanks
Making good progress! The new CompilerSupportLibraries_jll enacts my plan, and I've been cranking away on #33973 which will ship it by default with Julia.
I am not sure I understand how "always shipping the latest libstdc++" is gonna work, though? Suppose your fix is deployed in Julia 1.5, and suppose for the sake of the argument this is the new LTS. Then is the plan to keep releasing updates to 1.5.x promptly whenever a new libstdc++ is released, until it is no more the LTS version? And then everybody who updates GCC on their computer must remember to also update Julia at the same time, else things break down?
Hmm, to be honest, I have a hard time seeing how that will be viable in practice. Quite possible I am missing part of the plan, though. Now, if all packages in Julia that build or link external code where to consequently use a C/C++ compiler installed via Julia, instead of a system compiler, that might work. But as soon as any external code is pulled in, there is a chance it requires a newer C++ library than what Julia has, no?
You're correct in that there is a tension between Julia's precompiled binaries and system-compiled binaries. We have to work to balance two competing interests:
-
Precompiled binaries (typically generated through
BinaryBuilder.jl) that use one of the compilers we provide -
User-compiled binaries (using a user-provided compiler).
There are a lot of ways that something can be incompatible, and we do our best to deal with all of them. In the case of libstdc++, we basically just need to have a libstdc++ that is newer than all pieces of code that are trying to be loaded. Note that in the case of Julia, 99% of the time the libstdc++ that ships with Julia is much newer than the libstdc++ present on the system. For the last few years, we've been shipping a libstdc++ that comes from GCC 7, which was newer then the system compiler shipped by everything up to Debian Buster or Ubuntu Bionic. Because most users are using binaries that come from BinaryBuilder, and we tend to compile with very old compilers whenever possible there (so as to maximize the chance that a user who built Julia themselves from source can still use the precompiled binaries), the binaries we generate typically "just worked".
So the only corner case that is difficult in this scenario is when the user custom-compiles a library with their system compiler, and the system compiler is newer than what will ship with Julia. Luckily, both of these situations are rare; fewer and fewer users are compiling their own libraries for use in Julia (a trend we definitely want to encourage, as it reduces package installation errors dramatically) and for those that do, us shipping a more recent libstdc++ with Julia will allow a broader range of compiler support.
We do not yet have a way to "update" the libraries that ship with Julia easily, but in the future, we may have a method by which a user can rebuild their system image and incorporate newer versions of the libraries that ship with Julia, thereby updating the libstdc++ that is shipped with Julia. That's speculative at this point though.
I wanted to add that this appeared in a completely different context. After an update of CImGui.jl my application segfaulted. Setting the environment variable ´LIBGL_DEBUG´ showed that this is again is due to the libstdc++ mismatch.
libGL: Can't open configuration file /etc/drirc: No such file or directory.
libGL: Can't open configuration file /home/gerhard/.drirc: No such file or directory.
libGL: Can't open configuration file /etc/drirc: No such file or directory.
libGL: Can't open configuration file /home/gerhard/.drirc: No such file or directory.
libGL: pci id for fd 30: 8086:9bca, driver iris
libGL: MESA-LOADER: failed to open /usr/lib/x86_64-linux-gnu/dri/iris_dri.so: /home/gerhard/julia-1.4.2/bin/../lib/julia/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /lib/x86_64-linux-gnu/libLLVM-9.so.1)
libGL: MESA-LOADER: failed to open \$${ORIGIN}/dri/iris_dri.so: \$${ORIGIN}/dri/iris_dri.so: cannot open shared object file: No such file or directory
libGL: MESA-LOADER: failed to open /usr/lib/dri/iris_dri.so: /usr/lib/dri/iris_dri.so: cannot open shared object file: No such file or directory
libGL error: MESA-LOADER: failed to open iris (search paths /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri)
libGL error: failed to load driver: iris
libGL: Can't open configuration file /etc/drirc: No such file or directory.
libGL: Can't open configuration file /home/gerhard/.drirc: No such file or directory.
libGL: pci id for fd 30: 8086:9bca, driver iris
libGL: MESA-LOADER: failed to open /usr/lib/x86_64-linux-gnu/dri/iris_dri.so: /home/gerhard/julia-1.4.2/bin/../lib/julia/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /lib/x86_64-linux-gnu/libLLVM-9.so.1)
libGL: MESA-LOADER: failed to open \$${ORIGIN}/dri/iris_dri.so: \$${ORIGIN}/dri/iris_dri.so: cannot open shared object file: No such file or directory
libGL: MESA-LOADER: failed to open /usr/lib/dri/iris_dri.so: /usr/lib/dri/iris_dri.so: cannot open shared object file: No such file or directory
libGL error: MESA-LOADER: failed to open iris (search paths /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri)
libGL error: failed to load driver: iris
libGL: MESA-LOADER: failed to open /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so: /home/gerhard/julia-1.4.2/bin/../lib/julia/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /lib/x86_64-linux-gnu/libLLVM-9.so.1)
libGL: MESA-LOADER: failed to open \$${ORIGIN}/dri/swrast_dri.so: \$${ORIGIN}/dri/swrast_dri.so: cannot open shared object file: No such file or directory
libGL: MESA-LOADER: failed to open /usr/lib/dri/swrast_dri.so: /usr/lib/dri/swrast_dri.so: cannot open shared object file: No such file or directory
libGL error: MESA-LOADER: failed to open swrast (search paths /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri)
libGL error: failed to load driver: swrast
┌ Error: GLFW ERROR: code VERSION_UNAVAILABLE msg: GLX: Failed to create context: GLXBadFBConfig
└ @ ActTools.Hub /projects/actibelt/code/act-jl-tools/src/hub/hubconsole.jl:128
signal (11): Segmentation fault
in expression starting at REPL[2]:1
glfwSetWindowUserPointer at /home/gerhard/.julia/artifacts/a1e91245761ea49ceed2c708a278f8d90a3d88ad/lib/libglfw.so (unknown line)
CreateWindow at /home/gerhard/.julia/packages/GLFW/g1nX6/src/glfw3.jl:490
CreateWindow at /home/gerhard/.julia/packages/GLFW/g1nX6/src/glfw3.jl:487 [inlined]
hub at /projects/actibelt/code/act-jl-tools/src/hub/hubconsole.jl:232
unknown function (ip: 0x7fd361c3185c)
_jl_invoke at /buildworker/worker/package_linux64/build/src/gf.c:2159 [inlined]
jl_apply_generic at /buildworker/worker/package_linux64/build/src/gf.c:2323
jl_apply at /buildworker/worker/package_linux64/build/src/julia.h:1700 [inlined]
do_call at /buildworker/worker/package_linux64/build/src/interpreter.c:369
eval_value at /buildworker/worker/package_linux64/build/src/interpreter.c:458
eval_stmt_value at /buildworker/worker/package_linux64/build/src/interpreter.c:409 [inlined]
eval_body at /buildworker/worker/package_linux64/build/src/interpreter.c:817
jl_interpret_toplevel_thunk at /buildworker/worker/package_linux64/build/src/interpreter.c:911
jl_toplevel_eval_flex at /buildworker/worker/package_linux64/build/src/toplevel.c:819
jl_toplevel_eval_flex at /buildworker/worker/package_linux64/build/src/toplevel.c:769
jl_toplevel_eval_in at /buildworker/worker/package_linux64/build/src/toplevel.c:848
eval at ./boot.jl:331
_jl_invoke at /buildworker/worker/package_linux64/build/src/gf.c:2145 [inlined]
jl_apply_generic at /buildworker/worker/package_linux64/build/src/gf.c:2323
eval_user_input at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.4/REPL/src/REPL.jl:86
run_backend at /home/gerhard/.julia/packages/Revise/jVsKo/src/Revise.jl:1023
_jl_invoke at /buildworker/worker/package_linux64/build/src/gf.c:2159 [inlined]
jl_apply_generic at /buildworker/worker/package_linux64/build/src/gf.c:2323
jl_apply at /buildworker/worker/package_linux64/build/src/julia.h:1700 [inlined]
do_call at /buildworker/worker/package_linux64/build/src/interpreter.c:369
eval_value at /buildworker/worker/package_linux64/build/src/interpreter.c:458
eval_stmt_value at /buildworker/worker/package_linux64/build/src/interpreter.c:409 [inlined]
eval_body at /buildworker/worker/package_linux64/build/src/interpreter.c:817
jl_interpret_toplevel_thunk at /buildworker/worker/package_linux64/build/src/interpreter.c:911
jl_toplevel_eval_flex at /buildworker/worker/package_linux64/build/src/toplevel.c:819
jl_toplevel_eval_in at /buildworker/worker/package_linux64/build/src/toplevel.c:848
eval at ./boot.jl:331
_jl_invoke at /buildworker/worker/package_linux64/build/src/gf.c:2145 [inlined]
jl_apply_generic at /buildworker/worker/package_linux64/build/src/gf.c:2323
eval_user_input at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.4/REPL/src/REPL.jl:86
macro expansion at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.4/REPL/src/REPL.jl:118 [inlined]
#26 at ./task.jl:358
_jl_invoke at /buildworker/worker/package_linux64/build/src/gf.c:2145 [inlined]
jl_apply_generic at /buildworker/worker/package_linux64/build/src/gf.c:2323
jl_apply at /buildworker/worker/package_linux64/build/src/julia.h:1700 [inlined]
start_task at /buildworker/worker/package_linux64/build/src/task.c:687
unknown function (ip: (nil))
Allocations: 119940032 (Pool: 119907715; Big: 32317); GC: 97
Segmentation fault (core dumped)
@Gnimuc , this might be of interest for you.
Is there a workaround for this?
Do I need to build Julia myself?
@ambiso The workaround is linked in the first post:
An intermediate workaround is described here: https://discourse.julialang.org/t/glibcxx-3-4-26-not-found-in-rcall/29113/11?u=laborg
ubuntu Release 20.04 LTS (Focal Fossa) 64-bit
Kernel Linux 5.4.0-40-generic x86_64
Official https://julialang.org/ release Version 1.4.2 (2020-05-23)
Fresh install of all of them yesterday, July 16, 2020!
using RCall;
R"require(forecast)";
Warning: RCall.jl: Loading required package: forecast │ Error: package or namespace load failed for ‘forecast’ in dyn.load(file, DLLpath = DLLpath, ...): │ unable to load shared object '/home/..../R/x86_64-pc-linux-gnu-library/4.0/Rcpp/libs/Rcpp.so': │ /usr/local/julia/julia-1.4.2/bin/../lib/julia/libstdc++.so.6: version GLIBCXX_3.4.26' not found (required by /home/..../R/x86_64-pc-linux-gnu-library/4.0/Rcpp/libs/Rcpp.so)
└ @ RCall /home/..../.julia/packages/RCall/Qzssx/src/io.jl:160`
I had a crashed update on ubuntu 16.04 and had to clear system disc and start over.
I chose to use current releases, since my system was very old and ran into this very old julia bug that kills my program.
Isn't it about time the official releases get it fixed?
@ambiso The workaround is linked in the first post:
An intermediate workaround is described here: https://discourse.julialang.org/t/glibcxx-3-4-26-not-found-in-rcall/29113/11?u=laborg
This workaround now segfaults for me on Julia 1.5.0 (official x64 binary) when running:
using GLFW, ModernGL
window = GLFW.Window(resolution = (10, 10), major = 3, minor = 3, visible = false, focus = false)
with GLFW 3.3.2.
Is there a roadmap to get this issue fixed? E.g. building with a non-legacy libstdc++.so?
The segfault happens here:
[#0] 0x7fffbc521d2d → llvm::TargetPassConfig::addPass(llvm::Pass*, bool, bool)()
[#1] 0x7fffbc524bf8 → llvm::TargetPassConfig::addRegAssignmentOptimized()()
[#2] 0x7fffbc524fbe → llvm::TargetPassConfig::addOptimizedRegAlloc()()
[#3] 0x7fffbc52521d → llvm::TargetPassConfig::addMachinePasses()()
[#4] 0x7fffbc283152 → mov rax, r12
[#5] 0x7fffbc287e41 → llvm::LLVMTargetMachine::addPassesToEmitFile(llvm::legacy::PassManagerBase&, llvm::raw_pwrite_stream&, llvm::raw_pwrite_stream*, llvm::CodeGenFileType, bool, llvm::MachineModuleInfoWrapperPass*)()
[#6] 0x7fffc1213c00 → pop rdx
[#7] 0x7fffc116cd5a → mov rdi, QWORD PTR [rbx+0x20]
[#8] 0x7fffc11ae03b → jmp 0x7fffc11adc97
[#9] 0x7fffc0e5d9c8 → xor eax, eaxinside of libLLVM-10.so
LLVM 10?
Yes. Does Julia require a legacy version of LLVM?
Julia 1.5.0 should not be using LLVM 10; that segfault sounds like you are somehow forcing Julia to use a different LLVM than the one it ships with, which will cause segfaults; LLVM is not compatible across versions.
You're right according to ldd it should be using LLVM9:
$ ldd `which julia`
# ...
libLLVM-9jl.so => /usr/bin/../lib/julia/libLLVM-9jl.so
# ...I was thinking this could maybe be a misattribution of gdb but at least libLLVM-10 is loaded as can be seen from vmmap:
0x00007fffb9d26000 0x00007fffba514000 0x0000000000000000 r-- /usr/lib/libLLVM-10.so
0x00007fffba514000 0x00007fffbd2e6000 0x00000000007ee000 r-x /usr/lib/libLLVM-10.so
0x00007fffbd2e6000 0x00007fffbe9b8000 0x00000000035c0000 r-- /usr/lib/libLLVM-10.so
0x00007fffbe9b8000 0x00007fffbe9b9000 0x0000000004c92000 --- /usr/lib/libLLVM-10.so
0x00007fffbe9b9000 0x00007fffbeeb6000 0x0000000004c92000 r-- /usr/lib/libLLVM-10.so
0x00007fffbeeb6000 0x00007fffbf0de000 0x000000000518f000 rw- /usr/lib/libLLVM-10.so
Here is the full information from gdb
gdb julia 18:29:36 139 ↵
GEF for linux ready, type `gef' to start, `gef config' to configure
80 commands loaded for GDB 9.2 using Python engine 3.8
Reading symbols from julia...
gef➤ run
Starting program: /usr/bin/julia
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7ffff35d9640 (LWP 70673)]
[New Thread 0x7fffe0de0640 (LWP 70674)]
[New Thread 0x7fffe05df640 (LWP 70675)]
[New Thread 0x7fffdbdde640 (LWP 70676)]
[New Thread 0x7fffd95dd640 (LWP 70677)]
[New Thread 0x7fffd6ddc640 (LWP 70678)]
[New Thread 0x7fffd45db640 (LWP 70679)]
[New Thread 0x7fffd1dda640 (LWP 70680)]
_
_ _ _(_)_ | Documentation: https://docs.julialang.org
(_) | (_) (_) |
_ _ _| |_ __ _ | Type "?" for help, "]?" for Pkg help.
| | | | | | |/ _` | |
| | |_| | | | (_| | | Version 1.5.0 (2020-08-01)
_/ |\__'_|_|_|\__'_| | Official https://julialang.org/ release
|__/ |
julia> using GLFW, ModernGL
julia> window = GLFW.Window(resolution = (10, 10), major = 3, minor = 3, visible = false, focus = false)
[New Thread 0x7fffb9b33640 (LWP 70687)]
[New Thread 0x7fffb91f1640 (LWP 70688)]
[New Thread 0x7fffb89f0640 (LWP 70689)]
[New Thread 0x7fffabfff640 (LWP 70690)]
[New Thread 0x7fffa37fe640 (LWP 70691)]
[New Thread 0x7fffab7fe640 (LWP 70692)]
[New Thread 0x7fffaaffd640 (LWP 70693)]
[New Thread 0x7fffaa7fc640 (LWP 70694)]
[New Thread 0x7fffa9ffb640 (LWP 70695)]
[New Thread 0x7fffa97fa640 (LWP 70696)]
[New Thread 0x7fffa8ff9640 (LWP 70697)]
[New Thread 0x7fffa3fff640 (LWP 70698)]
[New Thread 0x7fffa2ffd640 (LWP 70699)]
[New Thread 0x7fffa27fc640 (LWP 70700)]
[New Thread 0x7fffa1ffb640 (LWP 70701)]
[New Thread 0x7fffa17fa640 (LWP 70702)]
Thread 16 "julia:sh1" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffaaffd640 (LWP 70693)]
0x00007fffbacb3d2d in llvm::TargetPassConfig::addPass(llvm::Pass*, bool, bool) () from /usr/bin/../lib/libLLVM-10.so
[ Legend: Modified register | Code | Heap | Stack | String ]
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── registers ────
$rax : 0x0
$rbx : 0x00007fff98008660 → 0x00007fffbee44f08 → 0x00007fffbc42db00 → lea rax, [rip+0x2a16fd9] # 0x7fffbee44ae0
$rcx : 0x1
$rdx : 0x1
$rsp : 0x00007fffaaff4f20 → 0x00007fffbd382d86 → "Machine Instruction Scheduler"
$rbp : 0x00007fff98008660 → 0x00007fffbee44f08 → 0x00007fffbc42db00 → lea rax, [rip+0x2a16fd9] # 0x7fffbee44ae0
$rsi : 0x0
$rdi : 0x00007fff98008660 → 0x00007fffbee44f08 → 0x00007fffbc42db00 → lea rax, [rip+0x2a16fd9] # 0x7fffbee44ae0
$rip : 0x00007fffbacb3d2d → <llvm::TargetPassConfig::addPass(llvm::Pass*,+0> mov rbp, QWORD PTR [rsi+0x10]
$r8 : 0xca
$r9 : 0x1
$r10 : 0x0
$r11 : 0x246
$r12 : 0x0
$r13 : 0x00007fff980092e0 → 0x00007fffbedfb940 → 0x00007fffbaaa9520 → mov rax, QWORD PTR [rip+0x43fe459] # 0x7fffbeea7980
$r14 : 0x1
$r15 : 0x1
$eflags: [zero carry parity adjust sign trap INTERRUPT direction overflow RESUME virtualx86 identification]
$cs: 0x0033 $ss: 0x002b $ds: 0x0000 $es: 0x0000 $fs: 0x0000 $gs: 0x0000
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── stack ────
0x00007fffaaff4f20│+0x0000: 0x00007fffbd382d86 → "Machine Instruction Scheduler" ← $rsp
0x00007fffaaff4f28│+0x0008: 0x000000000000001d
0x00007fffaaff4f30│+0x0010: 0x0000000000000002
0x00007fffaaff4f38│+0x0018: 0x000000000000001d
0x00007fffaaff4f40│+0x0020: 0x00007fff98032900 → 0x00007ff867fbe0a2
0x00007fffaaff4f48│+0x0028: 0x0000000000000023 ("#"?)
0x00007fffaaff4f50│+0x0030: 0x0000000000000023 ("#"?)
0x00007fffaaff4f58│+0x0038: 0x0000000000000000
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── code:x86:64 ────
0x7fffbacb3d22 <llvm::TargetPassConfig::addPass(llvm::Pass*,+0> push rbx
0x7fffbacb3d23 <llvm::TargetPassConfig::addPass(llvm::Pass*,+0> mov rbx, rdi
0x7fffbacb3d26 <llvm::TargetPassConfig::addPass(llvm::Pass*,+0> sub rsp, 0xc8
→ 0x7fffbacb3d2d <llvm::TargetPassConfig::addPass(llvm::Pass*,+0> mov rbp, QWORD PTR [rsi+0x10]
0x7fffbacb3d31 <llvm::TargetPassConfig::addPass(llvm::Pass*,+0> mov rax, QWORD PTR fs:0x28
0x7fffbacb3d3a <llvm::TargetPassConfig::addPass(llvm::Pass*,+0> mov QWORD PTR [rsp+0xb8], rax
0x7fffbacb3d42 <llvm::TargetPassConfig::addPass(llvm::Pass*,+0> xor eax, eax
0x7fffbacb3d44 <llvm::TargetPassConfig::addPass(llvm::Pass*,+0> mov rax, QWORD PTR [rdi+0x38]
0x7fffbacb3d48 <llvm::TargetPassConfig::addPass(llvm::Pass*,+0> cmp QWORD PTR [rdi+0x28], rbp
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── threads ────
[#0] Id 1, Name: "julia", stopped, reason: SIGSEGV
[#1] Id 2, Name: "julia", stopped, reason: SIGSEGV
[#2] Id 3, Name: "julia", stopped, reason: SIGSEGV
[#3] Id 4, Name: "julia", stopped, reason: SIGSEGV
[#4] Id 5, Name: "julia", stopped, reason: SIGSEGV
[#5] Id 6, Name: "julia", stopped, reason: SIGSEGV
[#6] Id 7, Name: "julia", stopped, reason: SIGSEGV
[#7] Id 8, Name: "julia", stopped, reason: SIGSEGV
[#8] Id 9, Name: "julia", stopped, reason: SIGSEGV
[#9] Id 10, Name: "julia:cs0", stopped, reason: SIGSEGV
[#10] Id 11, Name: "julia:disk$0", stopped, reason: SIGSEGV
[#11] Id 12, Name: "julia:disk$1", stopped, reason: SIGSEGV
[#12] Id 13, Name: "julia:disk$2", stopped, reason: SIGSEGV
[#13] Id 14, Name: "julia:disk$3", stopped, reason: SIGSEGV
[#14] Id 15, Name: "julia:sh0", stopped, reason: SIGSEGV
[#15] Id 16, Name: "julia:sh1", stopped, reason: SIGSEGV
[#16] Id 17, Name: "julia:sh2", stopped, reason: SIGSEGV
[#17] Id 18, Name: "julia:sh3", stopped, reason: SIGSEGV
[#18] Id 19, Name: "julia:sh4", stopped, reason: SIGSEGV
[#19] Id 20, Name: "julia:sh5", stopped, reason: SIGSEGV
[#20] Id 21, Name: "julia:shlo0", stopped, reason: SIGSEGV
[#21] Id 22, Name: "julia:shlo1", stopped, reason: SIGSEGV
[#22] Id 23, Name: "julia:shlo2", stopped, reason: SIGSEGV
[#23] Id 24, Name: "julia:shlo3", stopped, reason: SIGSEGV
[#24] Id 25, Name: "julia:gdrv0", stopped, reason: SIGSEGV
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── trace ────
[#0] 0x7fffbacb3d2d → llvm::TargetPassConfig::addPass(llvm::Pass*, bool, bool)()
[#1] 0x7fffbacb6bf8 → llvm::TargetPassConfig::addRegAssignmentOptimized()()
[#2] 0x7fffbacb6fbe → llvm::TargetPassConfig::addOptimizedRegAlloc()()
[#3] 0x7fffbacb721d → llvm::TargetPassConfig::addMachinePasses()()
[#4] 0x7fffbaa15152 → mov rax, r12
[#5] 0x7fffbaa19e41 → llvm::LLVMTargetMachine::addPassesToEmitFile(llvm::legacy::PassManagerBase&, llvm::raw_pwrite_stream&, llvm::raw_pwrite_stream*, llvm::CodeGenFileType, bool, llvm::MachineModuleInfoWrapperPass*)()
[#6] 0x7fffbf9a5c00 → pop rdx
[#7] 0x7fffbf8fed5a → mov rdi, QWORD PTR [rbx+0x20]
[#8] 0x7fffbf94003b → jmp 0x7fffbf93fc97
[#9] 0x7fffbf5ef9c8 → xor eax, eax
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
gef➤
Are you setting LD_LIBRARY_PATH?
No.
I've tried running under a clean environment but get the same results:
See this long gdb log
env -i - DISPLAY=:0 XDG_CACHE_HOME=/home/ambiso/.cache 18:43:31
XDG_CONFIG_HOME=/home/ambiso/.config
XDG_DATA_HOME=/home/ambiso/.local/share
XDG_RUNTIME_DIR=/run/user/1000
XDG_SEAT=seat0
XDG_SESSION_CLASS=user
XDG_SESSION_ID=1
XDG_SESSION_TYPE=tty
XDG_VTNR=1
XKB_DEFAULT_LAYOUT=us gdb julia
DISPLAY=:0
XDG_CACHE_HOME=/home/ambiso/.cache
GEF for linux ready, type `gef' to start, `gef config' to configure
80 commands loaded for GDB 9.2 using Python engine 3.8
Reading symbols from julia...
gef➤ run
Starting program: /usr/bin/julia
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7ffff35d9640 (LWP 72090)]
[New Thread 0x7fffe0de0640 (LWP 72094)]
[New Thread 0x7fffe05df640 (LWP 72095)]
[New Thread 0x7fffdbdde640 (LWP 72096)]
[New Thread 0x7fffd95dd640 (LWP 72097)]
[New Thread 0x7fffd6ddc640 (LWP 72098)]
[New Thread 0x7fffd45db640 (LWP 72099)]
[New Thread 0x7fffd3dda640 (LWP 72100)]
_
_ _ _(_)_ | Documentation: https://docs.julialang.org
(_) | (_) (_) |
_ _ _| |_ __ _ | Type "?" for help, "]?" for Pkg help.
| | | | | | |/ _` | |
| | |_| | | | (_| | | Version 1.5.0 (2020-08-01)
_/ |\__'_|_|_|\__'_| | Official https://julialang.org/ release
|__/ |
julia> using GLFW, ModernGL
julia> window = GLFW.Window(resolution = (10, 10), major = 3, minor = 3, visible = false, focus = false)
[New Thread 0x7fffb9b33640 (LWP 72107)]
[New Thread 0x7fffb91f1640 (LWP 72108)]
[New Thread 0x7fffb89f0640 (LWP 72109)]
[New Thread 0x7fffabfff640 (LWP 72110)]
[New Thread 0x7fffa37fe640 (LWP 72111)]
[New Thread 0x7fffab7fe640 (LWP 72112)]
[New Thread 0x7fffaaffd640 (LWP 72113)]
[New Thread 0x7fffaa7fc640 (LWP 72114)]
[New Thread 0x7fffa9ffb640 (LWP 72115)]
[New Thread 0x7fffa97fa640 (LWP 72116)]
[New Thread 0x7fffa8ff9640 (LWP 72117)]
[New Thread 0x7fffa3fff640 (LWP 72118)]
[New Thread 0x7fffa2ffd640 (LWP 72119)]
[New Thread 0x7fffa27fc640 (LWP 72120)]
[New Thread 0x7fffa1ffb640 (LWP 72121)]
[New Thread 0x7fffa17fa640 (LWP 72122)]
Thread 16 "julia:sh1" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffaaffd640 (LWP 72113)]
0x00007fffbacb3d2d in llvm::TargetPassConfig::addPass(llvm::Pass*, bool, bool) () from /usr/bin/../lib/libLLVM-10.so
[ Legend: Modified register | Code | Heap | Stack | String ]
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── registers ────
$rax : 0x0
$rbx : 0x00007fff98008560 → 0x00007fffbee44f08 → 0x00007fffbc42db00 → lea rax, [rip+0x2a16fd9] # 0x7fffbee44ae0
$rcx : 0x1
$rdx : 0x1
$rsp : 0x00007fffaaff4f20 → 0x00007fffbd382d86 → "Machine Instruction Scheduler"
$rbp : 0x00007fff98008560 → 0x00007fffbee44f08 → 0x00007fffbc42db00 → lea rax, [rip+0x2a16fd9] # 0x7fffbee44ae0
$rsi : 0x0
$rdi : 0x00007fff98008560 → 0x00007fffbee44f08 → 0x00007fffbc42db00 → lea rax, [rip+0x2a16fd9] # 0x7fffbee44ae0
$rip : 0x00007fffbacb3d2d → <llvm::TargetPassConfig::addPass(llvm::Pass*,+0> mov rbp, QWORD PTR [rsi+0x10]
$r8 : 0xca
$r9 : 0x1
$r10 : 0x0
$r11 : 0x246
$r12 : 0x0
$r13 : 0x00007fff980091e0 → 0x00007fffbedfb940 → 0x00007fffbaaa9520 → mov rax, QWORD PTR [rip+0x43fe459] # 0x7fffbeea7980
$r14 : 0x1
$r15 : 0x1
$eflags: [zero carry parity adjust sign trap INTERRUPT direction overflow RESUME virtualx86 identification]
$cs: 0x0033 $ss: 0x002b $ds: 0x0000 $es: 0x0000 $fs: 0x0000 $gs: 0x0000
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── stack ────
0x00007fffaaff4f20│+0x0000: 0x00007fffbd382d86 → "Machine Instruction Scheduler" ← $rsp
0x00007fffaaff4f28│+0x0008: 0x000000000000001d
0x00007fffaaff4f30│+0x0010: 0x0000000000000002
0x00007fffaaff4f38│+0x0018: 0x000000000000001d
0x00007fffaaff4f40│+0x0020: 0x00007fff98036db0 → 0x00007ff867fb25d6
0x00007fffaaff4f48│+0x0028: 0x0000000000000023 ("#"?)
0x00007fffaaff4f50│+0x0030: 0x0000000000000023 ("#"?)
0x00007fffaaff4f58│+0x0038: 0x0000000000000000
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── code:x86:64 ────
0x7fffbacb3d22 <llvm::TargetPassConfig::addPass(llvm::Pass*,+0> push rbx
0x7fffbacb3d23 <llvm::TargetPassConfig::addPass(llvm::Pass*,+0> mov rbx, rdi
0x7fffbacb3d26 <llvm::TargetPassConfig::addPass(llvm::Pass*,+0> sub rsp, 0xc8
→ 0x7fffbacb3d2d <llvm::TargetPassConfig::addPass(llvm::Pass*,+0> mov rbp, QWORD PTR [rsi+0x10]
0x7fffbacb3d31 <llvm::TargetPassConfig::addPass(llvm::Pass*,+0> mov rax, QWORD PTR fs:0x28
0x7fffbacb3d3a <llvm::TargetPassConfig::addPass(llvm::Pass*,+0> mov QWORD PTR [rsp+0xb8], rax
0x7fffbacb3d42 <llvm::TargetPassConfig::addPass(llvm::Pass*,+0> xor eax, eax
0x7fffbacb3d44 <llvm::TargetPassConfig::addPass(llvm::Pass*,+0> mov rax, QWORD PTR [rdi+0x38]
0x7fffbacb3d48 <llvm::TargetPassConfig::addPass(llvm::Pass*,+0> cmp QWORD PTR [rdi+0x28], rbp
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── threads ────
[#0] Id 1, Name: "julia", stopped, reason: SIGSEGV
[#1] Id 2, Name: "julia", stopped, reason: SIGSEGV
[#2] Id 3, Name: "julia", stopped, reason: SIGSEGV
[#3] Id 4, Name: "julia", stopped, reason: SIGSEGV
[#4] Id 5, Name: "julia", stopped, reason: SIGSEGV
[#5] Id 6, Name: "julia", stopped, reason: SIGSEGV
[#6] Id 7, Name: "julia", stopped, reason: SIGSEGV
[#7] Id 8, Name: "julia", stopped, reason: SIGSEGV
[#8] Id 9, Name: "julia", stopped, reason: SIGSEGV
[#9] Id 10, Name: "julia:cs0", stopped, reason: SIGSEGV
[#10] Id 11, Name: "julia:disk$0", stopped, reason: SIGSEGV
[#11] Id 12, Name: "julia:disk$1", stopped, reason: SIGSEGV
[#12] Id 13, Name: "julia:disk$2", stopped, reason: SIGSEGV
[#13] Id 14, Name: "julia:disk$3", stopped, reason: SIGSEGV
[#14] Id 15, Name: "julia:sh0", stopped, reason: SIGSEGV
[#15] Id 16, Name: "julia:sh1", stopped, reason: SIGSEGV
[#16] Id 17, Name: "julia:sh2", stopped, reason: SIGSEGV
[#17] Id 18, Name: "julia:sh3", stopped, reason: SIGSEGV
[#18] Id 19, Name: "julia:sh4", stopped, reason: SIGSEGV
[#19] Id 20, Name: "julia:sh5", stopped, reason: SIGSEGV
[#20] Id 21, Name: "julia:shlo0", stopped, reason: SIGSEGV
[#21] Id 22, Name: "julia:shlo1", stopped, reason: SIGSEGV
[#22] Id 23, Name: "julia:shlo2", stopped, reason: SIGSEGV
[#23] Id 24, Name: "julia:shlo3", stopped, reason: SIGSEGV
[#24] Id 25, Name: "julia:gdrv0", stopped, reason: SIGSEGV
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── trace ────
[#0] 0x7fffbacb3d2d → llvm::TargetPassConfig::addPass(llvm::Pass*, bool, bool)()
[#1] 0x7fffbacb6bf8 → llvm::TargetPassConfig::addRegAssignmentOptimized()()
[#2] 0x7fffbacb6fbe → llvm::TargetPassConfig::addOptimizedRegAlloc()()
[#3] 0x7fffbacb721d → llvm::TargetPassConfig::addMachinePasses()()
[#4] 0x7fffbaa15152 → mov rax, r12
[#5] 0x7fffbaa19e41 → llvm::LLVMTargetMachine::addPassesToEmitFile(llvm::legacy::PassManagerBase&, llvm::raw_pwrite_stream&, llvm::raw_pwrite_stream*, llvm::CodeGenFileType, bool, llvm::MachineModuleInfoWrapperPass*)()
[#6] 0x7fffbf9a5c00 → pop rdx
[#7] 0x7fffbf8fed5a → mov rdi, QWORD PTR [rbx+0x20]
[#8] 0x7fffbf94003b → jmp 0x7fffbf93fc97
[#9] 0x7fffbf5ef9c8 → xor eax, eax
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
gef➤
Perhaps GLFW or ModernGL is bringing in LLVM somehow. Can you run inside of strace -e openat,open to see at what point LLVM 10 is loaded?
Looks like you're right.
In the beginning it's loading LLVM9
│ File: strace -e openat,open julia -e 'using GLFW, ModernGL; window = GLFW.Window(resolution = (10, 10), major = 3, minor = 3, visible = false, focus = false)'
───────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
1 │ openat(AT_FDCWD, "/etc/ld.so.preload", O_RDONLY|O_CLOEXEC) = 3
2 │ openat(AT_FDCWD, "/usr/bin/../lib/tls/x86_64/x86_64/libjulia.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
3 │ openat(AT_FDCWD, "/usr/bin/../lib/tls/x86_64/libjulia.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
4 │ openat(AT_FDCWD, "/usr/bin/../lib/tls/x86_64/libjulia.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
5 │ openat(AT_FDCWD, "/usr/bin/../lib/tls/libjulia.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
6 │ openat(AT_FDCWD, "/usr/bin/../lib/x86_64/x86_64/libjulia.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
7 │ openat(AT_FDCWD, "/usr/bin/../lib/x86_64/libjulia.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
8 │ openat(AT_FDCWD, "/usr/bin/../lib/x86_64/libjulia.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
9 │ openat(AT_FDCWD, "/usr/bin/../lib/libjulia.so.1", O_RDONLY|O_CLOEXEC) = 3
10 │ openat(AT_FDCWD, "/usr/bin/../lib/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
11 │ openat(AT_FDCWD, "/usr/bin/../lib/librt.so.1", O_RDONLY|O_CLOEXEC) = 3
12 │ openat(AT_FDCWD, "/usr/bin/../lib/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
13 │ openat(AT_FDCWD, "/usr/bin/../lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
14 │ openat(AT_FDCWD, "/usr/bin/../lib/julia/tls/x86_64/x86_64/libLLVM-9jl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
15 │ openat(AT_FDCWD, "/usr/bin/../lib/julia/tls/x86_64/libLLVM-9jl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
16 │ openat(AT_FDCWD, "/usr/bin/../lib/julia/tls/x86_64/libLLVM-9jl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
17 │ openat(AT_FDCWD, "/usr/bin/../lib/julia/tls/libLLVM-9jl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
18 │ openat(AT_FDCWD, "/usr/bin/../lib/julia/x86_64/x86_64/libLLVM-9jl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
19 │ openat(AT_FDCWD, "/usr/bin/../lib/julia/x86_64/libLLVM-9jl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
20 │ openat(AT_FDCWD, "/usr/bin/../lib/julia/x86_64/libLLVM-9jl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
21 │ openat(AT_FDCWD, "/usr/bin/../lib/julia/libLLVM-9jl.so", O_RDONLY|O_CLOEXEC) = 3
22 │ openat(AT_FDCWD, "/usr/bin/../lib/julia/libstdc++.so.6", O_RDONLY|O_CLOEXEC) = 3
But then after loading graphics drivers it seems to be loading LLVM-10 in line 718, possibly for shader compilation?
693 │ openat(AT_FDCWD, "/sys/devices/pci0000:00/0000:00:08.1/0000:06:00.0/device", O_RDONLY) = 22
694 │ openat(AT_FDCWD, "/sys/devices/pci0000:00/0000:00:08.1/0000:06:00.0/subsystem_vendor", O_RDONLY) = 22
695 │ openat(AT_FDCWD, "/sys/devices/pci0000:00/0000:00:08.1/0000:06:00.0/subsystem_device", O_RDONLY) = 22
696 │ openat(AT_FDCWD, "/sys/devices/pci0000:00/0000:00:08.1/0000:06:00.0/uevent", O_RDONLY) = 22
697 │ openat(AT_FDCWD, "/sys/devices/pci0000:00/0000:00:08.1/0000:06:00.0/vendor", O_RDONLY) = 22
698 │ openat(AT_FDCWD, "/sys/devices/pci0000:00/0000:00:08.1/0000:06:00.0/device", O_RDONLY) = 22
699 │ openat(AT_FDCWD, "/sys/devices/pci0000:00/0000:00:08.1/0000:06:00.0/subsystem_vendor", O_RDONLY) = 22
700 │ openat(AT_FDCWD, "/sys/devices/pci0000:00/0000:00:08.1/0000:06:00.0/subsystem_device", O_RDONLY) = 22
701 │ openat(AT_FDCWD, "/usr/share/drirc.d", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 21
702 │ openat(AT_FDCWD, "/usr/share/drirc.d/00-mesa-defaults.conf", O_RDONLY) = 21
703 │ openat(AT_FDCWD, "/etc/drirc", O_RDONLY) = -1 ENOENT (No such file or directory)
704 │ openat(AT_FDCWD, "/home/ambiso/.drirc", O_RDONLY) = -1 ENOENT (No such file or directory)
705 │ openat(AT_FDCWD, "/dev/dri", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 21
706 │ openat(AT_FDCWD, "/sys/devices/pci0000:00/0000:00:08.1/0000:06:00.0/uevent", O_RDONLY) = 22
707 │ openat(AT_FDCWD, "/sys/devices/pci0000:00/0000:00:08.1/0000:06:00.0/vendor", O_RDONLY) = 22
708 │ openat(AT_FDCWD, "/sys/devices/pci0000:00/0000:00:08.1/0000:06:00.0/device", O_RDONLY) = 22
709 │ openat(AT_FDCWD, "/sys/devices/pci0000:00/0000:00:08.1/0000:06:00.0/subsystem_vendor", O_RDONLY) = 22
710 │ openat(AT_FDCWD, "/sys/devices/pci0000:00/0000:00:08.1/0000:06:00.0/subsystem_device", O_RDONLY) = 22
711 │ openat(AT_FDCWD, "/sys/devices/pci0000:00/0000:00:08.1/0000:06:00.0/uevent", O_RDONLY) = 22
712 │ openat(AT_FDCWD, "/sys/devices/pci0000:00/0000:00:08.1/0000:06:00.0/vendor", O_RDONLY) = 22
713 │ openat(AT_FDCWD, "/sys/devices/pci0000:00/0000:00:08.1/0000:06:00.0/device", O_RDONLY) = 22
714 │ openat(AT_FDCWD, "/sys/devices/pci0000:00/0000:00:08.1/0000:06:00.0/subsystem_vendor", O_RDONLY) = 22
715 │ openat(AT_FDCWD, "/sys/devices/pci0000:00/0000:00:08.1/0000:06:00.0/subsystem_device", O_RDONLY) = 22
716 │ openat(AT_FDCWD, "/usr/lib/dri/tls/radeonsi_dri.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
717 │ openat(AT_FDCWD, "/usr/lib/dri/radeonsi_dri.so", O_RDONLY|O_CLOEXEC) = 21
718 │ openat(AT_FDCWD, "/usr/bin/../lib/libLLVM-10.so", O_RDONLY|O_CLOEXEC) = 21
719 │ openat(AT_FDCWD, "/usr/bin/../lib/libzstd.so.1", O_RDONLY|O_CLOEXEC) = 21
720 │ openat(AT_FDCWD, "/usr/bin/../lib/libsensors.so.5", O_RDONLY|O_CLOEXEC) = 21
721 │ openat(AT_FDCWD, "/usr/bin/../lib/libdrm_radeon.so.1", O_RDONLY|O_CLOEXEC) = 21
722 │ openat(AT_FDCWD, "/usr/bin/../lib/libelf.so.1", O_RDONLY|O_CLOEXEC) = 21
723 │ openat(AT_FDCWD, "/usr/bin/../lib/libdrm_amdgpu.so.1", O_RDONLY|O_CLOEXEC) = 21
724 │ openat(AT_FDCWD, "/usr/bin/../lib/libdrm_nouveau.so.2", O_RDONLY|O_CLOEXEC) = 21
725 │ openat(AT_FDCWD, "/usr/bin/../lib/libvulkan.so.1", O_RDONLY|O_CLOEXEC) = 21
Hmmmmm. Yeah, this is unfortunate. Can you open a new issue with this information, it's separate from this thread.
Note that this is only the case when using libstdc++.so.6.0.28. Either when blatantly replacing the library as suggested by the workarounds mentioned in this thread, or when building julia from scratch with that version of libstdc++ installed. (although I can't say anything about having other versions installed)
It looks like Julia v1.6.0-rc1 solves this issue; please reopen if you continue to have problems with it!
Hello @staticfloat!
Thanks for your efforts in narrowing down this issue. I am trying to build julia v1.6.0 on archlinux and it is not building with the same error.
It looks like Julia v1.6.0-rc1 solves this issue; please reopen if you continue to have problems with it!
I tried the following on a fresh clone:
git checkout v1.6.0-rc1
make
...and also v1.6.1 (the latest tag):
git checkout v1.6.1
make
...and it throws the same error:
ERROR: Unable to load dependent library /home/user/programs/julia/usr/bin/../lib/libjulia-internal.so.1
Message:/home/user/programs/julia/usr/bin/../lib/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /home/user/programs/julia/usr/bin/../lib/libjulia-internal.so.1)
make[1]: *** [sysimage.mk:61: /home/user/programs/julia/usr/lib/julia/corecompiler.ji] Error 1
make: *** [Makefile:82: julia-sysimg-ji] Error 2
Thanks in advance for any tip.
If you want to build from source, why don't you use the latest stable version, v1.6.1 at the moment? I also use archlinux and occasionally build from source on master and never have particular problems. Do you set specific variables to configure your build?
Also, why not using the official binaries instead of building from source?
Hello @giordano,
If you want to build from source, why don't you use the latest stable version,
v1.6.1at the moment? I also use archlinux and occasionally build from source onmasterand never have particular problems. Do you set specific variables to configure your build?
Sorry, I edited the comment a couple minutes after publishing it, I also tried v1.6.1 without success. My arch was updated today, but I don't see any package with a substantial change (e.g., gcc was already 11) as to prevent building julia (which I originally built ca. a month ago).
As for variables, I do not set any manually, but can check and then report here if you suspect that something in particular might be of interest.
Also, why not using the official binaries instead of building from source?
My original reason for building again both v1.5.0 and v1.6.0 (which I had running until today) was because of an issue with RCall and other packages not recognizing the system libstdc++ but instead the older one that comes with julia.
Thus, I was hoping that a fresh build might now solve it, since a ready binary would still use the older libstdc++.
I just tried to build the latest commit in the git tree with the following error:
/usr/bin/ld: ./codegen.o: in function `__gnu_cxx::new_allocator<llvm::Type*>::allocate(unsigned long, void const*)':
/usr/include/c++/11.1.0/ext/new_allocator.h:110: undefined reference to `std::__throw_bad_array_new_length()'
/usr/bin/ld: ./llvm-late-gc-lowering.o: in function `__gnu_cxx::new_allocator<int>::allocate(unsigned long, void const*)':
/usr/include/c++/11.1.0/ext/new_allocator.h:110: undefined reference to `std::__throw_bad_array_new_length()'
/usr/bin/ld: ./llvm-late-gc-lowering.o: in function `__gnu_cxx::new_allocator<unsigned int>::allocate(unsigned long, void const*)':
/usr/include/c++/11.1.0/ext/new_allocator.h:110: undefined reference to `std::__throw_bad_array_new_length()'
/usr/bin/ld: ./llvm-late-gc-lowering.o: in function `__gnu_cxx::new_allocator<int>::allocate(unsigned long, void const*)':
/usr/include/c++/11.1.0/ext/new_allocator.h:110: undefined reference to `std::__throw_bad_array_new_length()'
/usr/bin/ld: /usr/include/c++/11.1.0/ext/new_allocator.h:110: undefined reference to `std::__throw_bad_array_new_length()'
/usr/bin/ld: ./llvm-late-gc-lowering.o:/usr/include/c++/11.1.0/ext/new_allocator.h:110: more undefined references to `std::__throw_bad_array_new_length()' follow
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:300: /home/user/programs/julia/usr/lib/libjulia-internal.so.1.7] Error 1
make: *** [Makefile:76: julia-src-release] Error 2
Thanks for your comments!
My original reason for building again both v1.5.0 and v1.6.0 (which I had running until today) was because of an issue with RCall and other packages not recognizing the system libstdc++ but instead the older one that comes with julia.
Well, that issue was tracked in this ticket which is closed because it has been fixed in Julia v1.6 and the official binaries ship a much more recent version of libstdc++
My original reason for building again both v1.5.0 and v1.6.0 (which I had running until today) was because of an issue with RCall and other packages not recognizing the system libstdc++ but instead the older one that comes with julia.
Well, that issue was tracked in this ticket which is closed because it has been fixed in Julia v1.6 and the official binaries ship a much more recent version of libstdc++
Oh thanks you! I did not know that. Will try the official binaries, although I'd still like to understand why the build fails to recognize the system version. I will re-read carefully the issues associated to this one to see if I can figure it out. Please feel free to comment on it if you wish.
It might be worthwhile to reopen this issue (and maybe search for a better fix than simply updating the libstdc++ version). It is again happening (e.g. on nightly). I am trying to use GLMakie which seems to depend on GLFW which faces this issue [1] on Ubuntum 22.04. Deleting the shipped libstdc++ fixes the problem. The nightly on which I observed this was installed with juliaup's fork [2].
It see someone is also asking whether the symlinking can be done by juliaup itself [3]
1: JuliaGL/GLFW.jl#198
2: JuliaLang/juliaup#384
3: JuliaLang/juliaup#402
I apologize if I have misunderstood the status of this issue though. I imagine there is a good reason to not fix it, but I did not immediately see it while skimming through the comments.
I am a bit confused as to why these issues keep getting closed too. Yes, they will get fixed by upgrading Julia when Julia updates libstdc++, but will immediately break when the system libstdc++ is upgraded again.
There are other options than trying to keep libstdc++ pointing at the newest out of the bundled version and the system version (which I still think is an approach that could be made to work). Another option is that Julia could standardise that all Julia itself and all binary packages to be built with an old glibc which is the manylinux from Python works https://github.com/pypa/manylinux . Since we generally have forward compatibility from build version => run version, libstdc++ could not be bundled at all but instead made a run time dependency. This approach can turn into a bit of a pain in terms of deprecation schedules --- it essentially means all libraries have to keep building on old versions of GCC.
Another option is for special sub-point releases for Julia Linux binaries only to be made (automatically) as soon as new versions of libstdc++ become available, and users poked to upgrade to these whenever these types of errors happen. (Is there some automated way of catching these errors?) I guess this may be preferable to automating the symlink workaround.
I do think the current situation is quite bad for some users. Users of rolling release Linux distributions are not so uncommon these days, and while they are likely to be able to do the Googling to work around things themselves, this is friction that might be avoided.
Another option is that Julia could standardise that all Julia itself and all binary packages to be built with an old glibc which is the manylinux from Python works https://github.com/pypa/manylinux . Since we generally have forward compatibility from build version => run version, libstdc++ could not be bundled at all but instead made a run time dependency. This approach can turn into a bit of a pain in terms of deprecation schedules --- it essentially means all libraries have to keep building on old versions of GCC.
This is already done and also misses the point of the issue entirely: problems happen when some system libraries built with recent versions of GCC are involved
Hi @giordano. Thanks for the response. I do actually understand that part of the issue. I will admit I am not an expert on all the details. I don't completely understand why certain taboos exist, e.g. against implementing what is the standard workaround in juliaup. I hope you can be patient with me because I believe (perhaps naively) that we might be able to come to some reasonable solution together.
Could you please tell me: if everything is built against a sufficiently old libstdc++, why is a new libstdc++ shipped, when we could instead assume that a newer libstdc++ is available from the system?
when we could instead assume that a newer libstdc++ is available from the system?
Because that's a pretty wrong assumption. Have you ever tried to run software on a cluster which ships GCC 4.8?
I too have trouble understanding the entirety of the problem and current solution. Currently I do need to delete a file in julia/lib in order to use a number of Julia libraries. I currently do not know which one of these is true:
- This is a bug that will be fixed "once and for all" in Julia
- This is a bug in Julia that will reoccur every so often and there will always be some time periods where I need to manually delete a julia/lib file
- This is a common bug in many Julia packages that should be fixed by the package authors, not by changes in core Julia
- This is not considered a bug, just a standard sysadmin task (in which case maybe we can document it on the install page?)
I understand that a lot of work has already been poured into this (including by volunteers working for free) and I really appreciate it. I just hope I can understand this issue (that is quite frequently affecting me) better and this is the only venue where I can ask.
Currently it's "2". I actually already opened a PR almost four months ago to get libstdc++ from GCC 12 in Julia (#45582), it's working everywhere apart from Windows, but I don't have a Windows machine nor have much experience with that system anyway. I've been asking for help, but no one helped me, I can't do miracles 🤷
What would be nice is a situation where we automatically detect system libstdc++ and decide whether to use that one or julia's one. The main problem is how to do this without
- killing startup time
- and without modifying in-place julia's installation (not always possible)
I don't think there is a technical solution to this problem, which is the reason why for the time being we need to live with "2".
Side note, I don't think this is such a widespread as you believe. For one, I never run into this because my use of Julia doesn't involve loading system libraries. This happens for example when people need some video libraries, or R libraries like in the case reported at the top of this issue, I don't need any of them.
RCall is currently broken on my system also, due to this bug.
If you're here from a search engine looking for a workaround, copy the system libstdc++.so.6 to the Julia folder.
E.g. (on archlinux with juliaup)
cp /usr/lib/libstdc++.so.6 ~/.julia/juliaup/julia-1.8.1+0.x64/lib/julia/
Have you ever tried to run software on a cluster which ships GCC 4.8?
I have not dealt with that particular scenario (more generally, I have managed to escape limitations of cluster environments using Singularity), but I understand the issue. It makes sense that Julia wants to support these very old environments, however, that should not get in the way of also supporting very new environments.
and without modifying in-place julia's installation (not always possible)
This is what I have been proposing as my primary proposal. I'm glad you agree that after consideration of the other options, this is the only one really left. You are correct that it is not always possible, but it should usually be possible at the point that Julia is installed. What I propose is that a hook could be included in the Julia distribution that will just emit a warning in case it can't write to Julia, and it's up to whichever installation process is used (e.g. juliaup) to decide whether it is appropriate to invoke it and when. Hopefully such a hook being bundled with Julia would give the juliaup folks some confidence that it's all kosher.
At this point, I'm satisfied that this is the best solution available at the moment, and will come back with a proof-of-concept/stawman. Hopefully this will give us a better starting point that won't end up with us talking past each other.
The best long-term solution here will likely be JuliaCI/julia-buildkite#205, which:
- Won't require modifying any files in the Julia distribution
- Won't require or involve any external tooling (such as Juliaup)
The best long-term solution here will likely be JuliaCI/julia-buildkite#205, which:
- Won't require modifying any files in the Julia distribution
- Won't require or involve any external tooling (such as Juliaup)
Okay, great! This is basically the "do it at startup approach" implied by giordano's "killing startup time" from above. In fact since it just requires 1 symbol value comparison and an extra dlopen(...), it probably won't kill startup time after all. I'll cancel work on the hook based approach.
(P.S. Ideally, this issue would still be reopened.)