search

OpenMathLib / OpenBLAS

OpenBLAS is an optimized BLAS library based on GotoBLAS2 1.13 BSD version.
http://www.openblas.net
BSD 3-Clause "New" or "Revised" License
6.38k stars 1.5k forks source link

Help to properly package Ubuntu libopenblas #3269

Closed catree closed 3 years ago

catree commented 3 years ago

Not an issue in the OpenBLAS repository.

But it would be helpful to have the help of the OpenBLAS maintainers to properly package OpenBLAS in Ubuntu/Debian distro. Indeed, OpenBLAS installed from apt misses the lapacke.h header and maybe some other related headers (see for instance the filelist in hirsute). This prevent for instance to be able to use OpenBLAS installed from apt when building OpenCV, see:

While building OpenBLAS from source will correctly install the lapacke.h header.

There is an open issue in bugs.launchpad.net: libopenblas-dev does not include lapacke.h

See also: https://salsa.debian.org/science-team/openblas How to warn them to ship also this missing header?

Edit:

/cc @svillemot

svillemot commented 3 years ago

@catree Can you open a bug in the Debian bug tracker? https://www.debian.org/Bugs/Reporting

catree commented 3 years ago

@svillemot

Can this issue be used? https://bugs.launchpad.net/ubuntu/+source/openblas/+bug/1728068

I prefer to let someone else do the Debian bug reporting thing.

svillemot commented 3 years ago

Well, Debian is not Ubuntu. As a Debian developer, I only care about the bugs in the Debian BTS (not because I’m biased, but because I don’t have the time to verify that those Ubuntu bugs also apply to Debian).

catree commented 3 years ago

I see. I will let someone else do it. Maybe /cc @alalek if someday you have the time?

Looking at the filelists, the issue should be there in Debian:

For instance in libopenblas-openmp-dev:

/usr/include/x86_64-linux-gnu/openblas-openmp/cblas.h
/usr/include/x86_64-linux-gnu/openblas-openmp/f77blas.h
/usr/include/x86_64-linux-gnu/openblas-openmp/openblas_config.h
/usr/lib/x86_64-linux-gnu/openblas-openmp/cmake/openblas/OpenBLASConfig.cmake
/usr/lib/x86_64-linux-gnu/openblas-openmp/cmake/openblas/OpenBLASConfigVersion.cmake
/usr/lib/x86_64-linux-gnu/openblas-openmp/libblas.a
/usr/lib/x86_64-linux-gnu/openblas-openmp/libblas.so
/usr/lib/x86_64-linux-gnu/openblas-openmp/liblapack.a
/usr/lib/x86_64-linux-gnu/openblas-openmp/liblapack.so
/usr/lib/x86_64-linux-gnu/openblas-openmp/libopenblas.a
/usr/lib/x86_64-linux-gnu/openblas-openmp/libopenblas.so
/usr/lib/x86_64-linux-gnu/openblas-openmp/libopenblasp-r0.3.15.a
/usr/lib/x86_64-linux-gnu/openblas-openmp/pkgconfig/blas-openblas.pc
/usr/lib/x86_64-linux-gnu/openblas-openmp/pkgconfig/lapack-openblas.pc
/usr/lib/x86_64-linux-gnu/openblas-openmp/pkgconfig/openblas.pc
/usr/share/doc/libopenblas-openmp-dev/changelog.Debian.gz
/usr/share/doc/libopenblas-openmp-dev/changelog.gz
/usr/share/doc/libopenblas-openmp-dev/copyright
martin-frbg commented 3 years ago

What kind of help are you looking for ? I'd expect the distribution maintainer to package what would be produced by a make install after a build from source, possibly with modified paths for distribution-specific conventions or tools like the "alternatives" mechanism. No idea why lapacke.h would get left out (unless the build was intentionally not including LAPACKE or even LAPACK itself) - are they omitting the make install in their builds (bad as some headers are generated there) or replacing (C)Makefiles even ?

svillemot commented 3 years ago

