Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Llvm13 #36229

Closed
wants to merge 30 commits into from
Closed

Llvm13 #36229

wants to merge 30 commits into from

Conversation

motorto
Copy link
Contributor

@motorto motorto commented Mar 19, 2022

This adds LLVM 13 and updates from LLVM 12.

Work-in-progress

The following packages were removed:

  • beignet -- upstream is dead
  • rundird -- has been deprecated by upstream which recommends using dumb_runtime_dir

The following packages were updated or patched:

  • SPIRV-LLVM-Translator
  • SPIRV-Headers
  • ispc
  • river
  • zig

Rebuilt packages:

(rebuilt based on output of: xrevshlib libllvm{12,13} )

  • bcc
  • bpftrace
  • ccls
  • clazy
  • codelite
  • ghdl
  • gnome-builder
  • include-what-you-use
  • juCi++
  • kdevelop
  • ldc
  • mesa
  • qt5
  • rtags
  • rust
  • shiboken2
  • tilix

Updated Templates:

  • Chromium

(I am probably missing some packages)

Thanks @DBLouis for your hard work!

[ci skip]

I nuked the #35895

@motorto motorto mentioned this pull request Mar 19, 2022
@dkwo
Copy link
Contributor

dkwo commented Mar 20, 2022

Thanks. Can you fix the trivial linting?

srcpkgs/ghdl/template:138: Last line is empty
srcpkgs/llvm12/template:8: use SPDX id for 'metapackage' license or see Manual.md

And perhaps then let it run on CI?
I'd also like this to be merged, as river does not work well with xwayland at the moment.

@q66 Can you review this?

@motorto
Copy link
Contributor Author

motorto commented Mar 20, 2022

Thanks. Can you fix the trivial linting?

Will do that, I will rebuild all packages locally. Could you check that all the packages that I am rebuilding need to be rebuild ?

@dkwo / @ifreund could you try to compile llvm13 on your pc ? My dual core is failing and I am not sure if its because of my low hardware

@dkwo
Copy link
Contributor

dkwo commented Mar 20, 2022 via email

@dkwo
Copy link
Contributor

dkwo commented Mar 21, 2022

on x86_64, it now fails with

[3060/7532] Generating html Sphinx documentation for libunwind into "/builddir/llvm-project-13.0.1.src/llvm/build/projects/libunwind/docs/html"                                                                                                                                  
FAILED: projects/libunwind/docs/CMakeFiles/docs-libunwind-html /builddir/llvm-project-13.0.1.src/llvm/build/projects/libunwind/docs/CMakeFiles/docs-libunwind-html                                                                                                               
cd /builddir/llvm-project-13.0.1.src/llvm/build/projects/libunwind/docs && /usr/bin/cmake -E env /usr/bin/sphinx-build -b html -d /builddir/llvm-project-13.0.1.src/llvm/build/projects/libunwind/docs/_doctrees-libunwind-html -q -t builder-html /builddir/llvm-project-13.0.1.
src/libunwind/docs /builddir/llvm-project-13.0.1.src/llvm/build/projects/libunwind/docs/html                                            
Traceback (most recent call last):                                                                                                      
  File "/usr/lib/python3.10/site-packages/pkg_resources/__init__.py", line 579, in _build_master                                        
    ws.require(__requires__)                                     
  File "/usr/lib/python3.10/site-packages/pkg_resources/__init__.py", line 897, in require                                              
    needed = self.resolve(parse_requirements(requirements))                                                                             
  File "/usr/lib/python3.10/site-packages/pkg_resources/__init__.py", line 788, in resolve                                              
    raise VersionConflict(dist, req).with_context(dependent_req)                                                                        
pkg_resources.ContextualVersionConflict: (docutils 0.18.1 (/usr/lib/python3.10/site-packages), Requirement.parse('docutils<0.18,>=0.14'), {'Sphinx'})                                                                                                                            
                                                                                                                                        
During handling of the above exception, another exception occurred:
                                                                                                                                        
Traceback (most recent call last):                     
  File "/usr/bin/sphinx-build", line 33, in <module>                                                                                    
    sys.exit(load_entry_point('Sphinx==4.2.0', 'console_scripts', 'sphinx-build')())                                                    
  File "/usr/bin/sphinx-build", line 25, in importlib_load_entry_point                                                                  
    return next(matches).load()          
  File "/usr/lib/python3.10/importlib/metadata/__init__.py", line 171, in load                                                          
    module = import_module(match.group('module'))
  File "/usr/lib/python3.10/importlib/__init__.py", line 126, in import_module                                                          
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1050, in _gcd_import                                                                       
  File "<frozen importlib._bootstrap>", line 1027, in _find_and_load                                                                    
  File "<frozen importlib._bootstrap>", line 1006, in _find_and_load_unlocked                                                           
  File "<frozen importlib._bootstrap>", line 688, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 883, in exec_module                                                               
  File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed                                                          
  File "/usr/lib/python3.10/site-packages/sphinx/cmd/build.py", line 25, in <module>                                                    
    from sphinx.application import Sphinx                                                                                               
  File "/usr/lib/python3.10/site-packages/sphinx/application.py", line 43, in <module>                                                  
    from sphinx.registry import SphinxComponentRegistry                                                                                 
  File "/usr/lib/python3.10/site-packages/sphinx/registry.py", line 24, in <module>                                                                                                                                                                                              
    from pkg_resources import iter_entry_points                                                                                                                                                                                                                                  
  File "/usr/lib/python3.10/site-packages/pkg_resources/__init__.py", line 3247, in <module>                                            
    def _initialize_master_working_set():           
  File "/usr/lib/python3.10/site-packages/pkg_resources/__init__.py", line 3221, in _call_aside                                                                                                                                                                                  
    f(*args, **kwargs)                               
  File "/usr/lib/python3.10/site-packages/pkg_resources/__init__.py", line 3259, in _initialize_master_working_set                      
    working_set = WorkingSet._build_master()                                                                                                                                                                                                                                     
  File "/usr/lib/python3.10/site-packages/pkg_resources/__init__.py", line 581, in _build_master                                        
    return cls._build_from_requirements(__requires__)
  File "/usr/lib/python3.10/site-packages/pkg_resources/__init__.py", line 594, in _build_from_requirements                                                                                                                                                                      
    dists = ws.resolve(reqs, Environment())
  File "/usr/lib/python3.10/site-packages/pkg_resources/__init__.py", line 783, in resolve                                              
    raise DistributionNotFound(req, requirers)                                                                                          
pkg_resources.DistributionNotFound: The 'docutils<0.18,>=0.14' distribution was not found and is required by Sphinx

[3066/7532] Generating html Sphinx documentation for libcxx into "/builddir/llvm-project-13.0.1.src/llvm/build/projects/libcxx/docs/html"                                                                                                                                        
FAILED: projects/libcxx/docs/CMakeFiles/docs-libcxx-html /builddir/llvm-project-13.0.1.src/llvm/build/projects/libcxx/docs/CMakeFiles/docs-libcxx-html                                                                                                                           
cd /builddir/llvm-project-13.0.1.src/llvm/build/projects/libcxx/docs && /usr/bin/cmake -E env /usr/bin/sphinx-build -b html -d /builddir/llvm-project-13.0.1.src/llvm/build/projects/libcxx/docs/_doctrees-libcxx-html -q -t builder-html /builddir/llvm-project-13.0.1.src/libcx
x/docs /builddir/llvm-project-13.0.1.src/llvm/build/projects/libcxx/docs/html                                                                                                                                                                                                    
Traceback (most recent call last):
  File "/usr/lib/python3.10/site-packages/pkg_resources/__init__.py", line 579, in _build_master
    ws.require(__requires__)
  File "/usr/lib/python3.10/site-packages/pkg_resources/__init__.py", line 897, in require
    needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python3.10/site-packages/pkg_resources/__init__.py", line 788, in resolve
    raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.ContextualVersionConflict: (docutils 0.18.1 (/usr/lib/python3.10/site-packages), Requirement.parse('docutils<0.18,>=0.14'), {'Sphinx'})

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/sphinx-build", line 33, in <module>
    sys.exit(load_entry_point('Sphinx==4.2.0', 'console_scripts', 'sphinx-build')())
  File "/usr/bin/sphinx-build", line 25, in importlib_load_entry_point
    return next(matches).load()
  File "/usr/lib/python3.10/importlib/metadata/__init__.py", line 171, in load
    module = import_module(match.group('module'))
  File "/usr/lib/python3.10/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1050, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1027, in _find_and_load 
  File "<frozen importlib._bootstrap>", line 1006, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 688, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 883, in exec_module
  File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
  File "/usr/lib/python3.10/site-packages/sphinx/cmd/build.py", line 25, in <module>
    from sphinx.application import Sphinx
  File "/usr/lib/python3.10/site-packages/sphinx/application.py", line 43, in <module>
    from sphinx.registry import SphinxComponentRegistry
  File "/usr/lib/python3.10/site-packages/sphinx/registry.py", line 24, in <module>
    from pkg_resources import iter_entry_points
  File "/usr/lib/python3.10/site-packages/pkg_resources/__init__.py", line 3247, in <module>
    def _initialize_master_working_set():
  File "/usr/lib/python3.10/site-packages/pkg_resources/__init__.py", line 3221, in _call_aside
    f(*args, **kwargs)
  File "/usr/lib/python3.10/site-packages/pkg_resources/__init__.py", line 3259, in _initialize_master_working_set
    working_set = WorkingSet._build_master()
  File "/usr/lib/python3.10/site-packages/pkg_resources/__init__.py", line 581, in _build_master
    return cls._build_from_requirements(__requires__)
  File "/usr/lib/python3.10/site-packages/pkg_resources/__init__.py", line 594, in _build_from_requirements
    dists = ws.resolve(reqs, Environment())
  File "/usr/lib/python3.10/site-packages/pkg_resources/__init__.py", line 783, in resolve
    raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'docutils<0.18,>=0.14' distribution was not found and is required by Sphinx

@dkwo
Copy link
Contributor

dkwo commented Mar 21, 2022

Does pkg_resources.DistributionNotFound: The 'docutils<0.18,>=0.14' distribution was not found and is required by Sphinx mean that our docutils (0.18.1) is too recent?

@dkwo
Copy link
Contributor

dkwo commented Mar 21, 2022

I'm now trying to build it after downgrading docutils to 0.17

@motorto
Copy link
Contributor Author

motorto commented Mar 21, 2022

That seems to be the issue Sphinx upstream doesn't support docutils-0.18.X

sphinx-doc/sphinx#9777

@dkwo
Copy link
Contributor

dkwo commented Mar 21, 2022

@sgn @ahesford The recent update of docutils breaks sphinx: can we downgrade it?

@dkwo
Copy link
Contributor

dkwo commented Mar 21, 2022 via email

@dkwo
Copy link
Contributor

dkwo commented Mar 21, 2022 via email

@dkwo
Copy link
Contributor

dkwo commented Mar 21, 2022

Forget about river, it also builds after rebuilding mesa.

@sgn
Copy link
Member

sgn commented Mar 21, 2022

@sgn @ahesford The recent update of docutils breaks sphinx: can we downgrade it?

Sphinx has been updated.

@dkwo
Copy link
Contributor

dkwo commented Mar 21, 2022

Thanks. Indeed, after rebasing, llvm13 builds fine here.

@dkwo
Copy link
Contributor

dkwo commented Mar 23, 2022

On the other hand, when building llvm13 for x86-64_musl, it fails at

[3912/7532] Linking CXX shared library lib/clang/13.0.1/lib/linux/libclang_rt.scudo_standalone-x86_64.so                                                                                                                                                                         
FAILED: lib/clang/13.0.1/lib/linux/libclang_rt.scudo_standalone-x86_64.so                                                                                                                                                                                                        
: && /usr/bin/g++ -fPIC -DNDEBUG -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2    -fdebug-prefix-map=/builddir/llvm-project-13.0.1.src=. -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra -Wno-unused-parameter -W
write-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-class-memaccess -Wno-redundant-move -Wno-pessimizing-move -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment -W
misleading-indentation -fdiagnostics-color -ffunction-sections -fdata-sections -Wall -std=c++14 -Wno-unused-parameter -O3 -DNDEBUG  -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -Wl,-z,defs -Wl,-z,nodelete   -m64 -Wl,-z,defs,-z,now,-z,relro -ffunction-sections -fdata-sections -W
l,--gc-sections -pthread -Wl,-rpath-link,/builddir/llvm-project-13.0.1.src/llvm/build/./lib -shared -Wl,-soname,libclang_rt.scudo_standalone-x86_64.so -o lib/clang/13.0.1/lib/linux/libclang_rt.scudo_standalone-x86_64.so projects/compiler-rt/lib/gwp_asan/CMakeFiles/RTGwpAsa
n.x86_64.dir/common.cpp.o projects/compiler-rt/lib/gwp_asan/CMakeFiles/RTGwpAsan.x86_64.dir/crash_handler.cpp.o projects/compiler-rt/lib/gwp_asan/CMakeFiles/RTGwpAsan.x86_64.dir/platform_specific/common_posix.cpp.o projects/compiler-rt/lib/gwp_asan/CMakeFiles/RTGwpAsan.x86
_64.dir/platform_specific/guarded_pool_allocator_posix.cpp.o projects/compiler-rt/lib/gwp_asan/CMakeFiles/RTGwpAsan.x86_64.dir/platform_specific/mutex_posix.cpp.o projects/compiler-rt/lib/gwp_asan/CMakeFiles/RTGwpAsan.x86_64.dir/platform_specific/utilities_posix.cpp.o proj
ects/compiler-rt/lib/gwp_asan/CMakeFiles/RTGwpAsan.x86_64.dir/guarded_pool_allocator.cpp.o projects/compiler-rt/lib/gwp_asan/CMakeFiles/RTGwpAsan.x86_64.dir/stack_trace_compressor.cpp.o projects/compiler-rt/lib/gwp_asan/CMakeFiles/RTGwpAsanBacktraceLibc.x86_64.dir/optional
/backtrace_linux_libc.cpp.o projects/compiler-rt/lib/gwp_asan/CMakeFiles/RTGwpAsanSegvHandler.x86_64.dir/optional/segv_handler_posix.cpp.o projects/compiler-rt/lib/gwp_asan/CMakeFiles/RTGwpAsanOptionsParser.x86_64.dir/optional/options_parser.cpp.o projects/compiler-rt/lib/
scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-x86_64.dir/checksum.cpp.o projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-x86_64.dir/common.cpp.o projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standa
lone-dynamic-x86_64.dir/crc32_hw.cpp.o projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-x86_64.dir/flags_parser.cpp.o projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-x86_64.dir/flags.cpp.o project
s/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-x86_64.dir/fuchsia.cpp.o projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-x86_64.dir/linux.cpp.o projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang
_rt.scudo_standalone-dynamic-x86_64.dir/release.cpp.o projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-x86_64.dir/report.cpp.o projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-x86_64.dir/string_uti
ls.cpp.o projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-x86_64.dir/wrappers_c.cpp.o projects/compiler-rt/lib/scudo/standalone/CMakeFiles/clang_rt.scudo_standalone-dynamic-x86_64.dir/wrappers_cpp.cpp.o  -Wl,-rpath,"\$ORIGIN/../lib" &&
 :                                                                                                                                                                                                                                                                               
/usr/bin/ld: projects/compiler-rt/lib/gwp_asan/CMakeFiles/RTGwpAsanBacktraceLibc.x86_64.dir/optional/backtrace_linux_libc.cpp.o: in function `(anonymous namespace)::SegvBacktrace(unsigned long*, unsigned long, void*)':                                                       
./llvm/build/./compiler-rt/lib/gwp_asan/optional/backtrace_linux_libc.cpp:25: undefined reference to `backtrace'                                                                                                                                                                 
/usr/bin/ld: projects/compiler-rt/lib/gwp_asan/CMakeFiles/RTGwpAsanBacktraceLibc.x86_64.dir/optional/backtrace_linux_libc.cpp.o: in function `(anonymous namespace)::Backtrace(unsigned long*, unsigned long)':
./llvm/build/./compiler-rt/lib/gwp_asan/optional/backtrace_linux_libc.cpp:25: undefined reference to `backtrace'
/usr/bin/ld: projects/compiler-rt/lib/gwp_asan/CMakeFiles/RTGwpAsanBacktraceLibc.x86_64.dir/optional/backtrace_linux_libc.cpp.o: in function `(anonymous namespace)::PrintBacktrace(unsigned long*, unsigned long, void (*)(char const*, ...))':
./llvm/build/./compiler-rt/lib/gwp_asan/optional/backtrace_linux_libc.cpp:44: undefined reference to `backtrace_symbols'
collect2: error: ld returned 1 exit status

@dkwo
Copy link
Contributor

dkwo commented Mar 23, 2022

This pr for llvm13 has one patch less then our llvm12, still at 20 something.
(For comparison Alpine has 3 patches.)
Are all our patches needed for cross? Which are actually necessary?

@motorto
Copy link
Contributor Author

motorto commented Mar 24, 2022 via email

@apprehensions
Copy link
Contributor

apprehensions commented Mar 27, 2022

