-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
avx2_shift_lib logic is wrong #17
Comments
This is a non-issue at the moment, since avx2 is really only used with a few key libraries where performance has been thoroughly tested and the libs are in the |
I do agree that |
gvfs was only used an an example as the strace was handy, but yeah it would unlock enabling avx2 in a few more packages, i believe I ran into this originally when looking into avx2 for octave. |
I don't really think it's worth it in octave. I looked at this in the past and it gets most benefit from its dependencies getting AVX2 (fftw, openblas). The rest of the internal stuff is either a light wrapper for those functions or awful interpreter code that's beyond saving. |
(Making this so Bryan sees it for libypkg rewrite).
Currently the avx2_shift_lib command in rc.yml dumps everything into /usr/lib64/haswell/*, this is wrong for packages which install themselves to
/usr/lib64/packagename
. avx2_shift_lib will install such packages to/usr/lib64/haswell/packagename
, however, glibc actually tries to load haswell libs from/usr/lib64/packagename/haswell
Strace output from glibc 2.33 (which also searches the new glibc-hwcaps directories)
Setting %libdir% back to /usr/lib64/haswell (which special care taken for the glibc package) or manually mangling the libs after the install step to /usr/lib64/packagename/haswell would fix this.
Potentially,
.so.avx2
files could be skipped so patching packages which dlopen their modules would be easier.The text was updated successfully, but these errors were encountered: