| View previous topic :: View next topic |
| Author |
Message |
CaptainBlood
Advocate
Joined: 24 Jan 2010
Posts: 3848
|
 Posted: Sun Aug 04, 2024 7:43 pm Post subject: dev-lang/nasm: about IUSE=lto removal |
 |
|
Removed as repo/gentoo.git
However, size wise here are the results here:
At make.conf level: | Code: | /usr/bin/nasm lto-no: 1942880 lto: 1959800 diff: -16920 #bigger-bin
/usr/bin/ndisasm lto-no: 1439272 lto: 1437632 diff: 1640 #bin |
At /etc/portage/package.use level; | Code: | -rwxr-xr-x 1 root root 1959864 août 4 21:54 /usr/bin/nasm
-rwxr-xr-x 1 root root 1437632 août 4 21:54 /usr/bin/ndisasm |
Different method, different result...
I generally favor lto when the sum of binary sizes shrinks.
I can not tell about performance though.
Plz note dev-lang/nasm ebuild not yet updated here.
Thks 4 ur attention, interest & support.
_________________
USE="-* ..." in /etc/portage/make.conf here, i.e. a countermeasure to portage implicit braces, belt & diaper paradigm
LT: "I've been doing a passable imitation of the Fontana di Trevi, except my medium is mucus. Sooo much mucus. " |
|
| Back to top |
|
 |
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22619
|
| Posted: Sun Aug 04, 2024 7:59 pm Post subject: |
|
|
| The commit message says users should just add -flto to their flags. Nothing was changed to make LTO more difficult to enable. |
|
| Back to top |
|
|
CaptainBlood
Advocate
Joined: 24 Jan 2010
Posts: 3848
|
| Posted: Sun Aug 04, 2024 8:12 pm Post subject: Re: dev-lang/nasm: about IUSE=lto removal |
|
|
| Hu wrote: | | Nothing was changed to make LTO more difficult to enable. |
Has it been stated otherwise?
To clarify, I'm just showing the numbers for: | CaptainBlood wrote: | | Different method, different result... |
Maybe someone can crank it up showing how wrong that is.
Thks 4 ur attention, interest & support.
_________________
USE="-* ..." in /etc/portage/make.conf here, i.e. a countermeasure to portage implicit braces, belt & diaper paradigm
LT: "I've been doing a passable imitation of the Fontana di Trevi, except my medium is mucus. Sooo much mucus. " |
|
| Back to top |
|
|
stefantalpalaru
n00b
Joined: 11 Jan 2009
Posts: 65
Location: Italy
|
| Posted: Mon Aug 05, 2024 6:09 pm Post subject: |
|
|
| Hu wrote: | | The commit message says users should just add -flto to their flags. |
That's not how we do things in Gentoo. We have USE flags for that.
| Hu wrote: | | Nothing was changed to make LTO more difficult to enable. |
Having per-package USE flags is much easier than having per-package CFLAGS/CXXFLAGS/LDFLAGS.
Also, how many users know that LTO requires passing optimisation flags like "-O3 -march=native" inside LDFLAGS? |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22619
|
| Posted: Mon Aug 05, 2024 7:29 pm Post subject: |
|
|
We have USE flags for things that are complicated to get right. Adding -flto is not complicated, and the Gentoo Wiki for LTO specifically tells users to add -flto to their CFLAGS and CXXFLAGS.
I doubt many users know to pass those flags in LDFLAGS, because in a properly written build system, they don't need to do that. The user's CFLAGS / CXXFLAGS, as appropriate, are repeated to the linker, so there is no need to copy CFLAGS into LDFLAGS. The Gentoo Wiki for LTO does not even mention LDFLAGS. |
|
| Back to top |
|
|
krumpf
Apprentice
Joined: 15 Jul 2018
Posts: 187
|
| Posted: Mon Aug 05, 2024 9:11 pm Post subject: |
|
|
My system currently defaults to gcc + lto + mold as linker, nasm compiles without fault.
| Code: | $ cat /var/db/pkg/dev-lang/nasm-2.16.03/{C,LD}FLAGS
-O2 -pipe -march=native -flto=auto -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing
-fuse-ld=mold -Wl,-O1 -Wl,--as-needed |
Packages depending on nasm are all functional, no issue spotted.
_________________
Dragon Princess Music Games Heroes and villains |
|
| Back to top |
|
|
sam_
Developer
Joined: 14 Aug 2020
Posts: 1949
|
|
| Back to top |
|
|
stefantalpalaru
n00b
Joined: 11 Jan 2009
Posts: 65
Location: Italy
|
| Posted: Tue Aug 06, 2024 9:40 am Post subject: |
|
|
| Hu wrote: | | I doubt many users know to pass those flags in LDFLAGS, because in a properly written build system, they don't need to do that. |
The kind of build system that needs a build-time flag to enable LTO? There is no magical CFLAGS/CXXFLAGS parsing and detection that lets CMake or Autotools know they are doing the - rather complicated - LTO song and dance.
By the way, to enable LTO parallelisation, GCC wants "-flto=auto" while Clang wants "-flto=thin". One more aspect you think users should handle on their own...
| Hu wrote: | | The user's CFLAGS / CXXFLAGS, as appropriate, are repeated to the linker, so there is no need to copy CFLAGS into LDFLAGS. |
Wrong. That's how you get unoptimised builds and then blame LTO for not working.
| Hu wrote: | | The Gentoo Wiki for LTO does not even mention LDFLAGS. |
It is truly the age of the expert beginner.
"To use the link-time optimizer, -flto and optimization options should be specified at compile time and during the final link. It is recommended that you compile all the files participating in the same link with the same options and also specify those options at link time." - https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
The blind leading the blind. |
|
| Back to top |
|
|
sam_
Developer
Joined: 14 Aug 2020
Posts: 1949
|
| Posted: Tue Aug 06, 2024 9:49 am Post subject: |
|
|
Not going to respond to all of that but on the point about repeated options: it's nuanced. That part of the docs is more for people writing software, as they should ensure that options they need are passed consistently, as the LTO option merging has had bugs in the past, but also it's not always clear how to merge two different option values (e.g. if you have -fno-strict-aliasing in one TU and the default -fstrict-aliasing with >= -O2 in another, it's obvious that the conservative & correct way to merge it is -fno-strict-aliasing, but it's not always so easy).
Note that simply omitting -flto from LDFLAGS if you have it in C{,XX}FLAGS won't do harm anyway, nor does it make sense for it to, given that with -flto in there, the compiler isn't omitting objects which the linker can handle without LTO anyway (i.e. LTO must be used and it will be picked up). If it were to somehow not work without LTO, it would either have to error out, or somehow rebuild every object from before without knowing what they were built with (as it's supposedly not aware of LTO at all). With -ffat-lto-objects, it's a different story, of course.
That doesn't mean one shouldn't take care with consistency between *FLAGS but it's not as critical as portrayed above. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22619
|
| Posted: Tue Aug 06, 2024 12:12 pm Post subject: |
|
|
| stefantalpalaru wrote: | | Hu wrote: | | I doubt many users know to pass those flags in LDFLAGS, because in a properly written build system, they don't need to do that. |
The kind of build system that needs a build-time flag to enable LTO? There is no magical CFLAGS/CXXFLAGS parsing and detection that lets CMake or Autotools know they are doing the - rather complicated - LTO song and dance. |
What build systems need that special handling? If the user passes -flto in CFLAGS/CXXFLAGS, and the build system passes CFLAGS/CXXFLAGS to CC/CXX, then the compiler gets what it needs. Why does the build system care? | stefantalpalaru wrote: | | By the way, to enable LTO parallelisation, GCC wants "-flto=auto" while Clang wants "-flto=thin". One more aspect you think users should handle on their own... |
Users are welcome to use that, or not, as they please. Since the build system should not care whether the user uses gcc versus clang, the build system cannot know which of those two special options it needs. The user knows what compiler CC runs, and can set the flags properly. | stefantalpalaru wrote: | | Hu wrote: | | The user's CFLAGS / CXXFLAGS, as appropriate, are repeated to the linker, so there is no need to copy CFLAGS into LDFLAGS. |
Wrong. That's how you get unoptimised builds and then blame LTO for not working. |
I cannot tell if you selectively quoted me to make your point or if you just misunderstood me. To restate my original point: GNU make's default rule automatically passes CFLAGS when linking a C target and CXXFLAGS when linking a CXX target: | Code: | $ touch c.c cxx.cpp
$ CFLAGS=-fc-compiler-only CXXFLAGS=-fcxx-compiler LDFLAGS=-fldflags make -n -f /dev/null c cxx
cc -fc-compiler-only -fldflags c.c -o c
x86_64-pc-linux-gnu-g++ -fcxx-compiler -fldflags cxx.cpp -o cxx |
In my opinion, all good build systems ought to follow this practice. For programs with a more complex pipeline than single source -> output file, the author will need to explicitly use $(LINK.c), $(LINK.cc), or equivalent. However, those will do most of the work: | Code: | $ make -n -f /dev/null -p | grep '^LINK\.c'
LINK.c = $(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH)
LINK.cc = $(CXX) $(CXXFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH) |
| stefantalpalaru wrote: | | Hu wrote: | | The Gentoo Wiki for LTO does not even mention LDFLAGS. |
It is truly the age of the expert beginner.
"To use the link-time optimizer, -flto and optimization options should be specified at compile time and during the final link. It is recommended that you compile all the files participating in the same link with the same options and also specify those options at link time." - https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html |
As above, I am not saying that -flto need not be passed to the linker (though as sam_ notes, there are cases where that is fine) at all. I am saying that the build system ought to be passing CFLAGS / CXXFLAGS to the linker, and that if it does, then the -flto in C*FLAGS will makes repeating -flto in LDFLAGS unnecessary. | stefantalpalaru wrote: | | sam_ wrote: | | https://devmanual.gentoo.org/general-concepts/use-flags/index.html#when-not-to-use-use-flags |
The blind leading the blind. |
You do realize that sam_ is a recognized Gentoo developer, quoting from Gentoo's policy manual on this, right? Who are you calling blind here? |
|
| Back to top |
|
|
stefantalpalaru
n00b
Joined: 11 Jan 2009
Posts: 65
Location: Italy
|
| Posted: Tue Aug 06, 2024 1:55 pm Post subject: |
|
|
| Hu wrote: | | Since the build system should not care whether the user uses gcc versus clang, the build system cannot know which of those two special options it needs. |
It can and it does, obviously: https://gitlab.kitware.com/cmake/cmake/-/blob/f774a5ab5c6c3259724da4edfe3c62631b19ca1c/Modules/Compiler/GNU.cmake#L71
Why are you so confident in these erroneous replies, when you clearly have no idea how software is being built? Is it some sort of humour that escapes me?
| Hu wrote: | | GNU make's default rule automatically passes CFLAGS when linking a C target and CXXFLAGS when linking a CXX target |
Wrong again. You got confused by combining compilation and linking in the same step. The actual GNU Make implicit rule for linking alone is "$(CC) $(LDFLAGS) n.o $(LOADLIBES) $(LDLIBS)", as documented here: https://www.gnu.org/software/make/manual/html_node/Catalogue-of-Rules.html#index-linking_002c-predefined-rule-for
| Hu wrote: | | In my opinion, all good build systems ought to |
Do you even have a personal overlay? You sound like someone who has no idea what's under the hood.
| Hu wrote: | | Who are you calling blind here? |
If you have to ask... |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20484
|
| Posted: Tue Aug 06, 2024 2:31 pm Post subject: |
|
|
@stefantalpalaru,
Although you registered in 2009 and ought to know this, you should read Guidelines (READ BEFORE POSTING). In particular items 1 (netiquette, code of conduct), 8 (no bashing), and 10 (no personal attacks). Thanks in advance for stopping the negative behavior you've exhibited multiple times in this thread.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
eschwartz
Developer
Joined: 29 Oct 2023
Posts: 214
|
| Posted: Tue Aug 06, 2024 10:34 pm Post subject: |
|
|
| stefantalpalaru wrote: | | Hu wrote: | | I doubt many users know to pass those flags in LDFLAGS, because in a properly written build system, they don't need to do that. |
The kind of build system that needs a build-time flag to enable LTO? There is no magical CFLAGS/CXXFLAGS parsing and detection that lets CMake or Autotools know they are doing the - rather complicated - LTO song and dance.
|
This distinction is unnecessary since automake has passed CFLAGS to libtool's link phase for decades, and do so regardless of whether LTO is enabled.
meson does the same.
cmake does the same.
People writing garbage-tier handwritten Makefiles usually don't manage to get anything correct at all -- and this includes passing CFLAGS to the linker, because indeed -- **they do not get that correct**.
Real developers who use real build systems produce real software that doesn't have this issue.
| stefantalpalaru wrote: |
By the way, to enable LTO parallelisation, GCC wants "-flto=auto" while Clang wants "-flto=thin". One more aspect you think users should handle on their own...
|
Why yes, certainly. There are a wealth of CFLAGS and LDFLAGS values that are only supported by one or the other, and you have to get that correct yourself. Unless you propose that Gentoo adds about 500 USE flags to each and every package, one USE flag per potential compiler flag? |
|
| Back to top |
|
|
stefantalpalaru
n00b
Joined: 11 Jan 2009
Posts: 65
Location: Italy
|
| Posted: Wed Aug 07, 2024 11:18 pm Post subject: |
|
|
| eschwartz wrote: | | There are a wealth of CFLAGS and LDFLAGS values that are only supported by one or the other, and you have to get that correct yourself. |
Or you could just enable an "lto" and/or "pgo" USE flag and have it handled properly, like you can with my "svt-av1" package.
I mentioned LTO parallelisation because CMake already handles it properly by default, when setting CMAKE_INTERPROCEDURAL_OPTIMIZATION to ON: https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/911c76502938498c34af50865b2279fa575c7811/CMakeLists.txt#L402-405 |
|
| Back to top |
|
|
eschwartz
Developer
Joined: 29 Oct 2023
Posts: 214
|
| Posted: Thu Aug 08, 2024 3:23 pm Post subject: |
|
|
You keep repeating these so-called "facts" but your logic is completely and utterly broken and nothing you say makes any sense.
It is entirely unnecessary to pass a CMake option telling CMake to add -flto=auto when users can set that themselves. There are no secret mysteries to how CMake sets up LTO, it's all fully reproducible via CFLAGS / CXXFLAGS / LDFLAGS.
Even if it were necessary, you have paid zero attention to Gentoo's eclass policy and don't seem to be aware that Gentoo already passes configure options such as --enable-lto to various packages that need special treatment (which does NOT include cmake), and Gentoo simply does not use a USE flag for this -- Gentoo uses the contents of CFLAGS, via the "tc-is-lto" toolchain function.
If it were desirable to pass CMAKE_INTERPROCEDURAL_OPTIMIZATION=ON, then Gentoo would do this via checking `tc-is-lto` and NOT via a USE flag.
You can argue that Gentoo is blind all you want, but Gentoo is not going to implement USE flags for this and your opinions are not being solicited for input on design so I guess go write a blog about how we suck or something. Dunno, don't care.
...
PGO is indeed something that needs a USE flag, since it adds additional build steps and isn't just a compiler optimization pass similar to -O2. |
|
| Back to top |
|
|
stefantalpalaru
n00b
Joined: 11 Jan 2009
Posts: 65
Location: Italy
|
| Posted: Thu Aug 08, 2024 4:00 pm Post subject: |
|
|
| eschwartz wrote: | | It is entirely unnecessary to pass a CMake option telling CMake to add -flto=auto when users can set that themselves. |
At the core of Gentoo's philosophy is that users set USE flags to control package features.
| eschwartz wrote: | | There are no secret mysteries to how CMake sets up LTO, it's all fully reproducible via CFLAGS / CXXFLAGS / LDFLAGS. |
It's more complicated than you think. Try reading this: https://gitlab.kitware.com/cmake/cmake/-/blob/f774a5ab5c6c3259724da4edfe3c62631b19ca1c/Modules/Compiler/GNU.cmake#L72-127
| eschwartz wrote: | | Even if it were necessary, you have paid zero attention to Gentoo's eclass policy and don't seem to be aware that Gentoo already passes configure options such as --enable-lto to various packages that need special treatment (which does NOT include cmake), and Gentoo simply does not use a USE flag for this -- Gentoo uses the contents of CFLAGS, via the "tc-is-lto" toolchain function. |
You're confused. To quote from "toolchain.eclass":
| Code: |
# This only controls whether the compiler *supports* LTO, not whether
# it's *built using* LTO. Hence we do it without a USE flag.
confgcc+=( --enable-lto )
|
The "gcc" package itself has an "lto" USE flag and it's described like this: "Build using Link Time Optimizations (LTO). Note that GCC is always built with support for building other programs with LTO. This USE flag is for whether GCC itself is built and optimized with LTO."
| eschwartz wrote: | | If it were desirable to pass CMAKE_INTERPROCEDURAL_OPTIMIZATION=ON, then Gentoo would do this via checking `tc-is-lto` and NOT via a USE flag. |
Terrible idea. LTO builds should be per-package opt-in, not a global setting, because these builds take longer and use drastically more RAM. If your solution is per-package CFLAGS instead of per-package USE flags, you failed to make the user's life easier. You failed as a packager and core distro developer.
| eschwartz wrote: | | Gentoo is not going to implement USE flags for this |
It already does. Besides "gcc", all these packages have an "lto" USE flag:
app-containers/lxc
dev-java/openjdk
dev-lang/R
dev-lang/rust
dev-lang/spidermonkey
games-action/prismlauncher
mail-client/thunderbird
media-gfx/darktable
net-dns/nsd
net-libs/nodejs
sys-devel/binutils-apple
www-client/firefox
| eschwartz wrote: | | You keep repeating these so-called "facts" but your logic is completely and utterly broken and nothing you say makes any sense. |
Oh, the irony... |
|
| Back to top |
|
|
eschwartz
Developer
Joined: 29 Oct 2023
Posts: 214
|
| Posted: Thu Aug 08, 2024 4:17 pm Post subject: |
|
|
Yup, and all of that is there to handle different versions of the compiler which is not a problem that make.conf possesses.
| stefantalpalaru wrote: |
| eschwartz wrote: | | Even if it were necessary, you have paid zero attention to Gentoo's eclass policy and don't seem to be aware that Gentoo already passes configure options such as --enable-lto to various packages that need special treatment (which does NOT include cmake), and Gentoo simply does not use a USE flag for this -- Gentoo uses the contents of CFLAGS, via the "tc-is-lto" toolchain function. |
You're confused. To quote from "toolchain.eclass":
|
Nope, I'm referring to toolchain-funcs.eclass
"Return value: Shell true if we are using LTO, shell false otherwise"
| stefantalpalaru wrote: |
Terrible idea. LTO builds should be per-package opt-in, not a global setting, because these builds take longer and use drastically more RAM. If your solution is per-package CFLAGS instead of per-package USE flags, you failed to make the user's life easier. You failed as a packager and core distro developer.
|
You're free to hold that opinion. But as I mentioned already, you have not been consulted for your opinions. And your belief in whether the user's life is easier, is not shared by others.
In exchange I offer you: all packages built by a binhost should use LTO builds, without causing USE flag mismatch.
| stefantalpalaru wrote: |
| eschwartz wrote: | | Gentoo is not going to implement USE flags for this |
It already does. Besides "gcc", all these packages have an "lto" USE flag:
app-containers/lxc
dev-java/openjdk
dev-lang/R
dev-lang/rust
dev-lang/spidermonkey
games-action/prismlauncher
mail-client/thunderbird
media-gfx/darktable
net-dns/nsd
net-libs/nodejs
sys-devel/binutils-apple
www-client/firefox
|
These are legacy USE flags, it is the difference between *implementing* something and *retaining* something -- we are not adding any more and we are working to remove the few that remain. Sorry to disappoint. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22619
|
| Posted: Thu Aug 08, 2024 4:39 pm Post subject: |
|
|
| stefantalpalaru wrote: | | At the core of Gentoo's philosophy is that users set USE flags to control package features. |
How is it a package feature that Portage builds the package with LTO enabled?Sorry, that page has nothing useful to show due to a Javascript error. | stefantalpalaru wrote: | | eschwartz wrote: | | Even if it were necessary, you have paid zero attention to Gentoo's eclass policy and don't seem to be aware that Gentoo already passes configure options such as --enable-lto to various packages that need special treatment (which does NOT include cmake), and Gentoo simply does not use a USE flag for this -- Gentoo uses the contents of CFLAGS, via the "tc-is-lto" toolchain function. |
You're confused. To quote from "toolchain.eclass": | Code: | # This only controls whether the compiler *supports* LTO, not whether
# it's *built using* LTO. Hence we do it without a USE flag.
confgcc+=( --enable-lto ) |
The "gcc" package itself has an "lto" USE flag and it's described like this: "Build using Link Time Optimizations (LTO). Note that GCC is always built with support for building other programs with LTO. This USE flag is for whether GCC itself is built and optimized with LTO." |
Yes, it has that flag because gcc needs more than just adding -flto to build successfully with LTO enabled. If you read elsewhere in that same file, you will even find that the eclass specifically uses filter-lto due to sys-devel/gcc-12.3.0[-lto] fails to build with -flto. Hence, -flto is filtered out, and the user must set USE=lto, which as you can see in the eclass, causes BUILD_CONFIG_TARGETS to gain the element bootstrap-lto. | stefantalpalaru wrote: | | eschwartz wrote: | | If it were desirable to pass CMAKE_INTERPROCEDURAL_OPTIMIZATION=ON, then Gentoo would do this via checking `tc-is-lto` and NOT via a USE flag. |
Terrible idea. LTO builds should be per-package opt-in, not a global setting, because these builds take longer and use drastically more RAM. If your solution is per-package CFLAGS instead of per-package USE flags, you failed to make the user's life easier. You failed as a packager and core distro developer. |
I think you fail to understand the points made here. tc-is-lto is an eclass function that tests whether the active package is being built with -flto according to CFLAGS. (Interestingly, this means that someone who puts -flto in CXXFLAGS and not in CFLAGS will get surprising results. Users should refrain from doing that.)
Users who want global LTO can do so via global CFLAGS. Users who want selective LTO can do so via per-package CFLAGS. Yes, it is slightly more trouble do to per-package CFLAGS than to do per-package USE flags. I am not convinced that this is a failure on the part of the maintainer, and I would even argue that the approach of inspecting the active CFLAGS has the benefit that users can just add -flto to CFLAGS and the ebuild will Do The Right Thing. Users coming from other distributions, or reading distribution-agnostic instructions, will likely reach for the CFLAGS approach first. | stefantalpalaru wrote: | | eschwartz wrote: | | Gentoo is not going to implement USE flags for this |
It already does. Besides "gcc", all these packages have an "lto" USE flag: |
As explained above, which you should have researched before making such strong accusations, gcc needs special handling to make LTO work.
A cursory search of the lxc ebuild shows that USE=lto causes it to pass an extra meson option, so apparently the lxc upstream build system needs to know whether the user is using LTO. Do you consider it a failure of the package developer that the user needs to use a special package-specific option to get LTO, rather than just putting -flto in CFLAGS and having lxc "figure it out"?
Likewise, OpenJDK has USE=lto because it too needs to pass special options to the upstream build system to make LTO work.
I stopped checking here, as you clearly either did not check your own examples, or are judging by criteria that I consider inconsistent with your argument. You insist there should be a consistent way to enable LTO, yet the packages you cite have USE=lto specifically because their upstream build system is not consistent and instead requires the ebuild to pass a special option to get the desired result. To me, consistency would mean that I could learn one way to enable LTO, and every package, regardless of the distribution on which I build it, would do the right thing. |
|
| Back to top |
|
|
Zucca
Moderator
Joined: 14 Jun 2007
Posts: 3687
Location: Rasi, Finland
|
| Posted: Thu Aug 08, 2024 6:40 pm Post subject: |
|
|
| LTO wiki page wrote: | USE Flags
On both GCC and LLVM systems, some packages required special fixes to work with LTO and this is enabled by setting globally the lto USE flag. |
That's very clear to me. I don't see how one can turn that into an opinion and argue about it.
_________________
..: Zucca :..
| My gentoo installs: | init=/sbin/openrc-init
-systemd -logind -elogind seatd |
| Quote: | | I am NaN! I am a man! |
|
|
| Back to top |
|
|
stefantalpalaru
n00b
Joined: 11 Jan 2009
Posts: 65
Location: Italy
|
| Posted: Thu Aug 08, 2024 9:28 pm Post subject: |
|
|
| Hu wrote: | | You insist there should be a consistent way to enable LTO |
I insist that LTO should be controlled by a USE flag, not by CFLAGS.
This trend of removing USE flags and focusing on binary packages is concerning, to say the least.
| eschwartz wrote: | | you have not been consulted for your opinions. And your belief in whether the user's life is easier, is not shared by others. |
And therein lies the problem. You only care about your ingroup, which probably consists of other core devs. You would benefit from hearing out the outgroup - the one where actual Gentoo users are.
| eschwartz wrote: | | These are legacy USE flags, it is the difference between *implementing* something and *retaining* something -- we are not adding any more and we are working to remove the few that remain. Sorry to disappoint. |
I guess my overlay - with 919 packages in it, already - will grow even bigger. Such is the life of an actual Gentoo user... |
|
| Back to top |
|
|
Zucca
Moderator
Joined: 14 Jun 2007
Posts: 3687
Location: Rasi, Finland
|
| Posted: Fri Aug 09, 2024 6:08 am Post subject: |
|
|
| stefantalpalaru wrote: | | I insist that LTO should be controlled by a USE flag, not by CFLAGS. |
I'm partly on the same line as you. From end-users perspective it would be somewhat easier to have lto USE flag for almost every package. But on the other hand tt's really not too complicated to control this via package.env.
_________________
..: Zucca :..
| My gentoo installs: | init=/sbin/openrc-init
-systemd -logind -elogind seatd |
| Quote: | | I am NaN! I am a man! |
|
|
| Back to top |
|
|
eschwartz
Developer
Joined: 29 Oct 2023
Posts: 214
|
| Posted: Fri Aug 09, 2024 4:37 pm Post subject: |
|
|
| Zucca wrote: | | stefantalpalaru wrote: | | I insist that LTO should be controlled by a USE flag, not by CFLAGS. |
I'm partly on the same line as you. From end-users perspective it would be somewhat easier to have lto USE flag for almost every package. But on the other hand tt's really not too complicated to control this via package.env. |
BTW the same argument could be made about -g or -ggdb, and about FEATURES=installsources. They can even result in packages taking a really large amount of time and drastically more RAM.  |
|
| Back to top |
|
|
kimchi_sg
Advocate
Joined: 26 Nov 2004
Posts: 3038
|
| Posted: Sat Aug 10, 2024 1:57 am Post subject: |
|
|
| stefantalpalaru wrote: | | Hu wrote: | | You insist there should be a consistent way to enable LTO |
I insist that LTO should be controlled by a USE flag, not by CFLAGS.
|
Why not let -march and -O be controlled by USE too?
Your argument makes no sense.
Golly, -O controlled by USE flag will add at least 3 flags to every package, more if you want to control for -Os -Ofast etc. |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 9261
|
| Posted: Sat Aug 10, 2024 8:30 am Post subject: |
|
|
| stefantalpalaru wrote: | | I guess my overlay - with 919 packages in it, already - will grow even bigger. Such is the life of an actual Gentoo user... |
You've certainly shown how to unsuccessfully argue for your changes. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Other Things Gentoo
