Skip to content

WIP: LLVM 14.0.6 #1

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

Closed
wants to merge 4 commits into from
Closed

WIP: LLVM 14.0.6 #1

wants to merge 4 commits into from

Conversation

rubdos
Copy link
Contributor

@rubdos rubdos commented Jun 24, 2022

LLVM 12+ is necessary for Rust 1.55+ sailfishos/rust#15

Nothing has been tested yet here. Just putting out the code. This one was easy to get to compile.

TODO:

  • Compile Rust with it (trying this out as we speak)
  • Fix aarch64 build (libz.so is getting searched for in /usr/lib instead of /usr/lib64).
  • Check whether Clang should also get bumped

@rubdos rubdos changed the title WIP: LLVM 15 WIP: LLVM 14.0.5 Jun 24, 2022
@rubdos
Copy link
Contributor Author

rubdos commented Jun 24, 2022

So, this compiles under armv7hl and i486, but fails under aarch64 with a reference to libz.so

CMake Warning:
  Manually-specified variables were not used by the project:

    LIB_INSTALL_DIR


-- Build files have been written to: /home/rsmet/src/sailfishos-rust/llvm/llvm/llvm/build
+ /usr/bin/ninja -v -j24
ninja: error: '/usr/lib/libz.so', needed by 'bin/llvm-tblgen', missing and no known rule to make it
error: Bad exit status from /var/tmp/rpm-tmp.kncB55 (%build)

I suppose I'll need to teach llvm to find this under /usr/lib64/libz.so, somehow.

@Thaodan
Copy link

Thaodan commented Jun 24, 2022

CMake Warning:
Manually-specified variables were not used by the project:

LIB_INSTALL_DIR

You can ignore that, it comes from the %cmake macro.

@Thaodan
Copy link

Thaodan commented Jun 24, 2022

CMake Warning:
Manually-specified variables were not used by the project:

LIB_INSTALL_DIR

You can ignore that, it comes from the %cmake macro.

So, this compiles under armv7hl and i486, but fails under aarch64 with a reference to libz.so

CMake Warning:
  Manually-specified variables were not used by the project:

    LIB_INSTALL_DIR


-- Build files have been written to: /home/rsmet/src/sailfishos-rust/llvm/llvm/llvm/build
+ /usr/bin/ninja -v -j24
ninja: error: '/usr/lib/libz.so', needed by 'bin/llvm-tblgen', missing and no known rule to make it
error: Bad exit status from /var/tmp/rpm-tmp.kncB55 (%build)

I suppose I'll need to teach llvm to find this under /usr/lib64/libz.so, somehow.

Can you check the ninja file, is libdir set correctly?

@rubdos
Copy link
Contributor Author

rubdos commented Jun 25, 2022

Can you check the ninja file, is libdir set correctly?

It was indeed badly generated.

Starting from a clean build directory, aarch64 just compiles fine. Reason was a dirty build directory from the i486/armv7hl compilation.

What's my best next step here; submit the packages to OBS and those as a repo to do my testing against? Manually installing all these RPMs in my targets is quite exhausting. I don't think I currently have an OBS account.

@rubdos rubdos mentioned this pull request Jun 25, 2022
2 tasks
@Thaodan
Copy link

Thaodan commented Jun 25, 2022 via email

@rubdos
Copy link
Contributor Author

rubdos commented Jun 26, 2022

I'm still trying to tackle an issue with Aarch64. By default, LLVM now emits LSE/out-of-line atomic calls, but these are not supported in GCC < 9.3.1.

I'm testing a patch that disables out-of-line atomics on MeeGo vendors now.

FWIW, I'm adding LLVM 14 and Rust 1.61 on my personal home-hosted repo for tests; I've scripted a bit around it.

I hope you don't mind me re-organising the patch files a bit for easier rebases in the future.

Comment on lines -32 to +37
- return getArch() == llvm::Triple::x86_64;
+ return true;
}

bool Generic_GCC::isPICDefault() const {
--
2.20.1

+ if (getTriple().isMeeGo()) {
+ return true;
+ }
switch (getArch()) {
case llvm::Triple::aarch64:
case llvm::Triple::ppc:
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was the most interesting conflict of the rebase. I'm not sure whether this still takes the commit message to heart .This might need some change in either the commit message or in the code (to replace it again with return true;)

@rubdos rubdos changed the title WIP: LLVM 14.0.5 WIP: LLVM 14.0.6 Jun 27, 2022
@rubdos
Copy link
Contributor Author

rubdos commented Jun 27, 2022

I'm testing a patch that disables out-of-line atomics on MeeGo vendors now.

I just tested the 0006 patch, and it doesn't help. The resulting log of installing this version and trying to compile sccache can be found here: https://gitlab.com/whisperfish/sailo-rs/-/jobs/2642920507/raw

Could it be that Rust calls LLVM with just aarch64-linux-gnu instead of aarch64-linux-meego? Would make sense if it does, but that also means I cannot really disable it only for MeeGo targets. I'll try disabling out-of-line altogether next.

@thigg
Copy link

thigg commented Jun 27, 2022

I have no idea what I am doing, but just wanted to leave this here, in case you were searching for it:

Options -moutline-atomics and -mno-outline-atomics to enable and disable it
were added to clang driver.

source

@rubdos
Copy link
Contributor Author

rubdos commented Jun 28, 2022

I have no idea what I am doing, but just wanted to leave this here, in case you were searching for it:

Options -moutline-atomics and -mno-outline-atomics to enable and disable it
were added to clang driver.

source

Found these indeed, but at no point are we using clang. The equivalent would be -C target-feature=-outline-atomics, but that doesn't pass through for some reason. Worst case, I'll have to summon a real Rustacean to the discussion.

@Thaodan
Copy link

Thaodan commented Oct 11, 2022 via email

@rubdos
Copy link
Contributor Author

rubdos commented Oct 12, 2022

Is there any chance someone at Jolla can continue this work? I cannot seem to find a sizable slot in my schedule any time soon to fit the mental power to finish this up. Since it's apparently also needed for sailfishos/mesa#2, I suppose there's an incentive for Jolla to continue this work.

@mlehtima
Copy link
Contributor

mlehtima commented Oct 12, 2022

Is there any chance someone at Jolla can continue this work? I cannot seem to find a sizable slot in my schedule any time soon to fit the mental power to finish this up. Since it's apparently also needed for sailfishos/mesa#2, I suppose there's an incentive for Jolla to continue this work.

Hi, I already did a test build of these and had to fix clang spec to make it build so maybe I can make a new PR or push to your branch.

@rubdos
Copy link
Contributor Author

rubdos commented Oct 13, 2022

Hi, I already did a test build of these and had to fix clang spec to make it build so maybe I can make a new PR or push to your branch.

Glad you found a fix for the clang build. I've added you to my fork as collaborator, feel free to push to this branch if that's easy for you! It's very inaptly named llvm-15 :-)

@simonschmeisser
Copy link

Would it help to package gcc 12 or similar in parallel to the current gcc8? Has anyone started working on it or would I need to start from scratch? If so would you recommend starting from the current huge gcc8 rpm spec or from fedora or similar?

@mlehtima
Copy link
Contributor

mlehtima commented Feb 6, 2023

Closing this as update was done in #2

@mlehtima mlehtima closed this Feb 6, 2023
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.

5 participants