meson's "more efficient static linking" may be causing static library linking to fail
This is just a guess right now, but I suspect that changes in meson are causing it to pass 'T' to the 'ar' command when generating a static library, and that's causing a new build failure for gst-plugins-bad1.
I'm attempting to rebuild gst-plugins-bad1 with an updated version of its one patch (for finding libsocket and libnsl and adding them to the link line for binaries that need them), however I'm running into a new problem:
[645/804] Linking target tests/check/elements_h263parse FAILED: tests/check/elements_h263parse /usr/gcc/7/bin/gcc -o tests/check/elements_h263parse tests/check/elements_h263parse.p/elements_h263parse.c.o -L/usr/lib/libjpeg8-turbo/lib -I/usr/X11/include/mesa -I/usr/X11/include -I/usr/include/libjpeg8-turbo -Wl,-z -Wl,ignore -z defs -m32 -R/usr/lib/libjpeg8-turbo/lib -m32 -O2 -Wl,-L/usr/lib/libjpeg8-turbo/lib -Wl,-R/usr/lib/libjpeg8-turbo/lib -m32 '-Wl,-rpath,$ORIGIN/../../gst-libs/gst/basecamerabinsrc:$ORIGIN/../../gst-libs/gst/interfaces:$ORIGIN/../../gst-libs/gst/uridownloader:$ORIGIN/../../gst-libs/gst/codecparsers' -Wl,--start-group gst-libs/gst/basecamerabinsrc/libgstbasecamerabinsrc-1.0.so.0.1805.0 gst-libs/gst/interfaces/libgstphotography-1.0.so.0.1805.0 gst-libs/gst/uridownloader/libgsturidownloader-1.0.so.0.1805.0 tests/check/libparser.a gst-libs/gst/codecparsers/libgstcodecparsers-1.0.so.0.1805.0 -lm /usr/lib/libgstreamer-1.0.so /usr/lib/libgobject-2.0.so /usr/lib/libglib-2.0.so /usr/lib/libgstapp-1.0.so /usr/lib/libgstbase-1.0.so /usr/lib/libgstpbutils-1.0.so /usr/lib/libgstaudio-1.0.so /usr/lib/libgstvideo-1.0.so /usr/lib/libgsttag-1.0.so /usr/lib/libgstcontroller-1.0.so /usr/lib/libgstrtp-1.0.so /usr/lib/libgstcheck-1.0.so -lrt /usr/lib/libgio-2.0.so -Wl,--end-group ld: fatal: file tests/check/libparser.a: unknown file type ld: fatal: file processing errors. No output written to tests/check/elements_h263parse collect2: error: ld returned 1 exit status [646/804] Compiling C object tests/check/elements_h264parse.p/elements_h264parse.c.o ninja: build stopped: subcommand failed.
It's the "unknown file type" for libparser.a that's the main problem.
I think what's going on is that meson 0.60+ now sometimes uses "thin" static libraries for convenience libraries that are not going to be installed. The change is outlined here:
This is just a guess, but I'm guessing that the OI linker does not understand the format for a "thin" static library.
Looking at the meson code, it was a little difficult to track down where "ar" and its arguments are (try grepping for "ar" or "-D" in the meson code...), but I eventually tracked it down to the "ArLinker" and "ArLikeLinker" in mesonbuild/linker/linker.py. Looking at the meson 0.59.4 that was in OI userland when I updated gst-plugins-bad1 in November of 2021, that version is different ("ArLinker in that version is closer to "ArLikeLinker" in 0.61.0), and isn't using "T" with ar at all.
I suspect we're going to need to patch out the "T" option to ar, so that it is never used.