[Bug Report]: static libs are unconditionally built/installed on linux

[ZeroChaos-]

What type of issue is this?

permanent - occurring repeatedly

What issue are you facing?

static libs are built and installed during make install but not needed or requested

What are the steps to reproduce this?

cmake make hackrf (builds just shared lib) make install (builds static lib and installs both static and shared lib)

Can you provide any logs? (output, errors, etc.)

https://github.com/greatscottgadgets/hackrf/issues/1193#issuecomment-1262587406 https://bugs.gentoo.org/724906

[mossmann]

We provide multiple options for building libhackrf.

• only dynamic libraries: make hackrf
• only static libraries: make hackrf-static
• both: make all or make

Are these options insufficient in some way?

[mossmann]

Oh, it looks like make install installs both static and dynamic libraries even if you do make hackrf-static install. Would it be acceptable to add a separate make install-static target and change the make install behavior to only build dynamic?

[ZeroChaos-]

in Gentoo libhackrf and hackrf-tools are currently divided into two separate packages. It seems that building this way doesn't support "make hackrf"

>>> Compiling source in /var/tmp/portage/net-libs/libhackrf-2022.09.1/work/hackrf-2022.09.1/host/libhackrf ...
make -j12 -l12 hackrf 
make: *** No rule to make target 'hackrf'.  Stop.

regular make (which I assume runs make all) works fine, just builds more than I want. I am not great at reading the CMakeFiles, so I can't make much of a suggestion here.

[mossmann]

I'm not sure how you are getting No rule to make target 'hackrf'. It looks like your output is truncated. Can you provide more context for this error?

This works for me:

cd host/libhackrf/
mkdir build
cd build
cmake ..
make hackrf

[ZeroChaos-]

>>> Emerging (1 of 1) net-libs/libhackrf-2022.09.1::maintainer-zero
 * hackrf-2022.09.1.tar.xz BLAKE2B SHA512 size ;-) ...                                                                                                                [ ok ]
>>> Unpacking source...
>>> Unpacking hackrf-2022.09.1.tar.xz to /var/tmp/portage/net-libs/libhackrf-2022.09.1/work
>>> Source unpacked in /var/tmp/portage/net-libs/libhackrf-2022.09.1/work
>>> Preparing source in /var/tmp/portage/net-libs/libhackrf-2022.09.1/work/hackrf-2022.09.1/host/libhackrf ...
 * Source directory (CMAKE_USE_DIR): "/var/tmp/portage/net-libs/libhackrf-2022.09.1/work/hackrf-2022.09.1/host/libhackrf"
 * Build directory  (BUILD_DIR):     "/var/tmp/portage/net-libs/libhackrf-2022.09.1/work/hackrf-2022.09.1/host/libhackrf_build"
>>> Source prepared.
>>> Configuring source in /var/tmp/portage/net-libs/libhackrf-2022.09.1/work/hackrf-2022.09.1/host/libhackrf ...
 * Source directory (CMAKE_USE_DIR): "/var/tmp/portage/net-libs/libhackrf-2022.09.1/work/hackrf-2022.09.1/host/libhackrf"
 * Build directory  (BUILD_DIR):     "/var/tmp/portage/net-libs/libhackrf-2022.09.1/work/hackrf-2022.09.1/host/libhackrf_build"
cmake -C /var/tmp/portage/net-libs/libhackrf-2022.09.1/work/hackrf-2022.09.1/host/libhackrf_build/gentoo_common_config.cmake -G Ninja -DCMAKE_INSTALL_PREFIX=/usr -DINSTALL_UDEV_RULES=yes -DUDEV_RULES_GROUP=usb -DUDEV_RULES_PATH=/lib/udev/rules.d -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_TOOLCHAIN_FILE=/var/tmp/portage/net-libs/libhackrf-2022.09.1/work/hackrf-2022.09.1/host/libhackrf_build/gentoo_toolchain.cmake /var/tmp/portage/net-libs/libhackrf-2022.09.1/work/hackrf-2022.09.1/host/libhackrf
loading initial cache file /var/tmp/portage/net-libs/libhackrf-2022.09.1/work/hackrf-2022.09.1/host/libhackrf_build/gentoo_common_config.cmake
CMake Deprecation Warning at CMakeLists.txt:24 (cmake_minimum_required):
  Compatibility with CMake < 2.8.12 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.


