Openblas package (and others) appear to have malformed pkconfig file

ccapitalK · 2024-01-08 08:47:02

Hello, I'm not entirely sure if I am posting this in the right place but I searched around and to the best of my knowledge there doesn't appear to be a better place to put this. I believe that the pkconfig file included in the openblas package is broken, I would have filed this as a bug under that package but I'm seeing something similar with other pkconfig files on my system so I just want to check if I have misunderstood something or if this is due to a pervasive issue that the archlinux maintainers have to work around. The contents of the file /usr/lib/pkgconfig/openblas.pc (as provided by openblas 0.3.26-1) are the following:

libdir=/usr/lib
libsuffix=
includedir=/usr/include/openblas

openblas_config=USE_64BITINT= NO_CBLAS= NO_LAPACK= NO_LAPACKE= DYNAMIC_ARCH=ON DYNAMIC_OLDER=OFF NO_AFFINITY=ON USE_OPENMP=1 ZEN MAX_THREADS=64 
Name: OpenBLAS
Description: OpenBLAS is an optimized BLAS library based on GotoBLAS2 1.13 BSD version
Version: 0.3.26
URL: https://github.com/OpenMathLib/OpenBLAS
Libs: -fopenmp -L${libdir} -lopenblas${libsuffix} 
Cflags: -I${includedir}

In the Libs line, it adds the `-fopenmp` flag, which from everything I have read is not legal since the `Libs` line maps to the LDFLAGS variable which needs to be parseable by `ld`, `-fopenmp` is not a valid ld flag. This causes certain 3rd party userspace build systems (in particular meson, but I imagine similar issues may arise when using other build systems e.g. cargo, ninja, etc.) to crash with an error message along the lines of "/usr/bin/ld: -f may not be used without -shared". I am currently hitting this bug when trying to build a D program, I'm working around this by patching my local files but that will not be sustainable.

I've noticed similar issues in the following packages:

grep -E  Lib.*openmp /usr/lib/pkgconfig/*pc | cut -f1 -d: | xargs pacman -Qo
/usr/lib/pkgconfig/blas64.pc is owned by blas64-openblas 0.3.26-1
/usr/lib/pkgconfig/cblas64.pc is owned by blas64-openblas 0.3.26-1
/usr/lib/pkgconfig/lapack64.pc is owned by blas64-openblas 0.3.26-1
/usr/lib/pkgconfig/lapacke64.pc is owned by blas64-openblas 0.3.26-1
/usr/lib/pkgconfig/libavfilter.pc is owned by ffmpeg 2:6.1.1-1
/usr/lib/pkgconfig/libavformat.pc is owned by ffmpeg 2:6.1.1-1
/usr/lib/pkgconfig/libopenmpt.pc is owned by libopenmpt 0.7.3-1
/usr/lib/pkgconfig/libraw.pc is owned by libraw 0.21.2-1
/usr/lib/pkgconfig/libraw_r.pc is owned by libraw 0.21.2-1
/usr/lib/pkgconfig/libR.pc is owned by r 4.3.2-3
/usr/lib/pkgconfig/openblas64.pc is owned by openblas64 0.3.26-1
/usr/lib/pkgconfig/openblas.pc is owned by openblas 0.3.26-1
/usr/lib/pkgconfig/vidstab.pc is owned by vid.stab 1.1.1-1

Is this an issue with the packages, the upstream pkconf files, or my understanding of the situation? I considered posting this on the AUR forum, but this appears to mostly be affecting official packages (on my system at least).

Last edited by ccapitalK (2024-01-08 08:48:11)

loqs · 2024-01-08 10:54:18

https://github.com/OpenMathLib/OpenBLAS … cfdadbaa48

ccapitalK · 2024-01-10 01:25:48

loqs wrote:

https://github.com/OpenMathLib/OpenBLAS … cfdadbaa48

That explains where openblas introduces the dependency, but it seems strange that the upstreams for these packages have all independently decided to do this. If that truly is the case then I guess that this isn't a bug in the package (though it might be a bunch of upstream bugs).

Does anyone know of any place authoritative where I can confirm/deny my belief that the Libs line has to be parseable by ld? The resources I've found seem to mostly be strongly hinting that it should be, but I haven't found anything that states it outright...

loqs · 2024-01-10 07:52:32

$ ld -fopenmp
ld: -f may not be used without -shared
$ ld -fopenmp -shared
ld: no input files
$ ld --version
GNU ld (GNU Binutils) 2.41.0
Copyright (C) 2023 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.

The build that fails is not passing -shared to ld?

ccapitalK · 2024-01-10 08:58:51

loqs wrote:

$ ld -fopenmp
ld: -f may not be used without -shared
$ ld -fopenmp -shared
ld: no input files
$ ld --version
GNU ld (GNU Binutils) 2.41.0
Copyright (C) 2023 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.

The build that fails is not passing -shared to ld?

The `-fopenmp` flag sets the openmp option in gcc (-f enables options in gcc, the openmp option enables support for things like `#pragma omp`). `ld` doesn't support these options, and it instead parses `-fopenmp` as a command to set the DT_AUXILARY field of the elf header (basically a completely unrelated thing, and clearly not what the openblas devs intended). You can only set the DT_AUXILARY field in a shared library, which is why it complains that the `-shared` flag is missing, adding the `-shared` flag doesn't fix the issue and wouldn't work when compiling an executable anyway. The error message is a red herring, the root issue is that a gcc option is being passed directly to ld, which isn't something I'm sure is allowed in pkgconfig.

Last edited by ccapitalK (2024-01-10 08:59:48)

Lone_Wolf · 2024-01-10 10:10:18

@OpenMP_C_FLAGS@

-fopenmp is not what is added to the pkgconf file, the content of OpenMP_C_FLAGS is.
Maybe you could check where OpenMP_C_FLAGS is set and why ?

loqs · 2024-01-10 13:34:29

Lone_Wolf wrote:

Maybe you could check where OpenMP_C_FLAGS is set and why ?

https://cmake.org/cmake/help/latest/mod … penMP.html

vid.stab also uses OpenMP_C_FLAGS which then propagates through to ffmpeg.
https://github.com/georgmartius/vid.sta … ts.txt#L87

libraw different cause https://github.com/LibRaw/LibRaw/commit … ff5194680c

r looks again to be something unrelated to OpenMP_C_FLAGS.
Edit:
r looks to be caused by https://github.com/r-devel/r-svn/commit … d8bfcd138c

Last edited by loqs (2024-01-10 14:23:07)

Lone_Wolf · 2024-01-10 15:46:43

I searched for OpenMP_C_FLAGS} in openblas 3.26.0 sources and found it in 2 files : cmake/openblas.pc AND cmake/arch.cmake .

To me this indicates OpenMP_C_FLAGS must be set elsewhere.
A search for just OpenMP_C_FLAGS lead me to https://stackoverflow.com/questions/488 … -lib-names .

The mention of clang made me look at openmp & openblas packages and realise that openmp is built with clang whereas openblas is built with gcc .

The archlinux openmp package doesn't provide a pkgconf file, but there is a custom FindOpenMPTarget.cmake in it.

The archlinux openblas package does not depend on openmp , so doesn't have access to the openmp provided custom version .

Maybe openblas (and the other packages showing this) need to be build with openmp present to get the correct flags ?

Last edited by Lone_Wolf (2024-01-10 15:48:28)

loqs · 2024-01-10 16:25:47

OpenMP_C_FLAGS is set by https://github.com/Kitware/CMake/blob/v … enMP.cmake this does not explain why a compilation flag is being passed to the linker of that is expected to work.
Rebuilding openblas with openmp installed produces the same /usr/lib/pkgconfig/openblas.pc
Dropping -DUSE_OPENMP=1 without openmp installed and openmp is no longer used in /usr/lib/pkgconfig/openblas.pc. The only package that I believe Arch packages that is intended to use openblas rspamd does not as it is not built with ENABLE_BLAS=ON and I suspct as it is cmake based would not use openblas.pc in any case.
Edit:
On the face of it I would not expect a flag for compilation obtained from cmake, pkgconf or autotools to be recorded in the Libs entry of a libraries .pc file.

Last edited by loqs (2024-01-10 17:13:00)

Arch Linux

#1 2024-01-08 08:47:02

Openblas package (and others) appear to have malformed pkconfig file

#2 2024-01-08 10:54:18

Re: Openblas package (and others) appear to have malformed pkconfig file

#3 2024-01-10 01:25:48

Re: Openblas package (and others) appear to have malformed pkconfig file

#4 2024-01-10 07:52:32

Re: Openblas package (and others) appear to have malformed pkconfig file

#5 2024-01-10 08:58:51

Re: Openblas package (and others) appear to have malformed pkconfig file

#6 2024-01-10 10:10:18

Re: Openblas package (and others) appear to have malformed pkconfig file

#7 2024-01-10 13:34:29

Re: Openblas package (and others) appear to have malformed pkconfig file

#8 2024-01-10 15:46:43

Re: Openblas package (and others) appear to have malformed pkconfig file

#9 2024-01-10 16:25:47

Re: Openblas package (and others) appear to have malformed pkconfig file

Board footer