On 11/15/24 7:42 AM, byte.size...@simplelogin.com wrote: > My only question that remains is whether I should change the existing > value for CFLAGS (I presume so). Currently, I have: > > COMMON_FLAGS="-march=znver4 -O2 -pipe" > > (yes CFLAGS etc are set to use $COMMON_FLAGS). > > Since I'm planning to use binary packages from x86-64-v3, I presume this > should be changed to: > > COMMON_FLAGS="-march=x86-64-v3 -O2 -pipe" > > or, perhaps: > > COMMON_FLAGS="-march=x86-64-v3 -mtune=znver4 -O2 -pipe" ?
Your CFLAGS are irrelevant here. CFLAGS on the binhost server must be compatible with your local machine, or you will successfully install packages that then abort with SIGILL when you try to run the programs. The reverse is not true -- CFLAGS on your local machine just need to be compatible with, well, your local machine (where they get installed), not the binhost, where they don't get installed. :) It's fully possible to change your CFLAGS in make.conf whenever you want, run emerge to do world updates etc, and portage doesn't care and effectively doesn't know you changed it since all installed packages are "compatible" with that make.conf -- this is extremely unlike USE flags, which are actually treated as match specifiers and if you change USE, then emerge insists on rebuilding / reinstalling. Which brings us to... > I also have a hefty $CPU_FLA > GS_X86 (also added to $USE) from "cpuid2cpuflags" but am not worried > about this as packages that don't fit will simply be built from source > as usual. Yup. CPU_FLAGS_X86 don't need to be added to $USE because they already *are* USE. And USE flags will force rebuilds where necessary, or prevent seeing binary packages as compatible. The binhost already builds with those USE flags as appropriate for v3 systems, but you may have a couple more enabled so packages which specifically can take advantage of that, will be built locally. > Anyway, in both cases running my usual: > > emerge -aqvND --update --keep-going --with-bdeps=y @world > > doesn't yield any changes to the system. I presume because, as of now, > everything is up to date. > > In contrast, adding "--rebuilt-binaries" shows a lot of binary packages > being pulled in and "--emptytree", as expected, shows a full rebuild > with a lot of binary packages being pulled in. > > So, to the actual questions: > > 1) What would be the preferred CFLAGS configuration or, since "- > march=znver4" is a newer subset of x86-64-v3, can I simply keep the > existing one? Keep your existing CFLAGS that you were using before enabling the binhost. It's a free optimization for any packages that you ended up building from source anyway. > 2) To reinstall the current source based packages with their binary > equivalent, "--rebuilt-binaries" sufficient or should I just go for "-- > emptytree @world"? --rebuilt-binaries will update all packages with their binary equivalents, if the binary on the server has a BUILD_TIME newer than the time you rebuilt it locally. This isn't really the same as reinstalling all source based packages with their binary equivalent. --emptytree will update all packages with their binary equivalents, and also update all other packages by building them from source, which isn't actually what you asked for, though it does what you asked for as a side effect. Some people encourage running weekly --emptytree anyways, though. Usually the idea is doing it as an experiment to see whether all packages still build and run successfully, and report bugs / commit fixes to gentoo.git whenever issues are encountered. It may also go well with running ACCEPT_KEYWORDS="**" for sys-devel/gcc and reporting regressions to the GCC bugtracker. ;) It's not actually strictly necessary to reinstall all source based packages with their binary equivalent. If you want to do that though, you can do that by looping over directories in /var/db/pkg/*/* and checking which ones have a file called BINPKGMD5 in them. Those were installed from a binpackage. Try installing all the rest with --ask, check if it says [binary] or [ebuild], and repeat after manually narrowing the list to just the ones that offer binaries. -- Eli Schwartz
OpenPGP_signature.asc
Description: OpenPGP digital signature
