Mason Protter (Jun 16 2021 at 20:38): Mason Protter (Jun 16 2021 at 20:38):I recently did a system upgrade and now I'm getting errors when trying to build julia from source. This is happening both on master and on earlier versions that I definitely have successfully built before, so I think the problem is on my end. Here's the end of the compile log on a fresh git clone of the repo:
[mason@mason-pc julia-dev]$ make clean && make
[...]
CC src/init.o
CC src/task.o
CC src/array.o
CC src/dump.o
CC src/staticdata.o
CC src/toplevel.o
CC src/jl_uv.o
CC src/datatype.o
CC src/simplevector.o
CC src/runtime_intrinsics.o
CC src/precompile.o
CC src/threading.o
CC src/partr.o
CC src/stackwalk.o
CC src/gc.o
CC src/gc-debug.o
CC src/gc-pages.o
CC src/gc-stacks.o
CC src/method.o
CC src/jlapi.o
CC src/signal-handling.o
CC src/safepoint.o
CC src/timing.o
CC src/subtype.o
CC src/crc32c.o
CC src/APInt-C.o
CC src/processor.o
CC src/ircode.o
CC src/opaque_closure.o
CC src/jitlayers.o
CC src/aotcompile.o
CC src/debuginfo.o
CC src/disasm.o
CC src/llvm-simdloop.o
CC src/llvm-muladd.o
CC src/llvm-final-gc-lowering.o
CC src/llvm-pass-helpers.o
CC src/llvm-late-gc-lowering.o
/home/mason/build/julia-dev/src/llvm-late-gc-lowering.cpp: In member function ‘void LateLowerGCFrame::LiftPhi(State&, llvm::PHINode*)’:
/home/mason/build/julia-dev/src/llvm-late-gc-lowering.cpp:729:39: warning: ‘unsigned int llvm::VectorType::getNumElements() const’ is deprecated: Calling this function via a base VectorType is deprecated. Either call getElementCount() and handle the case where Scalable is true or cast to FixedVectorType. [-Wdeprecated-declarations]
729 | NumRoots = VTy->getNumElements();
| ~~~~~~~~~~~~~~~~~~~^~
In file included from /home/mason/build/julia-dev/usr/include/llvm/IR/Constants.h:31,
from /home/mason/build/julia-dev/src/llvm-late-gc-lowering.cpp:14:
/home/mason/build/julia-dev/usr/include/llvm/IR/DerivedTypes.h:535:10: note: declared here
535 | unsigned VectorType::getNumElements() const {
| ^~~~~~~~~~
CC src/llvm-lower-handlers.o
CC src/llvm-gc-invariant-verifier.o
CC src/llvm-propagate-addrspaces.o
CC src/llvm-multiversioning.o
CC src/llvm-alloc-opt.o
CC src/cgmemmgr.o
CC src/llvm-api.o
CC src/llvm-remove-addrspaces.o
CC src/llvm-remove-ni.o
CC src/llvm-julia-licm.o
CC src/llvm-demote-float16.o
LINK usr/lib/libjulia-internal.so.1.8
/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/mason/build/julia-dev/usr/lib/libjulia-internal.so.1.8] Error 1
make: *** [Makefile:76: julia-src-release] Error 2
Any clue what might be going wrong?
Takafumi Arakaki (tkf) (Jun 16 2021 at 20:47):I wonder if it's a compatibility issue with GCC 11 which looks pretty new https://gcc.gnu.org/gcc-11/
Takafumi Arakaki (tkf) (Jun 16 2021 at 20:48):or more like libstdc++
Mason Protter (Jun 16 2021 at 20:48):Hm interesting yeah I am on Gcc11
[mason@mason-pc julia-dev]$ pacman -Q gcc
gcc 11.1.0-1
ok, I'll be careful to not update my arch for a while :)
Mason Protter (Jun 16 2021 at 20:51):Hm, https://archlinux.org/packages/core/x86_64/gcc/ says that it was released a while ago, I think I've updated gcc more recently than that and built julia but maybe not
Mason Protter (Jun 16 2021 at 20:51):Is anyone else on gcc 11.1 and able to build julia?
Max Köhler (Jun 16 2021 at 20:52):I can give it a try, just a sec
Max Köhler (Jun 16 2021 at 21:03):yes I can reproduce it on master
CC src/init.o
CC src/task.o
CC src/array.o
CC src/dump.o
CC src/staticdata.o
CC src/toplevel.o
CC src/jl_uv.o
CC src/datatype.o
CC src/simplevector.o
CC src/runtime_intrinsics.o
CC src/precompile.o
CC src/threading.o
CC src/partr.o
CC src/stackwalk.o
CC src/gc.o
CC src/gc-debug.o
CC src/gc-pages.o
CC src/gc-stacks.o
CC src/method.o
CC src/jlapi.o
CC src/signal-handling.o
CC src/safepoint.o
CC src/timing.o
CC src/subtype.o
CC src/crc32c.o
CC src/APInt-C.o
CC src/processor.o
CC src/ircode.o
CC src/opaque_closure.o
CC src/jitlayers.o
CC src/aotcompile.o
CC src/debuginfo.o
CC src/disasm.o
CC src/llvm-simdloop.o
CC src/llvm-muladd.o
CC src/llvm-final-gc-lowering.o
CC src/llvm-pass-helpers.o
CC src/llvm-late-gc-lowering.o
/home/max/repos/julia/src/llvm-late-gc-lowering.cpp: In Elementfunktion »void LateLowerGCFrame::LiftPhi(State&, llvm::PHINode*)«:
/home/max/repos/julia/src/llvm-late-gc-lowering.cpp:729:39: Warnung: »unsigned int llvm::VectorType::getNumElements() const« ist veraltet: Calling this function via a base VectorType is deprecated. Either call getElementCount() and handle the case where Scalable is true or cast to FixedVectorType. [-Wdeprecated-declarations]
729 | NumRoots = VTy->getNumElements();
| ~~~~~~~~~~~~~~~~~~~^~
In Datei, eingebunden von /home/max/repos/julia/usr/include/llvm/IR/Constants.h:31,
von /home/max/repos/julia/src/llvm-late-gc-lowering.cpp:14:
/home/max/repos/julia/usr/include/llvm/IR/DerivedTypes.h:535:10: Anmerkung: hier deklariert
535 | unsigned VectorType::getNumElements() const {
| ^~~~~~~~~~
CC src/llvm-lower-handlers.o
CC src/llvm-gc-invariant-verifier.o
CC src/llvm-propagate-addrspaces.o
CC src/llvm-multiversioning.o
CC src/llvm-alloc-opt.o
CC src/cgmemmgr.o
CC src/llvm-api.o
CC src/llvm-remove-addrspaces.o
CC src/llvm-remove-ni.o
CC src/llvm-julia-licm.o
CC src/llvm-demote-float16.o
LINK usr/lib/libjulia-internal.so.1.8
/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: Fehler: ld gab 1 als Ende-Status zurück
make[1]: *** [Makefile:300: /home/max/repos/julia/usr/lib/libjulia-internal.so.1.8] Fehler 1
make: *** [Makefile:76: julia-src-release] Fehler 2
Actually, libjulia-internal is linked to an internal libstdc++. So, I'm not sure why the build process is trying to access the header installed system-wide.
Simeon Schaub (Jun 16 2021 at 22:29):See https://github.com/JuliaLang/julia/issues/40703
Simeon Schaub (Jun 16 2021 at 22:30):I just installed gcc10 and followed these instructions: https://github.com/JuliaLang/julia/issues/40703#issuecomment-847903078
Simeon Schaub (Jun 16 2021 at 22:31):I know that @Mosè Giordano is currently working on compiling gcc11 for Yggdrasil, which should fix this.
Mason Protter (Jun 16 2021 at 22:36):Nice, thanks!
Mosè Giordano (Jun 16 2021 at 22:43):Yeah, if I manage to fix gcc 11 for macOS, it's an ungodly mess
Mosè Giordano (Jun 17 2021 at 01:14):And after 4 hours of debugging I'm about to give up, the source code of GCC doesn't make any sense to me, I fail to see how things can possibly work
Mosè Giordano (Jun 17 2021 at 20:35):For the record, I ended up opening an issue in GCC, my modest understanding is that it's broken. And the broken component (libasan) actually comes from llvm. So don't hold your breath for a fix directly in Julia anytime soon
Adam non-jedi Beckmeyer (Jun 17 2021 at 20:39):Wait. You're telling me that even when building Julia is broken because of gcc, it's still because of llvm!? Julia and llvm certainly have a special relationship.
Mosè Giordano (Jun 17 2021 at 20:46):Yeah, I was surprised as well, but they apparently bundle some stuff maintained in llvm-project
Mosè Giordano (Jun 17 2021 at 20:49):In fact I was unsure where to open the issue: in gcc (I got the error when building gcc) or llvm (the code is actually maintained there)? I went with gcc for the time being and maybe I'll escalate to llvm if I don't get answers in a few days. I really don't understand how this piece of code can work at all
Mason Protter (Jun 17 2021 at 20:53):Big yikes
Mosè Giordano (Jun 17 2021 at 21:06):in case someone with more C-fu than me wants to have a look and help out, this is the issue:
functions __lsan_is_turned_off and __lsan_default_suppressions are implemented at https://github.com/gcc-mirror/gcc/blob/6816a44dfe1b5fa9414490a18a4aa723b6f38f18/libsanitizer/lsan/lsan_common.cpp#L1042-L1052 in a #if !SANITIZER_SUPPORTS_WEAK_HOOKS guard, so if SANITIZER_SUPPORTS_WEAK_HOOKS is 1 these functions aren't implemented at all. the problem is that these functions are used unconditionally in the same file and SANITIZER_SUPPORTS_WEAK_HOOKS on macOS with SDK >= 10.9 (we use 10.12) is 1 (https://github.com/gcc-mirror/gcc/blob/487be9201c96d0a5c7c325339bc9c4916e933ed8/libsanitizer/sanitizer_common/sanitizer_internal_defs.h#L76-L78)
Mosè Giordano (Jun 17 2021 at 21:47):to add more confusion, these symbols are annotated as weak in the header file. this seems to work when building for Linux (I can see the weak symbol is libasan.so), but not macOS :confused: :sob:
Edit: new working hypothesis is that it's the intermediate cross-compiler that is "broken" and isn't generating weak symbols correctly
Mosè Giordano (Jun 18 2021 at 23:56):for the record, I found the error in GCC build system, fixed it in Yggdrasil and submitted the patch upstream. GCC 11 will come soon :tm: in Julia
Mason Protter (Jun 19 2021 at 00:33):My hero
Last updated: Nov 06 2024 at 04:40 UTC