How come LLVM13 for Void Linux is taking this long to get added? is it not receiving the attention it needs from the primary maintainers?

edit:

-- Configuring done
-- Generating done
-- Build files have been written to: /builddir/llvm-project-13.0.1.src/llvm/build
=> llvm13-13.0.1_1: running pre-build hook: 02-script-wrapper ...
=> llvm13-13.0.1_1: running do_build ...
ninja: error: loading 'build.ninja': No such file or directory
=> ERROR: llvm13-13.0.1_1: do_build: '${make_cmd} ${makejobs} ${make_build_args} ${make_build_target}' exited with 1
=> ERROR:   in do_build() at common/build-style/cmake.sh:85

@Anachron
Copy link
Contributor

@wael444 not sure how your comment is helpful at all.

This community is based purely on volunteers.

If something takes too long for you, feel free to give a helpful hand.

@apprehensions
Copy link
Contributor

apprehensions commented Mar 27, 2022

#35895 (comment)

also: i am merely just someone wanting to use river.

@q66
Copy link
Contributor

q66 commented Mar 27, 2022

llvm14 is out now, so we should probably jump straight to that

@dkwo
Copy link
Contributor

dkwo commented Mar 27, 2022

After adding this patch, I was able to build llvm13 for x86_64-musl.
https://github.com/llvm/llvm-project/commit/d6906be01281e9b39b12ecbbb0f1d755d52e21f7.patch
from llvm/llvm-project#351

@ifreund
Copy link
Contributor

ifreund commented Mar 27, 2022

llvm14 is out now, so we should probably jump straight to that

One downside to jumping straight to 14 is that it will probably be a few months until there is a zig release compatible with llvm 14. Furthermore, I believe patching zig ourselves would very non-trivial this time due to major changes in llvm's API relating to making all pointers in the IR opaque.

@motorto
Copy link
Contributor Author

motorto commented Mar 27, 2022

After adding this patch, I was able to build llvm13 for x86_64-musl.

(Going to do this)

  • Added the patch and rebased, thanks ! I am going to create an musl vm and report back.

@wael444, if you want to help fell free to build all changed packages in this pr and report back please, don't know if you are using any different arch/libc library. I moved way from void because I needed the llvm13, I am still working in this using a vm (I intend to come back once this is merged).

edit:

-- Configuring done
-- Generating done
-- Build files have been written to: /builddir/llvm-project-13.0.1.src/llvm/build
=> llvm13-13.0.1_1: running pre-build hook: 02-script-wrapper ...
=> llvm13-13.0.1_1: running do_build ...
ninja: error: loading 'build.ninja': No such file or directory
=> ERROR: llvm13-13.0.1_1: do_build: '${make_cmd} ${makejobs} ${make_build_args} ${make_build_target}' exited with 1
=> ERROR:   in do_build() at common/build-style/cmake.sh:85

@dkwo and I build it successful on x86_64 glibc, 6 days ago. Are you using any different arch ?

@apprehensions
Copy link
Contributor

@dkwo and I build it successful on x86_64 glibc, 6 days ago. Are you using any different arch ?

No.

-- Build files have been written to: /builddir/llvm-project-13.0.1.src/llvm/build
=> llvm13-13.0.1_1: running pre-build hook: 02-script-wrapper ...
=> llvm13-13.0.1_1: running do_build ...
ninja: error: loading 'build.ninja': No such file or directory
=> ERROR: llvm13-13.0.1_1: do_build: '${make_cmd} ${makejobs} ${make_build_args} ${make_build_target}' exited with 1
=> ERROR:   in do_build() at common/build-style/cmake.sh:85
$ xuname
Void 5.17.0-tkg-pds_22 x86_64 GenuineIntel uptodate rFFFFFFFFFFFFFF

@dkwo
Copy link
Contributor

dkwo commented Mar 27, 2022

@motorto As I said, with that patch it builds fine on x86_64 both glibc and musl. Can you rebase on master, add that patch, and let it run on CI?
@wael444 just zap first.

I also agree we should do llvm13 first, and hofully soon, as it is close to working condition.

@apprehensions
Copy link
Contributor

@wael444 just zap first.

