| View previous topic :: View next topic |
| Author |
Message |
eschwartz
Developer
Joined: 29 Oct 2023
Posts: 214
|
 Posted: Wed Aug 21, 2024 6:18 pm Post subject: |
 |
|
| lars_the_bear wrote: | | John R. Graham wrote: | In the meantime, to interpret what sam_ said above a little bit, that makes the requirement absolutely simple: don't set any USE flags in /etc/portage/*.
|
As I recall, all I have is | Code: | | +alsa -pulseaudio -gnome -kde -systemd -wayland |
.
These don't seem extraordinary settings to me, and I would have thought they were essential on a system where I never intend to run a full-scale integrated desktop.
But it's been suggested that Gentoo shouldn't break if I allow applications to have Wayland and Pulse support to be built, even if I don't (can't) use either of these. I can certainly try this, whilst I still have big machines to try it on in a reasonable time. But my gut feeling is that it will be problematic.
Or am I just being pessimistic?
BR, Lars. |
If you leave in wayland and pulseaudio support, then applications may build so that they load the wayland and libpulse shared libraries. They will also contain runtime-switchable code to detect if you have a sound server or active wayland session. If you don't actually use pulseaudio or wayland, then the only downside of including support is that you are unable to depclean dev-libs/wayland and media-libs/libpulse.
For smaller packages that you are going to be building locally anyway, you might as well disable the features you don't need. For binhost packages you really don't want to compile yourself, it's probably a better idea to just accept the media-libs/libpulse dependency for qtwebengine.
This may involve juggling your USE flags a bit, or it may involve deciding it's not worth the bother of disabling pulseaudio support in general. Personally I'm happy to maintain /etc/portage/package.use/binhost containing the flags I need to ensure I get binhost packages. |
|
| Back to top |
|
 |
