Bug #14452


meson's "more efficient static linking" may be causing static library linking to fail

Added by Tim Mooney over 1 year ago. Updated 4 months ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


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/ gst-libs/gst/interfaces/ gst-libs/gst/uridownloader/ tests/check/libparser.a gst-libs/gst/codecparsers/ -lm /usr/lib/ /usr/lib/ /usr/lib/ /usr/lib/ /usr/lib/ /usr/lib/ /usr/lib/ /usr/lib/ /usr/lib/ /usr/lib/ /usr/lib/ /usr/lib/ -lrt /usr/lib/ -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/ 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.

Actions #2

Updated by Tim Mooney over 1 year ago

This issue is resolved with the fix Aurélien committed to oi-userland.

Actions #3

Updated by Marcel Telka 4 months ago

  • Status changed from New to Resolved

Also available in: Atom PDF