Ubuntu's use of -Bsymbolic-functions prevents linking a shared object from static FFmpeg
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
ffmpeg (Ubuntu) |
New
|
Undecided
|
Unassigned |
Bug Description
Hello,
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-
ffmpeg/libavcodec$ gcc -shared -Wl,-Bsymbolic -o libfoo.so h264_cabac.o cabac.o => OK
But,
ffmpeg/libavcodec$ gcc -shared -Wl,-Bsymbolic -o libfoo.so h264_cabac.o cabac.o -Wl,-Bsymbolic-
/usr/bin/ld: h264_cabac.o: relocation R_X86_64_PC32 against symbol `ff_h264_
/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?
Thanks,
Maxim
affects: | xfe (Ubuntu) → ffmpeg (Ubuntu) |
description: | updated |
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 /bugs.launchpad .net/ubuntu/ +source/ ffmpeg/ +bug/1942352). functions, $(LDFLAGS) )
# shared objects with static FFmpeg archives (see:
# https:/
ifeq ($(shell dpkg-vendor --derives-from Ubuntu && echo yes),yes)
ifneq (,$(LDFLAGS))
LDFLAGS := $(filter-out %-Bsymbolic-
endif
endif
It is a good workaround.