sigutils
sigutils copied to clipboard
BatchDrake
Meson build system support
While playing with the build system, I found that Meson may be simpler than CMake...
I've decided to open a PR to evaluate wether this is positive or negative for the project.
Thanks
Documentation coverage report
| Element | Value |
|---|---|
| Defines | 0.3% (1/351) |
| Enum Values | 0.0% (0/38) |
| Enums | 0.0% (0/12) |
| Files | 0.0% (0/91) |
| Functions | 0.0% (0/703) |
| Pages | 100.0% (3/3) |
| Structs | 2.1% (1/48) |
| Typedefs | 0.0% (0/41) |
| Variables | 2.5% (12/489) |
| Total | 1.0% (17/1776) |
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
https://github.com/FFTW/fftw3/issues/180 is making me having to patch meson CI to work in OSX. It would be nice to see it fixed...
This is done to the exception of packaging... I would love to have that but it may not be that easy...
Now without removing CMake support. Documentation is failing due to github trying to use old ci files. Should be fixed with the merge of the PR.
Just tried it and, while I do like it (I have just seen a bunch of unused variable warnings I am going to fix ASAP) I see that the libraries are installed with the wrong version suffix. This is how I did it:
% meson setup build
% cd build
% meson compile
% sudo meson install
ninja: Entering directory `/home/waldo/Documents/Desarrollo/sigutils/build'
ninja: no work to do.
Installing src/libsigutils.so.0.1 to /usr/local/lib/x86_64-linux-gnu
[...]
Installing symlink pointing to libsigutils.so.0.1 to /usr/local/lib/x86_64-linux-gnu/libsigutils.so.0
Installing symlink pointing to libsigutils.so.0 to /usr/local/lib/x86_64-linux-gnu/libsigutils.so
This is a minor though, I believe it will suffice to change this line in the top-level meson.build:
project('sigutils', ['c', 'cpp'], version: '0.1', default_options: ['cpp_std=c++17'])
Two issues:
- Libraries are installed in
/usr/local/lib/x86_64-linux-gnu/. This is not in my$LD_LIBRARY_PATH. With CMake, they were installed in/usr/local/lib. - This makes SigDigger crash when I press the capture button, and it seems some obscure, undebuggable issue in
fftwduring plan creation:
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `SigDigger'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007fe45d18c36e in ?? () from /lib/x86_64-linux-gnu/libfftw3f.so.3
[Current thread is 1 (Thread 0x7fe409e3e6c0 (LWP 4024073))]
(gdb) bt
#0 0x00007fe45d18c36e in () at /lib/x86_64-linux-gnu/libfftw3f.so.3
#1 0x00007fe45d031b57 in () at /lib/x86_64-linux-gnu/libfftw3f.so.3
#2 0x00007fe45d02b92e in fftwf_measure_execution_time () at /lib/x86_64-linux-gnu/libfftw3f.so.3
#3 0x00007fe45d027b1e in () at /lib/x86_64-linux-gnu/libfftw3f.so.3
#4 0x00007fe45d027d8f in () at /lib/x86_64-linux-gnu/libfftw3f.so.3
#5 0x00007fe45d027f4c in () at /lib/x86_64-linux-gnu/libfftw3f.so.3
#6 0x00007fe45d02862f in fftwf_mkplan_d () at /lib/x86_64-linux-gnu/libfftw3f.so.3
#7 0x00007fe45d02f7d3 in () at /lib/x86_64-linux-gnu/libfftw3f.so.3
#8 0x00007fe45d027cce in () at /lib/x86_64-linux-gnu/libfftw3f.so.3
#9 0x00007fe45d027f4c in () at /lib/x86_64-linux-gnu/libfftw3f.so.3
#10 0x00007fe45d1169d4 in fftwf_mkapiplan () at /lib/x86_64-linux-gnu/libfftw3f.so.3
#11 0x00007fe45d11dc58 in fftwf_plan_many_dft () at /lib/x86_64-linux-gnu/libfftw3f.so.3
#12 0x00007fe45d11d0a7 in fftwf_plan_dft () at /lib/x86_64-linux-gnu/libfftw3f.so.3
#13 0x00007fe45d11ce66 in fftwf_plan_dft_1d () at /lib/x86_64-linux-gnu/libfftw3f.so.3
#14 0x00007fe45d28139a in su_lib_plan_dft_1d (n=4096, in=0x7fe4505bc000, out=0x0, sign=-1, flags=0) at ../src/sigutils/lib.c:156
#15 0x00007fe45d289281 in su_specttuner_plan_new (in=0x7fe4505bc000, out=0x0, size=4096, offset=2048) at ../src/sigutils/specttuner.c:528
#16 0x00007fe45d288fa1 in su_specttuner_make_plan (self=0x55f223f713e0, in=0x7fe4505bc000) at ../src/sigutils/specttuner.c:470
#17 0x00007fe45d491942 in suscan_local_analyzer_read_circ (self=0x55f2237eada0, got=0x7fe409e3d698) at /home/waldo/Documents/Desarrollo/suscan/analyzer/workers/channel.c:647
#18 0x00007fe45d49239c in suscan_local_analyzer_circbuf_channelizer_wk_cb (mq_out=0x55f2237eada8, wk_private=0x55f2237eada0, cb_private=0x55f22240b230) at /home/waldo/Documents/Desarrollo/suscan/analyzer/workers/channel.c:845
#19 0x00007fe45d4cc62e in suscan_worker_thread (data=0x55f223f70e70) at /home/waldo/Documents/Desarrollo/suscan/analyzer/worker.c:101
#20 0x00007fe45b8ecfd4 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#21 0x00007fe45b96d66c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
(gdb)
Can you reproduce?
I have just given a look to both libsigutils generated by Meson and CMake, and it seems the only difference between both is the order in which certain libraries are loaded:
With CMake:
(metalloid) % ldd /usr/local/lib/libsigutils.so.1
linux-vdso.so.1 (0x00007ffee6e33000)
libfftw3f.so.3 => /lib/x86_64-linux-gnu/libfftw3f.so.3 (0x00007f1016e00000)
libfftw3f_threads.so.3 => /lib/x86_64-linux-gnu/libfftw3f_threads.so.3 (0x00007f1017172000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1017093000)
libvolk.so.2.5 => /lib/x86_64-linux-gnu/libvolk.so.2.5 (0x00007f1016a00000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f101681f000)
/lib64/ld-linux-x86-64.so.2 (0x00007f10171ef000)
liborc-0.4.so.0 => /lib/x86_64-linux-gnu/liborc-0.4.so.0 (0x00007f1016d7c000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f101708c000)
With Meson:
(metalloid) % ldd /home/waldo/Documents/Desarrollo/sigutils/builddir/tests/./../src/libsigutils.so.0
linux-vdso.so.1 (0x00007ffd086e9000)
libfftw3f.so.3 => /lib/x86_64-linux-gnu/libfftw3f.so.3 (0x00007ff934000000)
libfftw3f_threads.so.3 => /lib/x86_64-linux-gnu/libfftw3f_threads.so.3 (0x00007ff93437d000)
libvolk.so.2.5 => /lib/x86_64-linux-gnu/libvolk.so.2.5 (0x00007ff933c00000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff93429e000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff933a1f000)
liborc-0.4.so.0 => /lib/x86_64-linux-gnu/liborc-0.4.so.0 (0x00007ff933f7c000)
/lib64/ld-linux-x86-64.so.2 (0x00007ff9343fa000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff934297000)
It does not seem to be related by the generated library either. I replaced one with the other and now it works. I believe the culprit is the .pc files generated by Meson:
CMake:
(metalloid) % cat build/src/sigutils.pc
# sigutils library pkg-config file
# Automatically generated by CMAKE
prefix=/usr/local
exec_prefix="${prefix}"
libdir="${prefix}/lib"
includedir="${prefix}/include"
Name: sigutils
Description: Digital signal processing utility library
URL: http://github.org/BatchDrake/sigutils
Version: 0.3.0
Cflags: -I${includedir} -D_SU_SINGLE_PRECISION -DHAVE_VOLK
Libs: -L${libdir} -lsigutils -lsndfile -lfftw3f -lfftw3f_threads -lm -lvolk
Meson:
(metalloid) % cat builddir/meson-private/sigutils.pc
prefix=/usr/local
includedir=${prefix}/include
libdir=${prefix}/lib/x86_64-linux-gnu
Name: sigutils
Description: sigutils: sigutils
Version: 0.3.0
Libs: -L${libdir} -lsigutils
Cflags: -I${includedir} -DHAVE_VOLK -D_SU_SINGLE_PRECISION
- Libraries are installed in
/usr/local/lib/x86_64-linux-gnu/. This is not in my$LD_LIBRARY_PATH. With CMake, they were installed in/usr/local/lib.
What distro are you on? Ubuntu and other Debian based distributions use that as the default libdir. This also happened while compiling with CMake. You can check out https://github.com/mesonbuild/meson/issues/1972 and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685519. Also, you may want to see the generated files from CMake pipelines that also include that lib prefix as in https://github.com/BatchDrake/sigutils/actions/runs/9005540364.
I think this could be solved using command line parameters during configuration. I can document that but I would rather not fix a bug here that comes from upstream and that is not related to our BS (aka build system)...
In this computer it is bookworm/sid. But I also have testing at home with similar behavior. My CMake version is:
(carbon) % cmake --version
cmake version 3.25.1
CMake suite maintained and supported by Kitware (kitware.com/cmake).
(carbon) % whereis cmake
cmake: /usr/bin/cmake /usr/lib/x86_64-linux-gnu/cmake /usr/lib/cmake /usr/local/lib/cmake /usr/share/cmake /usr/share/man/man1/cmake.1.gz
(carbon) % apt show cmake
Package: cmake
Version: 3.25.1-1
Priority: optional
Section: devel
Maintainer: Debian CMake Team <[email protected]>
Installed-Size: 29.6 MB
Depends: libarchive13 (>= 3.3.3), libc6 (>= 2.34), libcurl4 (...)
I just removed the build directory and rebuilt sigutils from scratch (cmake .. && make). This is what the sudo make install does:
(carbon) % sudo make install
[sudo] password for waldo:
[100%] Built target sigutils
Install the project...
-- Install configuration: "Debug"
-- Installing: /usr/local/lib/libsigutils.so.0.3.0
-- Up-to-date: /usr/local/lib/libsigutils.so.1
-- Up-to-date: /usr/local/lib/libsigutils.so
-- Up-to-date: /usr/local/include/sigutils
-- Installing: /usr/local/include/sigutils/tvproc.h
-- Installing: /usr/local/include/sigutils/agc.h
(...)
I've cloned the repo in this branch to a clean bookworm machine:
dummy@debian:~/sigutils$ cat build/meson-private/sigutils.pc
prefix=/usr/local
includedir=${prefix}/include
libdir=${prefix}/lib/x86_64-linux-gnu
Name: sigutils
Description: sigutils: sigutils
Version: 0.3.0
Requires.private: sndfile >= 1.0.2, fftw3 >= 3.0, fftw3f >= 3.0, volk >= 1.0
Libs: -L${libdir} -lsigutils
Libs.private: -pthread /usr/lib/x86_64-linux-gnu/libfftw3f_threads.so -lm
Cflags: -I${includedir} -DHAVE_VOLK -D_SU_SINGLE_PRECISION
dummy@debian:~/sigutils$ uname -a
Linux debian 6.1.0-21-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.90-1 (2024-05-03) x86_64 GNU/Linux
dummy@debian:~/sigutils$ meson -v
1.0.1
dummy@debian:~/sigutils$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 12 (bookworm)
Release: 12
Codename: bookworm
I cannot replicate the erroneous PC file! :/
EDIT: I see that there is a wrong libdir folder, I will fix that later on, what I meant is that there is a requires private section with the dependencies!
Last time I checked this kept failing, will try later this week at some point.
El dom., 11 ago. 2024 11:31, Antonio Vazquez @.***> escribió:
Friendly ping!
— Reply to this email directly, view it on GitHub https://github.com/BatchDrake/sigutils/pull/97#issuecomment-2282694351, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEVET4Z5G6XSP4URP4GH23ZQ4VONAVCNFSM6AAAAABBFY6TVKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOBSGY4TIMZVGE . You are receiving this because you commented.Message ID: @.***>
The problem persists
(metalloid) % sudo meson install -C builddir
ninja: Entering directory `/home/waldo/Documents/Desarrollo/sigutils/builddir'
ninja: no work to do.
Installing src/libsigutils.so.0.3.0 to /usr/local/lib/x86_64-linux-gnu
(...)
Wait, now it works! It still installs itself in /usr/local/lib/x86-64-linux-gnu though
Or related to https://github.com/mesonbuild/meson/issues/1972 or even debian... https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685519
Let's wait for upstream...