logrusx
Advocate
Joined: 22 Feb 2018
Posts: 2390
|
| Posted: Thu Aug 22, 2024 4:45 am Post subject: |
|
|
| lars_the_bear wrote: | | I can certainly try this, whilst I still have big machines to try it on in a reasonable time. |
You can try it right now on any machine. Portage will spit a list of possible use changes for packages with incompatible use flags. Better yet, post it here so you can take advantage of the collective knowledge:
| Code: | | wgetpaste -c 'emerge -DuUgpv @world' |
Best Regards,
Georgi |
|
| Back to top |
|
|
lars_the_bear
Guru
Joined: 05 Jun 2024
Posts: 512
|
| Posted: Thu Aug 22, 2024 7:46 am Post subject: |
|
|
| logrusx wrote: | Portage will spit a list of possible use changes for packages with incompatible use flags. Better yet, post it here so you can take advantage of the collective knowledge:
| Code: | | wgetpaste -c 'emerge -DuUgpv @world' |
|
Thanks. On the old laptop I'm struggling with, this `emerge` command produces no output at all.
On the machine I just set up to experiment with USE flags, it shows that a lot of things aren't supplied as binaries because of mismatched CPU flags.
For example, it seems that the binary libsodium has -cpu_flags_x86_sse4_1, but I have this flag set, because `cpuid2cpuflags` sets it.
I'm not entirely sure what I can do about that, since I can't easily change the CPU. I don't know what the implications would be, for ignoring `cpuid2cpuflags` and not having any CPU flags set at all.
I've started another thread for this general issue of binary compatibility, since it's broader than just the 'inspector' issue.
BR, Lars. |
|
| Back to top |
|
|
logrusx
Advocate
Joined: 22 Feb 2018
Posts: 2390
|
| Posted: Thu Aug 22, 2024 8:08 am Post subject: |
|
|
| lars_the_bear wrote: | | logrusx wrote: | Portage will spit a list of possible use changes for packages with incompatible use flags. Better yet, post it here so you can take advantage of the collective knowledge:
| Code: | | wgetpaste -c 'emerge -DuUgpv @world' |
|
Thanks. On the old laptop I'm struggling with, this `emerge` command produces no output at all. |
If you're saying you run only the emerge command, that means nothing is due to be updated. You can try with capital G which may produce not exactly what you want but at least will give us something to work on.
If you mean wgetpaste didn't finish, then try this:
| Code: | | wgetpaste -s 0x0 -c 'emerge -DuUgpv @world' |
or list the available services with wgetpaste -S and select another service.
| lars_the_bear wrote: | | On the machine I just set up to experiment with USE flags, it shows that a lot of things aren't supplied as binaries because of mismatched CPU flags. |
Share the output.
| lars_the_bear wrote: | | For example, it seems that the binary libsodium has -cpu_flags_x86_sse4_1, but I have this flag set, because `cpuid2cpuflags` sets it. |
Just remove it. No big deal.
Best Regards,
Georgi |
|
| Back to top |
|
|
lars_the_bear
Guru
Joined: 05 Jun 2024
Posts: 512
|
| Posted: Thu Aug 22, 2024 9:02 am Post subject: |
|
|
| logrusx wrote: | [
Just remove it. No big deal.
|
Well, this is the problem with reading the manual  The installation instructions are pretty clear that these CPU flags need to be set, but they don't really say why, or what the implications are of fiddling with them. So I just followed orders.
I've had instances in the past where packages had to be compiled because specific flags weren't set. I recally that AVX2 is the usual culprit. The binaries for a lot of media stuff seem to be built on the assumption that this flag is set. If it isn't, I guess there's another long compilation to look forward to.
I suppose it's probably safer to say that my CPU does not support some particular feature, when it does, than to say it supports it, when it doesn't. Either way, it seems that CPU flags affect whether binaries are used, as well as USE flags.
I don't care that libsodium has to be built from source, because it only takes a few minutes. But this whole situation is pretty confusing to me, to be honest.
BR, Lars. |
|
| Back to top |
|
|
logrusx
Advocate
Joined: 22 Feb 2018
Posts: 2390
|
| Posted: Thu Aug 22, 2024 9:13 am Post subject: |
|
|
It would be a lot easier if you shared output rather than your thoughts. If your thoughts were accurate you wouldn't be asking those questions, so please provide output. If you don't, count only on general advice which may lead you in a wrong direction and will cost you a lot more experimentation. And perhaps unnecessary compilation time.
Also it's quite annoying you always dodge the question when asked for output. Why do you do that?
Best Regards,
Georgi |
|
| Back to top |
|
|
lars_the_bear
Guru
Joined: 05 Jun 2024
Posts: 512
|
| Posted: Thu Aug 22, 2024 9:19 am Post subject: |
|
|
| logrusx wrote: |
Also it's quite annoying you always dodge the question when asked for output. Why do you do that?
|
I do it just to piss you off, or hadn't you guessed? 
Also, in some cases I'm referring to situations that arose over a month ago. I don't have any output. And also: my problem is a general one, it's not specific. What happens with some package or other isn't really the issue; my problem is getting the whole system to work acceptably.
BR, Lars. |
|
| Back to top |
|
|
logrusx
Advocate
Joined: 22 Feb 2018
Posts: 2390
|
| Posted: Thu Aug 22, 2024 11:38 am Post subject: |
|
|
| lars_the_bear wrote: |
Also, in some cases I'm referring to situations that arose over a month ago. I don't have any output. |
Actually you posted another thread where you said you created a new installation just today. It's very clever of you trying to avoid getting helped.
Good luck. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22602
|
| Posted: Thu Aug 22, 2024 12:04 pm Post subject: |
|
|
| CPU_FLAGS_X86, VIDEO_CARDS, and a few other special variables are USE_EXPAND shortcuts, so advice regarding USE flags tends to apply to them as well. |
|
| Back to top |
|
|
lars_the_bear
Guru
Joined: 05 Jun 2024
Posts: 512
|
| Posted: Thu Aug 22, 2024 12:12 pm Post subject: |
|
|
| logrusx wrote: | | lars_the_bear wrote: |
Also, in some cases I'm referring to situations that arose over a month ago. I don't have any output. |
Actually you posted another thread where you said you created a new installation just today. It's very clever of you trying to avoid getting helped.
|
Actually, I've created three installations today, and at least fifty since I started using Gentoo a few months ago. Fortunately, I have unlimited capacity for VMs.
It doesn't help me all that much to interpret my error messages and whatnot. What will help me, I think, is to understand the general principles that Gentoo uses. It's hard to get any kind of handle on that.
BR, Lars. |
|
| Back to top |
|
|
eschwartz
Developer
Joined: 29 Oct 2023
Posts: 214
|
| Posted: Thu Aug 22, 2024 6:22 pm Post subject: |
|
|
| lars_the_bear wrote: |
For example, it seems that the binary libsodium has -cpu_flags_x86_sse4_1, but I have this flag set, because `cpuid2cpuflags` sets it.
I'm not entirely sure what I can do about that, since I can't easily change the CPU. I don't know what the implications would be, for ignoring `cpuid2cpuflags` and not having any CPU flags set at all.
|
Ignoring cpuid2cpuflags and not having any CPU_FLAGS_X86 set at all, will mean that some packages which contain optional asm support for accelerated operation on specific CPUs, will simply build the generic version.
That is why the binhost doesn't set those flags. It also builds with -march=x86-64, in order to be broadly available for many systems. But unlike simply building with a different -march, the optimized asm requires passing different options to the configure command, so doing that without a USE flag but by simply guessing from CFLAGS is impractical.
Note: there is a variant binhost as well:
https://wiki.gentoo.org/wiki/Gentoo_Binary_Host_Quickstart#x86-64-v3_variant
| Quote: |
Most configuration is identical between x86-64 and x86-64-v3, but there are two tweaks:
- The packages are built with CFLAGS="-O2 -pipe -march=x86-64-v3" instead.
- Additionally, package.use contains */* CPU_FLAGS_X86: avx avx2 f16c fma3 mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3.
|
You can tell if your CPU supports the x86-64-v3 variant by running:
| Code: |
$ ld.so --help
[...]
Subdirectories of glibc-hwcaps directories, in priority order:
x86-64-v4
x86-64-v3 (supported, searched)
x86-64-v2 (supported, searched)
|
If x86-64-v3 is one of the ones marked as "supported, searched" then it is safe to use that binhost variant. To use it, tweak the sync-uri in /etc/portage/binrepos.conf/gentoobinhost.conf (where it says "x86-64", switch it to "x86-64-v3").
Last edited by eschwartz on Thu Aug 22, 2024 6:25 pm; edited 1 time in total |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20476
|
| Posted: Thu Aug 22, 2024 6:25 pm Post subject: |
|
|
| lars_the_bear wrote: | | It doesn't help me all that much to interpret my error messages and whatnot. What will help me, I think, is to understand the general principles that Gentoo uses. It's hard to get any kind of handle on that. |
Understanding the general principles is fairly simple. What helps to truly understand them is applying them to specific scenarios.
Hardware USE flags add support for that feature, but are often optional. It may make a program faster, but it might not make that much difference, depending on the usage. AVX2 supported in hardware can optionally be used by software. Without the hardware, it may run on the CPU without that hardware optimization.
| lars_the_bear wrote: | | For example, it seems that the binary libsodium has -cpu_flags_x86_sse4_1, but I have this flag set, because `cpuid2cpuflags` sets it. |
Clarification... you chose to use cpuid2cpuflags to set it.
As far as I know, both avx and sse are optional. In your case, maybe FreeCAD would benefit appreciably from them? That would require testing.
In my experience, the Gentoo installation Handbook is often vague and rarely says "you must do this" if it is at all optional. Sometimes I find the lack of default recommendation with reasoning to be annoying because it means I have a lot of work to do. ;)
I don't recall the handbook saying that you must set hardware optimization, but perhaps that changed or is vague on whether or not it is optional.
General principle: the settings provided in a given profile are probably suitable for most users of that profile. Only deviate from the default when you understand why you should deviate, or you are prepared to accept the outcome.
As an example, if you choose a desktop profile and find that you are inclined ti disable a lot of USE flags, maybe the desktop profile isn't the best choice. Or the inverse if you chose a "leander" profile and have to add a lot of USE flags, maybe a desktop profile would be better.
General principle: with increased deviation from defaults, chances increase that you'll encounter a problem. Minor deviations will likely be easier to resolve than extreme deviations. In the most extreme, a deviation may be considered "unsupported." Although unsupported, you may still receive offers of assistance.
Changing a USE flag is often "Mostly Harmless." If I notice new packages being installed, I immediately look to see if a USE flag is the culprit. Can I disable it to prevent packages I obviously wasn't using from being installed? If yes, the I disable it. Sometimes it is forced by the profile.
General principle: avoid experimenting with the active toolchain as well as python and portage. At a minimum, have a recovery plan.
_________________
Quis separabit? Quo animo? |
|
| 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
|
|
Portage & Programming
