Hi Tomi,
On Mon, Feb 20, 2023 at 01:13:09PM +0200, Tomi Valkeinen wrote:
> On 12/02/2023 02:51, Laurent Pinchart wrote:
> > Hello everybody,
> >
> > This series is the latest (and greatest) attempt to switch v4l-utils
> > from autotools to meson.
> >
> > Compared to v7, the series has been rebased on top of the latest master
> > branch, and lots of fixes have been added. All review comments should
> > have been addressed. Detailed changelogs are included in individual
> > patches, in particular in patch 3/6.
> >
> > The rebase was a bit painful due to the new v4l2-tracer tool and its
> > code generation script. While meson handles code generation fine, it
> > required fixes to the script to be able to specify the output directory
> > and to generate the trace and retrace sources separately. Many thanks to
> > Sakari for his help with this, which I've included in this series as
> > patch 1/6.
> >
> > Gregor, I haven't included the Tested-by tag you gave on v7 as v8
> > contains many small changes. Sorry about that.
> >
> > The patches are based on 3 pending patches for v4l-utils that have been
> > posted to the list in the last couple of days:
> >
> > - libv4lconvert: Don't ignore return value of ftruncate()
> > - keytable: Add -fno-stack-protector compilation option
> > - configure.ac: Add option to disable compilation of v4l2-tracer
> >
> > None are strictly required, but I've included the equivalent of the
> > second and third patches in the meson support, so I wanted to base the
> > patches on top of the autotools' equivalent. I expect those three
> > patches to be merged soon.
> >
> > As far as I can tell, meson support is now ready. I can address review
> > comments in a v9 if there are any, but I'd like to merge it soon to
> > avoid another painful rebase. I'll be available to fix issues on top if
> > any problem is encountered later.
> >
> > A tag that includes this series can be found at
> >
> > git://linuxtv.org/pinchartl/v4l-utils.git tags/meson-v8
>
> If I build this for x86 or arm64 with default options, it builds fine. If I build for arm32 (against my buildroot rootfs), the build fails:
>
> [197/254] Compiling C object contrib/test/v4l2gl.p/v4l2gl.c.o
> FAILED: contrib/test/v4l2gl.p/v4l2gl.c.o
> ccache /home/tomba/work/buildroot/output32/host/bin/arm-buildroot-linux-gnueabihf-gcc -Icontrib/test/v4l2gl.p -Icontrib/test -I../contrib/test -I../lib/include -I../include -I/home/tomba/work/buildroot/output32/host/arm-buildroot-linux-gnueabihf/sysroot/usr/include -I/home/tomba/work/buildroot/output32/host/arm-buildroot-linux-gnueabihf/sysroot/usr/include/libdrm -I/home/tomba/work/buildroot/output32/host/arm-buildroot-linux-gnueabihf/sysroot/usr/include/valgrind -I. -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=gnu99 -O2 -g -Wpointer-arith -D_GNU_SOURCE -DPROMOTED_MODE_T=int -DENABLE_NLS -MD -MQ contrib/test/v4l2gl.p/v4l2gl.c.o -MF contrib/test/v4l2gl.p/v4l2gl.c.o.d -o contrib/test/v4l2gl.p/v4l2gl.c.o -c ../contrib/test/v4l2gl.c
> ../contrib/test/v4l2gl.c:268:60: error: expected ‘,’ or ‘;’ before ‘V4L_UTILS_VERSION’
> 268 | const char *argp_program_version = "V4L2 grabber version " V4L_UTILS_VERSION;
> | ^~~~~~~~~~~~~~~~~
Thank you for the report. I've test-compiled for arm32, but my build
environment may not have the features needed by v4l2gl.c, so it may have
been skipped. Would you be able to check what goes wrong ? v4l2gl.c
includes config.h, so V4L_UTILS_VERSION should be defined. Does your
config.h (generated in the build directory) define V4L_UTILS_VERSION ?
Does your buildroot environment provide a config.h that is being picked
instead ?
> I also see some warnings, which are possibly not related to this seris, like:
That's not related as far as I can tell.
> [207/254] Compiling C++ object utils/cec-ctl/cec-ctl.p/cec-ctl.cpp.o
> In file included from /home/tomba/work/buildroot/output32/host/arm-buildroot-linux-gnueabihf/include/c++/11.3.0/vector:72,
> from ../utils/cec-ctl/cec-ctl.cpp:13:
> /home/tomba/work/buildroot/output32/host/arm-buildroot-linux-gnueabihf/include/c++/11.3.0/bits/vector.tcc: In member function ‘void std::vector<_Tp, _Alloc>::_M_realloc_insert(std::vector<_Tp, _Alloc>::iterator, _Args&& ...) [with _Args = {const cec_msg&}; _Tp = cec_msg; _Alloc = std::allocator<cec_msg>]’:
> /home/tomba/work/buildroot/output32/host/arm-buildroot-linux-gnueabihf/include/c++/11.3.0/bits/vector.tcc:426:7: note: parameter passing for argument of type ‘std::vector<cec_msg>::iterator’ changed in GCC 7.1
> 426 | vector<_Tp, _Alloc>::
> | ^~~~~~~~~~~~~~~~~~~
> In file included from /home/tomba/work/buildroot/output32/host/arm-buildroot-linux-gnueabihf/include/c++/11.3.0/vector:67,
> from ../utils/cec-ctl/cec-ctl.cpp:13:
> /home/tomba/work/buildroot/output32/host/arm-buildroot-linux-gnueabihf/include/c++/11.3.0/bits/stl_vector.h: In member function ‘void std::vector<_Tp, _Alloc>::push_back(const value_type&) [with _Tp = cec_msg; _Alloc = std::allocator<cec_msg>]’:
> /home/tomba/work/buildroot/output32/host/arm-buildroot-linux-gnueabihf/include/c++/11.3.0/bits/stl_vector.h:1198:28: note: parameter passing for argument of type ‘__gnu_cxx::__normal_iterator<cec_msg*, std::vector<cec_msg> >’ changed in GCC 7.1
> 1198 | _M_realloc_insert(end(), __x);
> | ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~
>
--
Regards,
Laurent Pinchart
