Bug 1574517 - OpenBLAS package should include the package config file
Summary: OpenBLAS package should include the package config file
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: openblas
Version: 29
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Susi Lehtola
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-05-03 13:00 UTC by Pavel Ondračka
Modified: 2019-11-27 20:12 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-11-27 20:12:38 UTC
Type: Bug


Attachments (Terms of Use)

Description Pavel Ondračka 2018-05-03 13:00:26 UTC
Description of problem:
Since the 0.2.20 version openBLAS provides the openblas.pc package config file, but it is not packaged in Fedora. 

Version-Release number of selected component (if applicable):
0.2.20-10.fc27

How reproducible:
always

Steps to Reproduce:
1. install openblas-devel

Actual results:
no openblas.pc file installed
Expected results:
openblas.pc file in the appropriate pkgconfig dir

Additional info:
I'm not sure how to deal with the multiple additional openBLAS flavours (e.g. {openmp, threads}{64, 64_}, etc.), specifically if they also need a openblas*.pc file, but packaging the openblas.pc file for the basic openblas lib would be a nice start.

Comment 1 Pavel Ondračka 2018-05-07 10:36:23 UTC
Looking at the openblas spec file shows that the pkgconfig file is actually deleted on purpose:

# Get rid of generated pkgconfig file
rm -rf %{buildroot}%{_libdir}/pkgconfig

Is there some specific reason why the pkgconfig file can not be packaged?

Comment 2 Susi Lehtola 2018-05-07 11:28:10 UTC
Exactly because there are multiple flavors and supplying a pkgconfig file gives you the false impression that there's only one variant.

The use of a pkgconfig file is rather limited, since it's easier to just add -lopenblas{,p,o}{,64{,_}} to your link command than patch in the correct pkgconfig file. This is IMHO simpler than having six different pkgconfig files for the different variants, which can silently give you the wrong result. (It's not obvious the default version should be the sequential one.)

Comment 3 Pavel Ondračka 2018-05-07 12:41:57 UTC
Well, I can see the complications, but to be honest I don't see a problem with choosing one specific version to be the default. I personally prefer the serial one (but choosing the same one as is the default upstream build, i.e. the threaded openblas with the 32bit interface (openblasp library) should be also reasonable). I think the openblasp library is the one which is lately used also by other Fedora packages which need BLAS (e.g. numpy), so this would play in favor of this choice as well.

I'm not sure how such default config could give you silently wrong result? Sure, you could get suboptimal performance, but it should be better than nothing.

From a perspective of a developer who wants an app to autodetect libraries in a reasonable way, the pkgconfig it the most common tool, i.e. there is a reason it was added upstream.
By not including the .pc file, packages which depend on pkgconfig to detect openBLAS (and since upstream has it now it is a reasonable assumption that the distros will pick it as well) will not be able to detect it at all.

Comment 4 Susi Lehtola 2018-05-07 14:13:34 UTC
The pthreads version is the wrong one to use, since it doesn't play nice with OpenMP applications, which are nowadays pretty much ubiquitous in numerical programming.

Comment 5 Pavel Ondračka 2018-05-07 14:47:33 UTC
I will defer to you judgment what the default version should be, but if the pthreads and openmp does not play well together then maybe the serial version should be the default choice.
It would also make sense from the point of view that when you pass -lopenblas to your flags on Fedora ATM, you will link with the serial version, hence it would make sense for the pkg-config --libs openblas to return the -lopenblas flag

I would really prefer to have one .pc file for each version, similar how it is done for example with fftw which have multiple fftw{,f,l,q}.pc files. However fftw suffixes are standard upstream naming, while OpenBLAS suffix naming is unfortunately distro dependent as far as I can see. Hence the benefit for app portability would be probably minimal there. I could bring this up upstream though to see if they can come up with some consistent library versions naming...

But even if the above is not solved, having one default .pc file does not IMO hurt anything.

Comment 6 Pavel Ondračka 2018-05-21 09:10:17 UTC
I'm reopening this bug for a next round of discussion, since there were further related improvements upstream.

Specifically since this commit:
https://github.com/xianyi/OpenBLAS/commit/67912943120c9488b53a8d1dcf645f6a3b950475
the OpenBLAS .pc files now contains majority of the build options in the openblas_config variable. Hence it should be now IMO possible to have a really distro independent openblas detection.

E.g. if each openblas flavor had its .pc file, you could just do "pkg-config --list-all | grep openblas" to detect all installed flavors and then you can obtain the build options with "pkg-config --variable openblas_config openblas{,p,o}{,64{,_}}" for each detected library and select the one you prefer based on the output.

Comment 7 Ben Cotton 2018-11-27 15:39:36 UTC
This message is a reminder that Fedora 27 is nearing its end of life.
On 2018-Nov-30  Fedora will stop maintaining and issuing updates for
Fedora 27. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora  'version' of '27'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 27 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 8 Ben Cotton 2018-11-30 21:40:34 UTC
Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 9 Ben Cotton 2019-10-31 20:22:47 UTC
This message is a reminder that Fedora 29 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '29'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 29 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 10 Ben Cotton 2019-11-27 20:12:38 UTC
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.