ALHP
/
ALHP.GO
6
34
Fork 9
Code Issues 29 Pull Requests Projects Releases Wiki Activity

LLVM, LLVM-Libs, Clang and lld need a rebuild #54

New Issue
Closed
opened 2021-11-13 14:07:20 +01:00 by Gontier-Julien · 30 comments
Gontier-Julien commented 2021-11-13 14:07:20 +01:00
Copy Link

LLVM, LLVM-Libs, Clang and lld pacakge need a rebuild, it cause it to crash and there a serious size difference for LLVM

warning: downgrading package llvm (13.0.0-3.1 => 13.0.0-3)
resolving dependencies...
looking for conflicting packages...

Package (1)  Old Version  New Version  Net Change  Download Size

extra/llvm   13.0.0-3.1   13.0.0-3     242.79 MiB      55.16 MiB

Total Download Size:    55.16 MiB
Total Installed Size:  337.63 MiB
Net Upgrade Size:      242.79 MiB
LLVM, LLVM-Libs, Clang and lld pacakge need a rebuild, it cause it to crash and there a serious size difference for LLVM ``` warning: downgrading package llvm (13.0.0-3.1 => 13.0.0-3) resolving dependencies... looking for conflicting packages... Package (1) Old Version New Version Net Change Download Size extra/llvm 13.0.0-3.1 13.0.0-3 242.79 MiB 55.16 MiB Total Download Size: 55.16 MiB Total Installed Size: 337.63 MiB Net Upgrade Size: 242.79 MiB ```
anonfunc commented 2021-11-13 14:16:56 +01:00
Owner
Copy Link

That could be one of the sideffects mentioned in https://git.harting.dev/anonfunc/ALHP.GO/issues/52#issuecomment-695.

I'll requeue them and monitor if the LTO linking is OOM-killed.

That could be one of the sideffects mentioned in https://git.harting.dev/anonfunc/ALHP.GO/issues/52#issuecomment-695. I'll requeue them and monitor if the LTO linking is OOM-killed.
anonfunc added the
bug
 label 2021-11-13 14:17:10 +01:00
anonfunc commented 2021-11-13 14:27:50 +01:00
Owner
Copy Link

Removed and requeued, lets see how it goes.

Removed and requeued, lets see how it goes.
👍 1
Gontier-Julien commented 2021-11-13 17:26:40 +01:00
Author
Copy Link

Removed and requeued, lets see how it goes.

Okay it seems to have fixed some issue, but i'm in dought concerning llvm, it still have a huge difference in size, when i have some time, i will try to compile it my self and see what going on.

But llvm-libs seem to be causing some issue at compile time, maybe should we try a rebuild with lto, and if the issue seem the same on without lto ?

> Removed and requeued, lets see how it goes. Okay it seems to have fixed some issue, but i'm in dought concerning llvm, it still have a huge difference in size, when i have some time, i will try to compile it my self and see what going on. But llvm-libs seem to be causing some issue at compile time, maybe should we try a rebuild with lto, and if the issue seem the same on without lto ?
anonfunc commented 2021-11-13 18:00:48 +01:00
Owner
Copy Link

But llvm-libs seem to be causing some issue at compile time, maybe should we try a rebuild with lto, and if the issue seem the same on without lto ?

I agree, we need to investigate if its caused by LTO. I would blacklist it for now, until we got that figured out.