Packaging is not simply dumping the output of make install. In some cases files must be omitted, renamed, or moved, to conform to the distribution standards. This issue is probably not difficult to deal with, so I need no help. What I’m just complaining about is that @catree seems to expect issues to be fixed in Debian without following the normal Debian workflow. That’s neither reasonable nor scalable (I maintain dozens of packages in Debian).

martin-frbg commented 3 years ago

Right. Any distro that omits, renames or moves files are doing so at their own discretion, so related bugs should be reported there (and of course maintainers are free to create issue tickets "upstream" i.e. here as needed, but this should not be the first recourse for users seeing a problem in the way their distribution of choice packages OpenBLAS).

alalek commented 3 years ago

I agree that this problem is not directly related to the upstream project (also this is stated by the first sentence). However project stackholders are interested in the usage of their product. At least project maintainers may provide some workarounds if any or may help to find the right contacts. Or just close if no help can be provided.

Please note, that this issue is already reported to Ubuntu tracker (see the link above). But there is no any significant progress for the last 3+ years. Also there are no "upstream" reports/questions from there too. As we can see, described process doesn't work as expected. Ubuntu reporting path is stuck.

P.S. Debian is not a primary problem of this report as stated by the issue's title. Debian is mentioned in the description, just because there is the similar case.

svillemot commented 3 years ago

The point is that Debian is Ubuntu’s upstream. So the best way of having a problem fixed in Ubuntu is to report it in Debian (unless it’s Ubuntu-specific).

svillemot commented 3 years ago

See https://wiki.ubuntu.com/Debian/ForUbuntuDevelopers#Forwarding_bug_reports

svillemot commented 3 years ago

If that procedure had been followed and the Ubuntu bug reported upstream to Debian, then I would have been made aware of this issue, and it would have been fixed long ago.

martin-frbg commented 3 years ago

@svillemot the list posted above is also missing lapack.h , which was split out of lapacke.h by Reference-LAPACK 3.9.0 in late 2019.

svillemot commented 3 years ago

@svillemot the list posted above is also missing lapack.h , which was split out of lapacke.h by Reference-LAPACK 3.9.0 in late 2019.

That should not be a concern. In Debian, LAPACKE is not built from the OpenBLAS source package, but by the package that ships Reference LAPACK. And the LAPACKE package contains lapack.h: https://packages.debian.org/sid/amd64/liblapacke-dev/filelist

martin-frbg commented 3 years ago

So the OP's point is probably moot as well, as the same would apply to lapacke.h ? (No fundamental problem with taking LAPACKE from Reference-LAPACK as that is what OpenBLAS does as well, except that I have occasionally cherry-picked fixes from the Reference-LAPACK master branch due to its longer release cycle)

svillemot commented 3 years ago

Yes, of course! Sorry for not noticing that earlier…

@catree So the solution is indeed just to install liblapacke-dev on your system.

catree commented 3 years ago

This is the original issue: https://github.com/opencv/opencv/issues/9953#issuecomment-340122217

OpenCV wants to have Lapack header into OpenBLAS folders. I would let @alalek comment on why this is needed since this is not my field of expertise.

brada4 commented 3 years ago

It is a long standing issue, not considered a problem by real upstream. Probably not worth pushing everybody else around. https://github.com/opencv/opencv/issues/9953

alalek commented 3 years ago

There are several concerns about proposed approach:

I believe that flow should be improved in Ubuntu/Debian. Fedora packages are more clear in that area (they ship lapacke.h file in /usr/include/openblas/).

svillemot commented 3 years ago

liblapacke-dev is not a LAPACK implementation, it only contains the glue code for interfacing with C. It does not include the code that actually does linear algebra computation (with a Fortran interface), which is provided by the liblapack.so included in OpenBLAS packages. So it makes sense to have liblapacke.h in liblapacke-dev, since that header is only used in a C context.

In any case, here is not the right place to discuss this. Please bring it to the Debian BTS if you disagree with those choices, and provide a rationale for why we should change this.

martin-frbg commented 3 years ago

I have to agree that it looks to be a bit unfortunate if the header file installed by lapacke-dev ends up in a different location, but I also strongly agree that this discussion should be continued on the Debian bugtracker and/or related fora.