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

["Martin Storsjö" <martin@martin.st>]

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.

// Martin
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".