Did you try using the 'smaller' ALHP version to see if it works as intended? The size difference must come from somewhere, but it would be interesting to see if it still does its job (I think mesa uses aco for shaders by default now, so that's out).

> But llvm-libs seem to be causing some issue at compile time, maybe should we try a rebuild with lto, and if the issue seem the same on without lto ? I agree, we need to investigate if its caused by LTO. I would blacklist it for now, until we got that figured out. Did you try using the 'smaller' ALHP version to see if it works as intended? The size difference must come from somewhere, but it would be interesting to see if it still does its job (I think mesa uses aco for shaders by default now, so that's out).
Gontier-Julien commented 2021-11-13 18:28:34 +01:00
Author
Copy Link

But llvm-libs seem to be causing some issue at compile time, maybe should we try a rebuild with lto, and if the issue seem the same on without lto ?

I agree, we need to investigate if its caused by LTO. I would blacklist it for now, until we got that figured out.

Did you try using the 'smaller' ALHP version to see if it works as intended? The size difference must come from somewhere, but it would be interesting to see if it still does its job (I think mesa uses aco for sharders by default now, so that's out).

Atm I have a package that compiling with llvm from ALPH but needed to install llvm-libs from the arch repo to make it compile, so will see if there something wrong or not, but llvm seem fine (for now).

> > But llvm-libs seem to be causing some issue at compile time, maybe should we try a rebuild with lto, and if the issue seem the same on without lto ? > > I agree, we need to investigate if its caused by LTO. I would blacklist it for now, until we got that figured out. > > Did you try using the 'smaller' ALHP version to see if it works as intended? The size difference must come from somewhere, but it would be interesting to see if it still does its job (I think mesa uses aco for sharders by default now, so that's out). Atm I have a package that compiling with llvm from ALPH but needed to install llvm-libs from the arch repo to make it compile, so will see if there something wrong or not, but llvm seem fine (for now).
titaniumtown commented 2021-11-13 19:17:48 +01:00
Copy Link

The rust package also needs to be rebuilt I believe.

The rust package also needs to be rebuilt I believe.
anonfunc commented 2021-11-13 19:31:36 +01:00
Owner
Copy Link

@titaniumtown rust seems to fail currently. Not sure if a rebuild yields new result there.

@Gontier-Julien there not currently no way to blacklist a split-package. Since llvm-libs is part of llvm, blacklisting llvm is the only option.

@titaniumtown `rust` seems to [fail currently](https://alhp.harting.dev/logs/rust.log). Not sure if a rebuild yields new result there. @Gontier-Julien there not currently no way to blacklist a split-package. Since `llvm-libs` is part of `llvm`, blacklisting `llvm` is the only option.
titaniumtown commented 2021-11-13 19:34:41 +01:00
Copy Link

@titaniumtown rust seems to fail currently. Not sure if a rebuild yields new result there.

Well I just got errors trying to compile a rust project in relation to the llvm version. idk

> @titaniumtown `rust` seems to [fail currently](https://alhp.harting.dev/logs/rust.log). Not sure if a rebuild yields new result there. Well I just got errors trying to compile a rust project in relation to the llvm version. idk
titaniumtown commented 2021-11-13 19:36:45 +01:00
Copy Link

And also, just noticed that rust shouldn't be built with LTO: dde13f77f3/sys-config/ltoize/files/package.cflags/lto.conf (L32)

Maybe that's the issue?

And also, just noticed that rust shouldn't be built with LTO: https://github.com/InBetweenNames/gentooLTO/blob/dde13f77f390545d64b1a64430f23b4bf10b65eb/sys-config/ltoize/files/package.cflags/lto.conf#L32 Maybe that's the issue?
anonfunc commented 2021-11-13 19:37:31 +01:00
Owner
Copy Link

Could be connected to that weird llvm version that is build currently. I just blacklisted it, can you try again after downgrading llvm (and its split packages) to arch's official version? (pacman -Suuy)

Could be connected to that weird `llvm` version that is build currently. I just blacklisted it, can you try again after downgrading `llvm` (and its split packages) to arch's official version? (`pacman -Suuy`)
anonfunc commented 2021-11-13 19:39:07 +01:00
Owner
Copy Link

And also, just noticed that rust shouldn't be built with LTO: dde13f77f3/sys-config/ltoize/files/package.cflags/lto.conf (L32)

Maybe that's the issue?

That is probably why it has failed to build, but does not explain your build failure related to llvm.

EDIT: Interestingly enough, llvm is also listed there: dde13f77f3/sys-config/ltoize/files/package.cflags/lto.conf (L89)

EDIT2: Probably time to go through that list... Would need to add some code that would make it possible to disable LTO for specific packages.

> And also, just noticed that rust shouldn't be built with LTO: https://github.com/InBetweenNames/gentooLTO/blob/dde13f77f390545d64b1a64430f23b4bf10b65eb/sys-config/ltoize/files/package.cflags/lto.conf#L32 > > Maybe that's the issue? That is probably why it has failed to build, but does not explain your build failure related to `llvm`. *EDIT*: Interestingly enough, `llvm` is also listed there: https://github.com/InBetweenNames/gentooLTO/blob/dde13f77f390545d64b1a64430f23b4bf10b65eb/sys-config/ltoize/files/package.cflags/lto.conf#L89 *EDIT2*: Probably time to go through that list... Would need to add some code that would make it possible to disable LTO for specific packages.
titaniumtown commented 2021-11-13 19:42:53 +01:00
Copy Link

And also, just noticed that rust shouldn't be built with LTO: dde13f77f3/sys-config/ltoize/files/package.cflags/lto.conf (L32)

Maybe that's the issue?

That is probably why it has failed to build, but does not explain your build failure related to llvm.

The exact error I get is:

rustc: error while loading shared libraries: libLLVM-12.so: cannot open shared object file: No such file or directory

> > And also, just noticed that rust shouldn't be built with LTO: https://github.com/InBetweenNames/gentooLTO/blob/dde13f77f390545d64b1a64430f23b4bf10b65eb/sys-config/ltoize/files/package.cflags/lto.conf#L32 > > > > Maybe that's the issue? > > That is probably why it has failed to build, but does not explain your build failure related to llvm. The exact error I get is: > rustc: error while loading shared libraries: libLLVM-12.so: cannot open shared object file: No such file or directory
anonfunc commented 2021-11-13 19:45:14 +01:00
Owner
Copy Link

Well, your rustc is linking to llvm12, so no suprises there. Whats your rust package version? Should be 1:1.56.1-3 from [extra].

Well, your rustc is linking to llvm12, so no suprises there. Whats your rust package version? Should be `1:1.56.1-3` from **[extra]**.
titaniumtown commented 2021-11-13 19:46:18 +01:00
Copy Link

It's using the rust version from this repo (rust-1:1.56.0-1.1) I have my pacman.conf structured like in the README.md https://git.harting.dev/anonfunc/ALHP.GO#example-pacman-conf

It's using the rust version from this repo (`rust-1:1.56.0-1.1`) I have my pacman.conf structured like in the README.md https://git.harting.dev/anonfunc/ALHP.GO#example-pacman-conf
anonfunc commented 2021-11-13 19:51:57 +01:00
Owner
Copy Link

Ah, rust was not removed from ALHP when it failed to build. Weird. Going to remove that shortly, then you should get the newest official version.

Ah, rust was not removed from ALHP when it failed to build. Weird. Going to remove that shortly, then you should get the newest official version.
titaniumtown commented 2021-11-13 19:53:11 +01:00
Copy Link

Got it, thank you so much!

Got it, thank you so much!
anonfunc commented 2021-11-13 20:01:31 +01:00
Owner
Copy Link

rust removed, should be fixed now.

`rust` removed, should be fixed now.
👍 1
Gontier-Julien commented 2021-11-13 20:05:04 +01:00
Author
Copy Link

@titaniumtown rust seems to fail currently. Not sure if a rebuild yields new result there.

@Gontier-Julien there not currently no way to blacklist a split-package. Since llvm-libs is part of llvm, blacklisting llvm is the only option.

Yup just seen it I'm going to do the test and report back to you if it is lto or not, it just take a long time to

> @titaniumtown `rust` seems to [fail currently](https://alhp.harting.dev/logs/rust.log). Not sure if a rebuild yields new result there. > > @Gontier-Julien there not currently no way to blacklist a split-package. Since `llvm-libs` is part of `llvm`, blacklisting `llvm` is the only option. Yup just seen it I'm going to do the test and report back to you if it is lto or not, it just take a long time to
👍 1
anonfunc commented 2021-11-13 20:54:39 +01:00
Owner
Copy Link

@Gontier-Julien I implemented a separate LTO blacklist in de3ca80aab.

Currently on there are rust, llvm and xf86-intel-video.

@Gontier-Julien I implemented a separate LTO blacklist in https://git.harting.dev/anonfunc/ALHP.GO/commit/de3ca80aab8d1d85bbc0644d48cbc2214cb52622. Currently on there are `rust`, `llvm` and `xf86-intel-video`.
Gontier-Julien commented 2021-11-13 21:04:51 +01:00
Author
Copy Link

@Gontier-Julien I implemented a separate LTO blacklist in de3ca80aab.

Currently on there are rust, llvm and xf86-intel-video.

Awesome!
Also I've remarked that gcc is on the blacklist, I think it for stability reason ?

> @Gontier-Julien I implemented a separate LTO blacklist in https://git.harting.dev/anonfunc/ALHP.GO/commit/de3ca80aab8d1d85bbc0644d48cbc2214cb52622. > > Currently on there are `rust`, `llvm` and `xf86-intel-video`. Awesome! Also I've remarked that `gcc` is on the blacklist, I think it for stability reason ?
anonfunc commented 2021-11-13 21:29:42 +01:00
Owner
Copy Link

@Gontier-Julien I implemented a separate LTO blacklist in de3ca80aab.

Currently on there are rust, llvm and xf86-intel-video.

Awesome!
Also I've remarked that gcc is on the blacklist, I think it for stability reason ?

gcc behaves really weird when you try to build local packages with the x86-64-v3 version of it. I don't have the exact errors anymore, since I noticed that really early on while working on the now-deprecated python version of alhp (so over 12 months ago).

Something about local header includes not matching compiled or build-in versions.

> > @Gontier-Julien I implemented a separate LTO blacklist in https://git.harting.dev/anonfunc/ALHP.GO/commit/de3ca80aab8d1d85bbc0644d48cbc2214cb52622. > > > > Currently on there are `rust`, `llvm` and `xf86-intel-video`. > > Awesome! > Also I've remarked that `gcc` is on the blacklist, I think it for stability reason ? `gcc` behaves really weird when you try to build local packages with the x86-64-v3 version of it. I don't have the exact errors anymore, since I noticed that really early on while working on the now-deprecated [python version of alhp](https://git.harting.dev/anonfunc/alhp) (so over 12 months ago). Something about local header includes not matching compiled or build-in versions.
Gontier-Julien commented 2021-11-13 21:38:38 +01:00
Author
Copy Link

@Gontier-Julien I implemented a separate LTO blacklist in de3ca80aab.

Currently on there are rust, llvm and xf86-intel-video.

Awesome!
Also I've remarked that gcc is on the blacklist, I think it for stability reason ?

gcc behaves really weird when you try to build local packages with the x86-64-v3 version of it. I don't have the exact errors anymore, since I noticed that really early on while working on the now-deprecated python version of alhp (so over 12 months ago).

Something about local header includes not matching compiled or build-in versions.

Maybe since there is the new version, a test build couldn't hurt?

What do you think?

> > > @Gontier-Julien I implemented a separate LTO blacklist in https://git.harting.dev/anonfunc/ALHP.GO/commit/de3ca80aab8d1d85bbc0644d48cbc2214cb52622. > > > > > > Currently on there are `rust`, `llvm` and `xf86-intel-video`. > > > > Awesome! > > Also I've remarked that `gcc` is on the blacklist, I think it for stability reason ? > > `gcc` behaves really weird when you try to build local packages with the x86-64-v3 version of it. I don't have the exact errors anymore, since I noticed that really early on while working on the now-deprecated [python version of alhp](https://git.harting.dev/anonfunc/alhp) (so over 12 months ago). > > Something about local header includes not matching compiled or build-in versions. Maybe since there is the new version, a test build couldn't hurt? What do you think?
anonfunc commented 2021-11-13 21:41:21 +01:00
Owner
Copy Link

Maybe since there is the new version, a test build couldn't hurt?

What do you think?

Probably a local build then, but yea why not. Building gcc local + trying to build an AUR package with gcc as compiler should be enough to test that.

> Maybe since there is the new version, a test build couldn't hurt? > > What do you think? Probably a local build then, but yea why not. Building `gcc` local + trying to build an AUR package with `gcc` as compiler should be enough to test that.
👍 1
titaniumtown commented 2021-11-13 21:42:43 +01:00
Copy Link

@anonfunc do you think it would be a good idea to create a Discord server for this project (if there isn't one already)? So things like this could be discussed there, was just an idea.

@anonfunc do you think it would be a good idea to create a Discord server for this project (if there isn't one already)? So things like this could be discussed there, was just an idea.
👍 1
Gontier-Julien commented 2021-11-13 21:51:56 +01:00
Author
Copy Link

@anonfunc do you think it would be a good idea to create a Discord server for this project (if there isn't one already)? So things like this could be discussed there, was just an idea.

Could be a great idea @titaniumtown ^^

> @anonfunc do you think it would be a good idea to create a Discord server for this project (if there isn't one already)? So things like this could be discussed there, was just an idea. Could be a great idea @titaniumtown ^^
Gontier-Julien commented 2021-11-14 02:31:03 +01:00
Author
Copy Link

So a little report on the test with just llvm-libs from arch.

The package with llvm build successfully and work as expected no bug, my test build of llvm never finished/is taking to long

So for me, the size difference didn't cause issues, but llvm-libs did, so could be that the lto does someting that reduce a lot of code and/or doc

llvm take agggeeee to build my gosh

@titaniumtown maybe could you try to build it on your end?

So a little report on the test with just llvm-libs from arch. The package with llvm build successfully and work as expected no bug, my test build of llvm never finished/is taking to long So for me, the size difference didn't cause issues, but llvm-libs did, so could be that the lto does someting that reduce a lot of code and/or doc llvm take agggeeee to build my gosh @titaniumtown maybe could you try to build it on your end?
Gontier-Julien commented 2021-11-14 19:29:34 +01:00
Author
Copy Link

Btw @anonfunc the blacklisted LTO packages is being build without LTO right? Because if that so LLVM wasn't rebuild without LTO

Btw @anonfunc the blacklisted LTO packages is being build without LTO right? Because if that so LLVM wasn't rebuild without LTO
anonfunc commented 2021-11-14 21:28:28 +01:00
Owner
Copy Link

It'll be build if I requeue it or a new version appears. I may requeue it later.

It'll be build if I requeue it or a new version appears. I may requeue it later.
Gontier-Julien commented 2021-11-14 22:03:43 +01:00
Author
Copy Link

It'll be build if I requeue it or a new version appears. I may requeue it later.

Okay no problem ^^

> It'll be build if I requeue it or a new version appears. I may requeue it later. Okay no problem ^^
anonfunc commented 2021-11-17 00:14:58 +01:00
Owner
Copy Link

Closing this on the same basis as #57, please reopen if new package versions still do not work correctly.

Closing this on the same basis as #57, please reopen if new package versions still do not work correctly.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
main
Labels
Clear labels   
blocked upstream

   
bug

Something is not working

  
build-failure

package build fails because of our added buildflags

  
duplicate

This issue or pull request already exists

  
enhancement

New feature

  
help wanted

Need some help

  
informational

Provides information about something

  
invalid

Something is wrong

  
invalid/corrupt package

Package needs to be rebuild

  
packaging issue

   
priority: high

High priority

  
question

More information is needed

  
support

   
wontfix

This won't be fixed

No Label
blocked upstream
bug
build-failure
duplicate
enhancement
help wanted
informational
invalid
invalid/corrupt package
packaging issue
priority: high
question
support
wontfix
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: ALHP/ALHP.GO#54
No description provided.
Delete Branch "%!s(<nil>)"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?