-- The C compiler identification is GNU 11.3.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/x86_64-pc-linux-gnu-gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Found PkgConfig: /usr/bin/x86_64-pc-linux-gnu-pkg-config (found version "1.8.0") 
-- Checking for module 'libusb-1.0'
--   Found libusb-1.0, version 1.0.26
CMake Warning (dev) at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:438 (message):
  The package name passed to `find_package_handle_standard_args` (LIBUSB)
  does not match the name of the calling package (USB1).  This can lead to
  problems in calling code that expects `find_package` result variables
  (e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):
  /var/tmp/portage/net-libs/libhackrf-2022.09.1/work/hackrf-2022.09.1/host/cmake/modules/FindUSB1.cmake:39 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  CMakeLists.txt:48 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Found LIBUSB: /usr/lib64/libusb-1.0.so  
-- Looking for include file pthread.h
-- Looking for include file pthread.h - found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE  
-- HackRF udev rules will be installed to '/lib/udev/rules.d' upon running 'make install'
-- <<< Gentoo configuration >>>
Build type      RelWithDebInfo
Install path    /usr
Compiler flags:
C               -Os -march=native -mtune=native -pipe -frecord-gcc-switches -std=gnu90
C++             
Linker flags:
Executable      -Wl,-O1 -Wl,--as-needed -Wl,--defsym=__gentoo_check_ldflags__=0
Module          -Wl,-O1 -Wl,--as-needed -Wl,--defsym=__gentoo_check_ldflags__=0
Shared          -Wl,-O1 -Wl,--as-needed -Wl,--defsym=__gentoo_check_ldflags__=0

-- Configuring done
-- Generating done
-- Build files have been written to: /var/tmp/portage/net-libs/libhackrf-2022.09.1/work/hackrf-2022.09.1/host/libhackrf_build
>>> Source configured.
>>> Compiling source in /var/tmp/portage/net-libs/libhackrf-2022.09.1/work/hackrf-2022.09.1/host/libhackrf ...
make -j12 -l12 hackrf 
make: *** No rule to make target 'hackrf'.  Stop.
 * ERROR: net-libs/libhackrf-2022.09.1::maintainer-zero failed (compile phase):
 *   emake failed
 * 
 * If you need support, post the output of `emerge --info '=net-libs/libhackrf-2022.09.1::maintainer-zero'`,
 * the complete build log and the output of `emerge -pqv '=net-libs/libhackrf-2022.09.1::maintainer-zero'`.
 * The complete build log is located at '/var/log/portage/net-libs:libhackrf-2022.09.1:20220929-161748.log'.
 * For convenience, a symlink to the build log is located at '/var/tmp/portage/net-libs/libhackrf-2022.09.1/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/net-libs/libhackrf-2022.09.1/temp/environment'.
 * Working directory: '/var/tmp/portage/net-libs/libhackrf-2022.09.1/work/hackrf-2022.09.1/host/libhackrf'
 * S: '/var/tmp/portage/net-libs/libhackrf-2022.09.1/work/hackrf-2022.09.1/host/libhackrf'

[martinling]

Breaking down that cmake command to make it more readable:

cmake \
-C /var/tmp/portage/net-libs/libhackrf-2022.09.1/work/hackrf-2022.09.1/host/libhackrf_build/gentoo_common_config.cmake \
-G Ninja \
-DCMAKE_INSTALL_PREFIX=/usr \
-DINSTALL_UDEV_RULES=yes \
-DUDEV_RULES_GROUP=usb \
-DUDEV_RULES_PATH=/lib/udev/rules.d \
-DCMAKE_BUILD_TYPE=RelWithDebInfo \
-DCMAKE_TOOLCHAIN_FILE=/var/tmp/portage/net-libs/libhackrf-2022.09.1/work/hackrf-2022.09.1/host/libhackrf_build/gentoo_toolchain.cmake \
/var/tmp/portage/net-libs/libhackrf-2022.09.1/work/hackrf-2022.09.1/host/libhackrf

It's generating a Ninja build, not a Makefile, so it may not be surprising that make doesn't work. But if you had no Makefile at all I'd expect the error:

make: *** No targets specified and no makefile found.  Stop.

I don't know anything about gentoo packaging but it seems like this isn't following our normal build processes.

[ZeroChaos-]

ugh, thanks @martinling , that's my bad.

So, based on the original feedback from @mossmann and the pointing out of the obvious by @martinling , I'll amend the bug description. The actual issue is that make/ninja install seems to install the static file unconditionally. If make/ninja hackrf is used, then make install ends up invoking the compiler to build the static lib during install.

>>> Compiling source in /var/tmp/portage/net-libs/libhackrf-2022.09.1/work/hackrf-2022.09.1/host/libhackrf ...
 * Source directory (CMAKE_USE_DIR): "/var/tmp/portage/net-libs/libhackrf-2022.09.1/work/hackrf-2022.09.1/host/libhackrf"
 * Build directory  (BUILD_DIR):     "/var/tmp/portage/net-libs/libhackrf-2022.09.1/work/hackrf-2022.09.1/host/libhackrf_build"
ninja -v -j12 -l12 hackrf
[1/3] /usr/bin/x86_64-pc-linux-gnu-gcc -DLIBRARY_RELEASE=\"2022.09.1\" -DLIBRARY_VERSION=\"0.7\" -Dhackrf_EXPORTS -I/usr/include/libusb-1.0  -Os -march=native -mtune=native -pipe -frecord-gcc-switches -std=gnu90 -fPIC   -Wall -MD -MT src/CMakeFiles/hackrf.dir/hackrf.c.o -MF src/CMakeFiles/hackrf.dir/hackrf.c.o.d -o src/CMakeFiles/hackrf.dir/hackrf.c.o -c /var/tmp/portage/net-libs/libhackrf-2022.09.1/work/hackrf-2022.09.1/host/libhackrf/src/hackrf.c
[2/3] : && /usr/bin/x86_64-pc-linux-gnu-gcc -fPIC -Os -march=native -mtune=native -pipe -frecord-gcc-switches -std=gnu90  -Wl,-O1 -Wl,--as-needed -Wl,--defsym=__gentoo_check_ldflags__=0 -shared -Wl,-soname,libhackrf.so.0 -o src/libhackrf.so.0.7.0 src/CMakeFiles/hackrf.dir/hackrf.c.o  -lusb-1.0  -lpthread && :
[3/3] /usr/bin/cmake -E cmake_symlink_library src/libhackrf.so.0.7.0  src/libhackrf.so.0 src/libhackrf.so && :
>>> Source compiled.
>>> Test phase [not enabled]: net-libs/libhackrf-2022.09.1

>>> Install net-libs/libhackrf-2022.09.1 into /var/tmp/portage/net-libs/libhackrf-2022.09.1/image
 * Source directory (CMAKE_USE_DIR): "/var/tmp/portage/net-libs/libhackrf-2022.09.1/work/hackrf-2022.09.1/host/libhackrf"
 * Build directory  (BUILD_DIR):     "/var/tmp/portage/net-libs/libhackrf-2022.09.1/work/hackrf-2022.09.1/host/libhackrf_build"
ninja -v -j12 -l12 install
[1/3] /usr/bin/x86_64-pc-linux-gnu-gcc -DLIBRARY_RELEASE=\"2022.09.1\" -DLIBRARY_VERSION=\"0.7\" -I/usr/include/libusb-1.0  -Os -march=native -mtune=native -pipe -frecord-gcc-switches -std=gnu90   -Wall -MD -MT src/CMakeFiles/hackrf-static.dir/hackrf.c.o -MF src/CMakeFiles/hackrf-static.dir/hackrf.c.o.d -o src/CMakeFiles/hackrf-static.dir/hackrf.c.o -c /var/tmp/portage/net-libs/libhackrf-2022.09.1/work/hackrf-2022.09.1/host/libhackrf/src/hackrf.c
[2/3] : && /usr/bin/cmake -E rm -f src/libhackrf.a && /usr/bin/x86_64-pc-linux-gnu-ar qc src/libhackrf.a  src/CMakeFiles/hackrf-static.dir/hackrf.c.o && /usr/bin/x86_64-pc-linux-gnu-ranlib src/libhackrf.a && :
[2/3] cd /var/tmp/portage/net-libs/libhackrf-2022.09.1/work/hackrf-2022.09.1/host/libhackrf_build && /usr/bin/cmake -P cmake_install.cmake
-- Install configuration: "RelWithDebInfo"
-- Installing: /var/tmp/portage/net-libs/libhackrf-2022.09.1/image/usr/lib64/pkgconfig/libhackrf.pc
-- Installing: /var/tmp/portage/net-libs/libhackrf-2022.09.1/image/lib/udev/rules.d/53-hackrf.rules
-- Installing: /var/tmp/portage/net-libs/libhackrf-2022.09.1/image/usr/lib64/libhackrf.so.0.7.0
-- Installing: /var/tmp/portage/net-libs/libhackrf-2022.09.1/image/usr/lib64/libhackrf.so.0
-- Installing: /var/tmp/portage/net-libs/libhackrf-2022.09.1/image/usr/lib64/libhackrf.so
-- Installing: /var/tmp/portage/net-libs/libhackrf-2022.09.1/image/usr/lib64/libhackrf.a
-- Installing: /var/tmp/portage/net-libs/libhackrf-2022.09.1/image/usr/include/libhackrf/hackrf.h
>>> Completed installing net-libs/libhackrf-2022.09.1 into /var/tmp/portage/net-libs/libhackrf-2022.09.1/image

The comment in https://github.com/greatscottgadgets/hackrf/issues/1193#issuecomment-1262500341 is the real issue. I am happy to accept changing the behavior of make install as suggested in that comment, or something like make install-dynamic for just dynamic and keep the default behavior as is. Either way is fine for me, upstream's choice.

[martinling]

I don't think we should change the existing behaviour of make install, since any number of other users may be depending on it.

Could you clarify what split you want to achieve? The usual separation I'd expect to see at the distro level is that you'd have:

• a libhackrf runtime package with just the dynamic libraries and udev rules
• a libhackrf-dev package which would include everything else needed to build against libhackrf: headers, pkg-config file, and static libraries.

An install-dynamic target which installs everything except the static libraries seems like an odd mix?

Experience has made me a bit wary of requests from distributions to change an upstream build system, because in my experience they're often followed by requests from other distro packagers to do things their way instead... :smile:

Personally I think it's simpler if the upstream package keeps a single install target, and distro packagers divide the results up as they see fit in their own packaging scripts. It's not a big package, we're talking about only a handful of files here.

[ZeroChaos-]

That is an interesting take, however, the existence of make hackrf and make hackrf-static show clear intent of upstream to support exactly what I want, which is to build (and install) only one or the other (in my case just the shared libs).

Since these two make targets exist separately already, I don't feel I'm asking a lot to have separate make install type targets as well. Again, I fully agree that the default behavior should probably stay the same (despite very few users on linux needing static libs), but making these two separate install targets and then having install simply use both targets is a fairly minimal change.

Most distros, debian for example, ship the solib with the main package and then drop the static lib in the dev package, because most users simply don't need it. In gentoo, we do roughly the same thing with a "use flag" which controls which parts get installed and which don't. The difference is that debian et al like to build everything at once and divide the results into different packages, while gentoo builds for the user's requested config. I can and have done some patching on the build system to get my desired results, but it's just a hack to disable static completely https://github.com/gentoo/gentoo/blob/master/net-libs/libhackrf/files/hackrf-disable-static-2022.09.1.patch

I opened this bug after fixing the issue for myself, because the inability to disable (or choose) static libs seemed unusual. If I'm asking too much, if you feel this request is inappropriate, you are welcome to simply say no and close the bug. That said, every reasonable distro doesn't ship static libs by default for a reason, and not only are static libs shipped by default here, they cannot be disabled.

[BenHut1]

That is an interesting take, however, the existence of make hackrf and make hackrf-static show clear intent of upstream to support exactly what I want, which is to build (and install) only one or the other (in my case just the shared libs).

Since these two make targets exist separately already, I don't feel I'm asking a lot to have separate make install type targets as well. Again, I fully agree that the default behavior should probably stay the same (despite very few users on linux needing static libs), but making these two separate install targets and then having install simply use both targets is a fairly minimal change.

Most distros, debian for example, ship the solib with the main package and then drop the static lib in the dev package, because most users simply don't need it. In gentoo, we do roughly the same thing with a "use flag" which controls which parts get installed and which don't. The difference is that debian et al like to build everything at once and divide the results into different packages, while gentoo builds for the user's requested config. I can and have done some patching on the build system to get my desired results, but it's just a hack to disable static completely https://github.com/gentoo/gentoo/blob/master/net-libs/libhackrf/files/hackrf-disable-static-2022.09.1.patch

I opened this bug after fixing the issue for myself, because the inability to disable (or choose) static libs seemed unusual. If I'm asking too much, if you feel this request is inappropriate, you are welcome to simply say no and close the bug. That said, every reasonable distro doesn't ship static libs by default for a reason, and not only are static libs shipped by default here, they cannot be disabled.

And he seems to be ignoring you, which is quite rude, as he hasn't appeared to do any fix or even attempt at fix to what you are describing.

[straithe]

It isn't intentional ignoring. We've got the information we need, we just don't have the work cycles available to take this any further at this time based on development priorities across all of our repositories. Thank you for caring about the community.

[Vascom]

I also need to disable build and install of static lib for Fedora packaging. It will be great if we no need to hack sources for that.