Issues with compiling gst-plugins-bad with libaom support

Application Development Build issues
1

Hi,

first, congrats on moving ahead with this forum. it is more convenient than the mailing list.

I have compiled libaom on Pi (debian 11 bullseye) from src to get the latest optimization and compiled gst from src as well (1.22.6). it starts throwing issues like:

[573/867] Linking target ext/aom/libgstaom.so
FAILED: ext/aom/libgstaom.so 
cc  -o ext/aom/libgstaom.so ext/aom/libgstaom.so.p/gstaom.c.o ext/aom/libgstaom.so.p/gstav1enc.c.o ext/aom/libgstaom.so.p/gstav1dec.c.o ext/aom/libgstaom.so.p/gstav1utils.c.o -Wl,--as-needed -Wl,--no-undefined -shared -fPIC -Wl,--start-group -Wl,-soname,libgstaom.so -Wl,-Bsymbolic-functions -Wl,-z,nodelete -mcpu=arm1176jzf-s -mfloat-abi=hard -mfpu=vfp -mtune=arm1176jzf-s -Wl,-rpath,/usr/local/lib/arm-linux-gnueabihf -Wl,-rpath-link,/usr/local/lib/arm-linux-gnueabihf /usr/local/lib/arm-linux-gnueabihf/libgstpbutils-1.0.so /usr/local/lib/arm-linux-gnueabihf/libgstvideo-1.0.so /usr/local/lib/arm-linux-gnueabihf/libgstaudio-1.0.so /usr/local/lib/arm-linux-gnueabihf/libgstbase-1.0.so /usr/local/lib/arm-linux-gnueabihf/libgstreamer-1.0.so /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so /usr/lib/arm-linux-gnueabihf/libglib-2.0.so /usr/local/lib/arm-linux-gnueabihf/libaom.a -Wl,--end-group
/usr/bin/ld: /usr/local/lib/arm-linux-gnueabihf/libaom.a(encodeframe_utils.c.o): in function `av1_set_ssim_rdmult':
encodeframe_utils.c:(.text+0xa78): undefined reference to `pow'
/usr/bin/ld: /usr/local/lib/arm-linux-gnueabihf/libaom.a(encodeframe_utils.c.o): in function `av1_get_cb_rdmult':
encodeframe_utils.c:(.text+0xd18): undefined reference to `log'
/usr/bin/ld: encodeframe_utils.c:(.text+0xd3c): undefined reference to `log'
/usr/bin/ld: encodeframe_utils.c:(.text+0xd78): undefined reference to `exp'
/usr/bin/ld: /usr/local/lib/arm-linux-gnueabihf/libaom.a(encodeframe_utils.c.o): in function `av1_get_hier_tpl_rdmult':
encodeframe_utils.c:(.text+0x1078): undefined reference to `log'
/usr/bin/ld: encodeframe_utils.c:(.text+0x10c4): undefined reference to `exp'
/usr/bin/ld: /usr/local/lib/arm-linux-gnueabihf/libaom.a(encodeframe_utils.c.o): in function `av1_get_q_for_deltaq_objective':
......
......
/usr/bin/ld: disflow.c:(.text+0x718): undefined reference to `rint'
/usr/bin/ld: /usr/local/lib/arm-linux-gnueabihf/libaom.a(disflow.c.o):disflow.c:(.text+0x738): more undefined references to `rint' follow
collect2: error: ld returned 1 exit status

any hint is appreciated

full logs:

2

That looks like a bug in libaom. It should list -lm in Libs.private so that it is pulled in when doing static linking.

OOC, why do you do build libaom as a static library instead of a shared one?

3

it seems static build is actually the default configuration:
https://aomedia.googlesource.com/aom/+/refs/heads/main/build/cmake/aom_config_defaults.cmake#90

I changed it to shared and recompiled it again just in case, but still had the same issue.

4

That should be reproducible with anything else linking to it (but not explicitly by itself against -lm) too then. Can you check that other software fails the same way if it just uses the information from the pkg-config file?

5

i have compiled ffmpeg 6.0 with --enable-libaom and it seems fine. also libavif seems ok as well.

i have also raised this to aom team (link) but it seems the -lm linking is correct.

i think I’m missing something in my build but I’m not expert to see it.

6

Ok, so libaom is actually including -lm in Libs.private in the pkg-config file but it’s not used by GStreamer here. Can you report that in Gitlab? That seems like a bug somewhere either in GStreamer’s build system, or in meson not correctly picking that up.

7

done, thank you

1 Like