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-requ...@ffmpeg.org with subject "unsubscribe".
