Sys-config/ltoize-0.9.11 doesn't recognize clang (fails to install)

[Phoenix591]

>>> Emerging (1 of 1) sys-config/ltoize-0.9.11::lto-overlay
 * FEATURES='assume-digests binpkg-docompress binpkg-dostrip binpkg-logs buildpkg-live config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch pid-sandbox preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms strict strict-keepdir unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr'
 * CFLAGS='-march=native -O3 -pipe -flto=thin -fstack-protector-strong'
 * CXXFLAGS='-march=native -O3 -pipe -flto=thin -fstack-protector-strong'
 * FFLAGS='-march=native -O3 -pipe -flto=thin -fstack-protector-strong'
 * FCFLAGS='-march=native -O3 -pipe -flto=thin -fstack-protector-strong'
 * F77FLAGS='-march=native -O3 -pipe -flto=thin -fstack-protector-strong'
 * LDFLAGS='-Wl,-O1 -Wl,--as-needed -march=native -O3 -pipe -flto=thin -fstack-protector-strong'
 * MAKEOPTS='-j6 -l5'
 * USE_NONGNU='1'
 * clang version 15.0.6
 * clang version 15.0.6
 * LLD 15.0.6 (compatible with GNU linkers)
 * Linux Phoenix591 6.0.13 #1 SMP PREEMPT_DYNAMIC Thu Dec 15 06:25:33 CST 2022 x86_64 Intel(R) Core(TM) i5-8400 CPU @ 2.80GHz GenuineIntel GNU/Linux
sys-config/ltoize: 13 seconds average for 4 merges
2021-03-02T02:28:11 >>> sys-config/ltoize: 19 seconds
2021-03-02T02:36:27 >>> sys-config/ltoize: 19 seconds
2021-09-27T23:42:46 >>> sys-config/ltoize: 8 seconds
2021-09-30T19:20:34 >>> sys-config/ltoize: 8 seconds
 * Warning: Active GCC version '4.2.1' is lower then the expected version '10.2.0', it is recommended that you use the newest GCC if you want LTO.
 * I_KNOW_WHAT_I_AM_DOING=y -- continuing anyway

[emrakyz]

I can reproduce this with the default recent stage-3 tarball. I guess Clang is seen as GCC 4.1.2

[kir68k]

The issue still persists, I'm using the clang profile with version 16.0.6 and get this bug.
Seems to be caused by gcc-fullversion inside of pkg_setup(), at least I presume.

Looking around, that function seems to reside here, but I don't understand why it's activated if I don't use GCC.

When I want to merge ltoize, above the warning message I get

clang-16: warning: argument unused during compilation: '-E' [-Wunused-command-line-argument]'

So it is trying to use clang, but also tries to use a GCC version that doesn't exist on the system? As for the record, eselect gcc list has GCC 13 selected, and "4.2.1" is nowhere.

[emrakyz]

This repo is outdated in my opinion as of now.

Not for just Clang. Lots of packages has changed. and the latest update on this repo was on december 2022.

[sm-moshi]

@emrakyz Do you know any alternative until this point?

[kir68k]

@emrakyz Do you know any alternative until this point?

I have a plan to incorporate some ideas (like ltoize's make.conf.lto) and maybe packages from this overlay into mine, with updates, but it's a relatively new one and I wouldn't want someone's machine breaking from a mistake I'd make.

I think for now you could try to have ltoize in your overlay, and update the ebuild to have an if then else part for both gcc and clang/llvm.
I had to do that for another package recently which called die if tc-is-gcc failed (as it does if you just don't use gcc, normally).
Haven't seen the ltoize ebuild as of writing but I could later.

[kir68k]

I think for now you could try to have ltoize in your overlay, and update the ebuild to have an if then else part for both gcc and clang/llvm. I had to do that for another package recently which called die if tc-is-gcc failed (as it does if you just don't use gcc, normally). Haven't seen the ltoize ebuild as of writing but I could later.

Looking at it, this line seems to be the issue.
As I understand it, ver_test would return nothing since gcc is not used at all, unless gcc_fullversion returns the active gcc version even in an LLVM environment?
Anyway, if that function returns false, it checks if the I_KNOW_WHAT_I_AM_DOING flag is set, and since it's not it calls die...

I think copying the ebuild to somewhere else, and entirely refactoring that section to respect other compilers, until the owner here comes back is the best option.
Is gcc 10.2.0 even available for downloading anywhere? The main repository only lists 10.4.1 & 10.5.1, with everything below explicitly masked, so I think this whole section can be refactored.