Ubuntu's use of -Bsymbolic-functions prevents linking a shared object from static FFmpeg

Bug #1942352 reported by Apteryx
This bug affects 1 person
Affects Status Importance Assigned to Milestone
ffmpeg (Ubuntu)

Bug Description


I've spent much time trying to figure out why linking the Jami daemon [0] as a shared library against Ubuntu's own build of FFmpeg or our own would *not* work (any version, from 18.04 to 21.04), while it would link just fine in Debian.

It turns out this is caused by Ubuntu's usage of -Bsymbolic-functions by default:

ffmpeg/libavcodec$ gcc -shared -Wl,-Bsymbolic -o libfoo.so h264_cabac.o cabac.o => OK


ffmpeg/libavcodec$ gcc -shared -Wl,-Bsymbolic -o libfoo.so h264_cabac.o cabac.o -Wl,-Bsymbolic-functions
/usr/bin/ld: h264_cabac.o: relocation R_X86_64_PC32 against symbol `ff_h264_cabac_tables' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status

This is rather confusing!

Any idea of how this can be resolved/worked around?



[0] https://git.jami.net/savoirfairelinux/ring-daemon

Apteryx (maxco)
affects: xfe (Ubuntu) → ffmpeg (Ubuntu)
description: updated
Revision history for this message
Apteryx (maxco) wrote :

I've peeked at the fix that was done for the fox1.6, which was also negatively impacted by -Bsymbolic-functions, and it was doing this in its debian/rules file:

# Ubuntu defaults to use -Bsymbolic-functions, which breaks linking
# shared objects with static FFmpeg archives (see:
# https://bugs.launchpad.net/ubuntu/+source/ffmpeg/+bug/1942352).
ifeq ($(shell dpkg-vendor --derives-from Ubuntu && echo yes),yes)
ifneq (,$(LDFLAGS))
  LDFLAGS := $(filter-out %-Bsymbolic-functions,$(LDFLAGS))

It is a good workaround.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers