[FFmpeg-devel] duplicate symbol '_dec_init' in: fftools/ffmpeg_dec.o

Andreas Rheinhardt andreas.rheinhardt at outlook.com
Mon Mar 18 12:52:07 EET 2024


Martin Storsjö:
> On Sun, 17 Mar 2024, Rémi Denis-Courmont wrote:
> 
>> Obviously not. Imported libraries are only there to resolve missing
>> symbols.
> 
> Sure - but if resolving the missing symbols brings in those conflicting
> object files, there's not much to do about it. If the static library
> contains dec_init in a standalone object file that nothing references,
> then sure, it won't be an issue. But if linking libbr brings in the
> object file that defines that symbol, we can't get around it.
> 
> Example:
> 
> $ cat mylib.h
> void mylib_func(void);
> $ cat mylib.c
> #include "mylib.h"
> void mylib_func(void) { }
> void dec_init(void) { }
> $ cat main.c
> #include "mylib.h"
> 
> void dec_init(void) { }
> 
> int main(int argc, char **argv) {
>     mylib_func();
>     return 0;
> }
> $ gcc -c mylib.c
> $ ar rcs libmylib.a mylib.o
> $ gcc -c main.c
> $ gcc main.o -o main -L. -lmylib
> /usr/bin/ld: ./libmylib.a(mylib.o): in function `dec_init':
> mylib.c:(.text+0xb): multiple definition of `dec_init';
> main.o:main.c:(.text+0x0): first defined here
> collect2: error: ld returned 1 exit status
> 
> I don't see what you propose that the FFmpeg build system should do
> differently to get around this issue, other than libbr not exposing
> global symbols outside of their namespace.
> 

I think he wants us to use partial linking for the fftools: Link all the
object files for a given fftool into a single object file and make this
object file export nothing (except main).

- Andreas



More information about the ffmpeg-devel mailing list