https://bugzilla.redhat.com/show_bug.cgi?id=1591910 --- Comment #10 from Dave Love <dave.love@xxxxxxxxxxxxxxxx> --- (In reply to Antonio Trande from comment #9) > (In reply to Dave Love from comment #8) > > (In reply to Antonio Trande from comment #7) > > > > > - libblas* libraries are not hardened: > > > > > > $ checksec --file libblas.so.3 > > > RELRO STACK CANARY NX PIE RPATH > > > RUNPATH FORTIFY Fortified Fortifiable FILE > > > Partial RELRO No canary found NX enabled DSO No RPATH > > > No RUNPATH No 0 0 libblas.so.3 > > > > Do you know how to change that? Linking with %build_ldflags doesn't affect > > that result. I assume it doesn't make any real difference for the shims. > > It depends by these commands: > > + cc -shared -Wl,-soname=libblas.so.3 ... > > Add %__global_ldflags as options. __global_ldflags is defined as %build_ldflags. Have you actually made it work? I guess the only reason to worry about it at all is so it doesn't show up. Those libraries are as close as possible to an alias of libblis etc., so I doubt there's much scope for compromising them anyhow. > > > > > - These packages provide same blas* libraries: > > > > > > $ repoquery --whatprovides libblas.so.* > > > Last metadata expiration check: 2:17:11 ago on sab 22 set 2018 12:57:31 CEST. > > > blas-0:3.8.0-8.fc28.i686 > > > blas-0:3.8.0-8.fc28.x86_64 > > > blas-0:3.8.0-9.fc28.i686 > > > blas-0:3.8.0-9.fc28.x86_64 > > > > > > Must be filtered, i guess. > > > > Sorry, I don't know what that's getting at. Could you explain? (It's > > arguable clear how the libblas shims should be handled, especially as either > > openblas of blis might win in different circumstances.) > > This package provides libblas.so.* libraries (inside a private directory): > > blis: > blis > blis(x86-64) > config(blis) > libblas.so.3()(64bit) > libblis.so.1()(64bit) > > like 'blas': https://koji.fedoraproject.org/koji/rpminfo?rpmID=14724212 > > libblas from 'blis' and libblas from 'blas' have same name. > Probably, you'll need to filter libblas from 'blis' and set rpath links from > libblis* to %_libdir/blisblas/libblas* . > > Please, ask in devel mailing list if this is right approach. No, the idea is that you should be able to swap BLAS implementations at run time via LD_LIBRARY_PATH/ld.so.conf; perhaps README.Fedora needs a better explanation. (See also https://loveshack.fedorapeople.org/blas-subversion.html for what I've run in anger with OpenBLAS.) Fedora does need a useful linear algebra policy, but that's been rejected in committee. Can you see a real problem in practice with this approach? -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx
