Project

General

Profile

Actions

Bug #14452

closed

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.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:

Description

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:

https://mesonbuild.com/Release-notes-for-0-60-0.html#more-efficient-static-linking-of-uninstalled-libraries

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.

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
Actions

Also available in: Atom PDF