On Sun, 8 Nov 2020 at 02:36, Joseph D Wagner <joe@xxxxxxxxxxxxxxxxxx> wrote:
Forgive me if this is the wrong spot to ask.
I'm doing some CPU intensive work, and I'd like to optimize a few
packages. Even if it's only a 5% gain, it will add up over many
hours/days of continuous runtime.
Back in the day, I could recompile a package like this:
rpmbuild --rebuild --target=pentium3 package.srpm
And it would produce a package with source compiled using -march=pentium3.
That doesn't appear to be the case anymore for a couple of reasons:
1) /usr/lib/rpm/platform has only the generic x86_64, causing rpm macros
for more specific microarchitectures, like znver2, to fail.
2) Some configure/make scripts incorrectly recognize "znver2" as a
request for a cross-compiler, and exit the build with an error.
3) Some rpm spec files appear to use the x86_64 architecture as a test
for 64-bit capable, so providing a more specific microarchitecture, like
znver2, actually disables 64-bit extensions in those packages.
Is there a way to pass '-march=znver2' to the compiler from rpmbuild?
Or are these all bugs that have crept in over the years?
I don't think using rpmbuild directly to support this has been valid since the pentium iii or possibly iv was hot because most of the boosts since then have needed specific tweaks. You could optimize for some arch and find out that 3/4 of the chips Intel sold with that arch didn't actually support it but had it turned off somewhere. At some point in the early 2000's, I think it was documented that wasn't the way to do things anymore, but I expect that 10+ years of everyone doing it meant the docs weren't kept as why (plus all the different way software makes itself have added new items). If you need to compile for a specific architecture you need to massage your .rpmmacros to have the flags you want compiled in it. Then you need to start on the chain of tools to make sure they are really compiled in to make those changes.
Thanks for your help.
Joseph D. Wagner
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
--
Stephen J Smoogen.
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
