2009/3/16 Michael Matz <matz@suse.de>:
Hi,
On Fri, 13 Mar 2009, Cristian Morales Vega wrote:
2009/3/11 Cristian Morales Vega <cmorve69@yahoo.es>:
I would still like to know from someone with more knowledge of linker internal working. But seems to not matter? In the binary linked against ffmpeg the symbols are just marked like undefined whatever they are D or B in ffmpeg?
After reading a little, I understand thing a little better.
I haven't investigated what the package you talk about actually does to create the fake library, but from what you say in this thread it seems that it constructs the fake library by taking the binary full binary, i.e. the ET_DYN .so file, and removing some sections. Is that correct, or is it only how you try to solve the problem?
The original libffmpeg-api packages just creates a library from an empty file doing "gcc -o empty.so --shared empty.c"... it doesn't works. The package was never completed to a point where it would work. The section removing idea was my attempt to make it work.
In any case, this would be _extremely_ fragile, and generally a terrible idea. The only way to sensibly generate such fake library is by parsing the original exported symbols from the .so file, generating a C source file from that info, implementing empty functions and defining data symbols (of the right size), of the right visibility and version info (the latter can be done by inline asm or by a linker version script).
Something for this summer. Too much work for me right now, I don't even know asm or relocation types (I just looked to know what a COPY reloc was). Still, a good way to learn all the internals. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org