~/.local/src/llvm13 $ ./xbps-src zap 2>&1 >/dev/null
~/.local/src/llvm13 $ ./xbps-src binary-bootstrap 2>&1 >/dev/null
~/.local/src/llvm13 $ ./xbps-src pkg river  
...
=> llvm13-13.0.1_1: running pre-build hook: 02-script-wrapper ...
=> llvm13-13.0.1_1: running do_build ...
ninja: error: loading 'build.ninja': No such file or directory
=> ERROR: llvm13-13.0.1_1: do_build: '${make_cmd} ${makejobs} ${make_build_args} ${make_build_target}' exited with 1
=> ERROR:   in do_build() at common/build-style/cmake.sh:85

@dkwo
Copy link
Contributor

dkwo commented Mar 28, 2022 via email

@motorto
Copy link
Contributor Author

motorto commented Mar 28, 2022

./llvm/build/./compiler-rt/lib/gwp_asan/optional/backtrace_linux_libc.cpp:44: undefined reference to `backtrace_symbols'
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
=> ERROR: llvm13-13.0.1_1: do_build: '${make_cmd} ${makejobs} ${make_build_args} ${make_build_target}' exited with 1
=> ERROR:   in do_build() at common/build-style/cmake.sh:85

didn't push yet because I am having the same issue as @wael444

@motorto
Copy link
Contributor Author

motorto commented May 22, 2022

If you could try rebasing and fixing conflicts as well, that'd be awesome.

Rebased and fixed the conflicts

@q66
Copy link
Contributor

q66 commented May 22, 2022

there is already a PR for llvm 14 open, work on that instead

@motorto
Copy link
Contributor Author

motorto commented May 22, 2022

there is already a PR for llvm 14 open, work on that instead

@motorto motorto closed this May 22, 2022
@Nairou
Copy link
Contributor

Nairou commented May 23, 2022

What about programs (like zig) that still require llvm 13?

It looks like the work has already been done here, no need to throw it away.

@motorto
Copy link
Contributor Author

motorto commented May 23, 2022

What about programs (like zig) that still require llvm 13?

It looks like the work has already been done here, no need to throw it away.

On llvm14 pr he kept the llvm12 just for that purpose ...

Totally forgot about that package, should we keep this open or discard llvm13 in favor of llvm14,@q66

@q66
Copy link
Contributor

q66 commented May 23, 2022

there is no rule saying we can't keep an older llvm runtime library for things that don't support the newer one (i.e. 12 for zig, 14 for most other things)

it's been done before

@motorto
Copy link
Contributor Author

motorto commented May 23, 2022

there is no rule saying we can't keep an older llvm runtime library for things that don't support the newer one (i.e. 12 for zig, 14 for most other things)

it's been done before

I will try to help on the llvm14 package then.

@q66
Copy link
Contributor

q66 commented May 23, 2022

fwiw it's a bit tricky for zig as far as i understand it because it also needs libclang, but we can probably have a versioned libclang package just like we have a versioned libllvm package, and then there will be no problem (the -devel packages can conflict, all that matters is that libclang12 and libllvm12 can be installed in parallel to the main version)

@ifreund
Copy link
Contributor

ifreund commented May 23, 2022

fwiw it's a bit tricky for zig as far as i understand it because it also needs libclang, but we can probably have a versioned libclang package just like we have a versioned libllvm package, and then there will be no problem (the -devel packages can conflict, all that matters is that libclang12 and libllvm12 can be installed in parallel to the main version)

Zig links against all 3 of llvm, clang, and lld. I left a comment on the LLVM 14 PR and I believe the author already split off llvm/clang/lld 12 packages for that purpose.

@q66
Copy link
Contributor

q66 commented May 23, 2022

it's the same story for anything else, runtime libraries need to be split into packages that have version in the name in a way that doesn't conflict with the rest (everything else can conflict)

@dkwo
Copy link
Contributor

dkwo commented Jun 13, 2022

@ifreund Assuming we're going to skip llvm13, is there a way to patch our current river so that xwayland is not broken, without relying on llvm13? i.e. would it work to add the patch riverwm/river@e16eabd ?

@gbrlsnchs
Copy link
Contributor

@ifreund Assuming we're going to skip llvm13, is there a way to patch our current river so that xwayland is not broken, without relying on llvm13? i.e. would it work to add the patch riverwm/river@e16eabd ?

There is, I patched, packaged and published River with that XWayland patch at https://void.gsr.dev.

Here is the source, in case you want to build it yourself.

@dkwo
Copy link
Contributor

dkwo commented Jun 24, 2022 via email

@motorto motorto deleted the llvm13 branch July 17, 2022 15:10
@motorto
Copy link
Contributor Author

motorto commented Oct 11, 2022 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet