Meson build system support

[antoniovazquezblanco]

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

[github-actions]

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)

[antoniovazquezblanco]

FFTW/fftw3#180 is making me having to patch meson CI to work in OSX. It would be nice to see it fixed...

[antoniovazquezblanco]

This is done to the exception of packaging... I would love to have that but it may not be that easy...

[antoniovazquezblanco]

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.

[BatchDrake]

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

[BatchDrake]

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'])

[BatchDrake]

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 fftw during 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?

[BatchDrake]

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)

[BatchDrake]

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

[antoniovazquezblanco]

One at a time... I fixed the library soversion problem. :)

[antoniovazquezblanco]

• 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 mesonbuild/meson#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)...

[BatchDrake]

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 <pkg-cmake-team@lists.alioth.debian.org>
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
(...)

[antoniovazquezblanco]

Could you please post your meson version? Thanks!

[BatchDrake]

% meson --version
0.63.3

[antoniovazquezblanco]

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!

[antoniovazquezblanco]

Friendly ping!

[BatchDrake]

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 <#97 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEVET4Z5G6XSP4URP4GH23ZQ4VONAVCNFSM6AAAAABBFY6TVKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOBSGY4TIMZVGE> . You are receiving this because you commented.Message ID: ***@***.***>

[BatchDrake]

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
(...)

[BatchDrake]

Wait, now it works! It still installs itself in /usr/local/lib/x86-64-linux-gnu though

[BatchDrake]

Related to: mesonbuild/meson#5925

[antoniovazquezblanco]

Or related to mesonbuild/meson#1972 or even debian... https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685519

Let's wait for upstream...