On Dienstag, 6. Juni 2017 15:59:35 CEST Richard Biener wrote:
On Tue, 6 Jun 2017, Stefan Bruens wrote:
On Dienstag, 6. Juni 2017 09:31:59 CEST Richard Biener wrote:
On Sat, 3 Jun 2017, Jan Engelhardt wrote:
On Saturday 2017-06-03 19:38, Stefan Bruens wrote:
But there is no specification for libraries available in different variants, i.e. different implementations or optimizations, with compatible ABI.>
You are correct in that it is not specified. One could say that we were still experimenting with what works. One arm of that experiment was Mesa-libGL1.>
openblas [...] three libraries [..] each one carries its own SONAME (libopenblas_serial.so.0, libopenblas_pthreads.so.0, libopenblas_openmp.so.0).>
Different SONAME => different package names. It's that simple.
Now, it is trivial to set the SONAME for all three implementations to libopenblas.so.0, but unfortunately rpmlint insist on the package name to be libopenblas0 in this case, with no possibility to have different package names for the three variants.
The pattern is [vendor-][libblah1][-variant].rpm, stemming from the "other" arm of the experiment that is libatomic1-gcc6, libblasc2-openmp.
With the important part that each of the variants shall
Provide: libblah1 = %version Conflict: libblah1
to explicitely disallow installing multiple variants at the same time (you'll get file conflicts) plus make requiring them via sth other than the SONAME auto generated provides possible.
A conflict is only required if the variants have the same paths. This can be avoided by either having a filename different from the soname, or by creating directories for each variant.
Not sure this is easily possible, you need LD_LIBRARY_PATH for the latter and ldconfig will screw up the former.
I have modified the openblas package and built opencv and os-autoinst packages on top. Now I can select my variant either: - by installing only one variant - selecting one using "update-alternatives --config libopenblas.so.0"
Note that in case of libopenblas_serial vs. libopenblas_pthreads vs. libopenblas_openmp it's also a matter of how an application was built thus using the same SONAME for this might not be what you want as you do want the possibility to run a OpenMP app at the same time as a serial one both using openblas.
Thats not exactly true - I *may* want different applications running at the same time to use different variants, but more likely I want all applications to use the same variant.
Currently, the variant is fixed at link time. If I want to switch, I have to rebuild the whole stack.
For a real world example: OpenCV links against openblas_pthreads on x86(_64) (and openblas_openmp else, go figure). openblas claims to have support for switching the variants using update-alternatives, but this has no effect for OpenCV and any of its users. If I want to change the openblas variant, I have to rebuild: - openblas - opencv - all of the packages depending on openblas/opencv
But I'm quite sure -openmp and -pthreads are not equivalent when used from an OpenMP application.
For openblas, all three variants are completely equivalent from a functional point of view. OpenMP vs pthreads is an implementation detail. Of course pthreads will ignore e.g. OPENMP_NUM_THREADS, but if you really care, openmp vs pthreads should be selected at your discretion whats best. Currently, you can not select. Regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019 work: +49 2405 49936-424 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org