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
_______________________________________________
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".
