Mailinglist Archive: opensuse-factory (914 mails)

< Previous Next >
Re: [opensuse-factory] Shared library policy - multiple providers for a single API/ABI
On Tue, 6 Jun 2017, Stefan Bruens wrote:

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
still experimenting with what works. One arm of that experiment was

openblas [...] three libraries [..] each one carries its own SONAME

Different SONAME => different package names. It's that simple.

Now, it is trivial to set the SONAME for all three implementations to, 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
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
on top. Now I can select my variant either:
- by installing only one variant
- selecting one using "update-alternatives --config"

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
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
- 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.

Well, if your program uses OpenMP and inside a OpenMP region calls a blas
function then behavior will be different dependent on whether blas
is OpenMP aware or not.

OpenMP aware blas should be safe, eventually the pthreads variant has
lower overhead.

Currently, you can not select.

Yes. But I don't believe in selecting in this case.




Richard Biener <rguenther@xxxxxxx>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB
21284 (AG Nuernberg)
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >