2009/3/11 Cristian Morales Vega
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. If I'm not wrong, a false library needs: - Since the linker search symbols by name the .dynsym and .dynstr sections are needed. But, does the value (st_value) needs to be the same? It's my understanding that different compilations will have different values, so this is only checked at load time and for libffmpeg-api purpose the value can be anything? I don't think st_size is needed. st_info must be correct, at least the binding info not sure about the type. st_other also must be correct since specifies the symbol visibility. st_shndx, the section index... since st_value isn't section relative I don't think this value matters. - .hash and .gnu.hash. Not sure if they are used only at load time or also at link time. If they are used .gnu.hash should be enough. - .gnu.version and .gnu.version_r sections... I suppose they are needed to avoid problems with versioned symbols. - Perhaps .note.gnu.build-id, .comment and/or .comment.SUSE.OPTs are used to do some kind of compatibility check? - I have no idea what the .jcr section contains. - The .dynamic section would be good to have to know where undefined symbols from the library should be search on. - So .rela.dyn, .rela.plt, .init, .plt, .text, .fini, .rodata, .eh_frame_hdr, .eh_frame, .ctors, .dtors, .data.rel.ro, .got, .got.plt, .data and .bss are just needed at load and runtime and aren't needed at all for libffmpeg-api. - The ELF header must be there and be correct. - The section header probably must be there. But doesn't needs to be equal to the original. It doesn't even needs to contains all the sections referenced by symbols st_shndx since st_shndx isn't important. Still, it would be "pretty" if "st_shndx"s would point to the correct section. - The program header isn't needed but specs say must be there for the file to be valid. But after all this... I'm asking myself why the library is needed to start with. For the final executable linked against ffmpeg libraries: - A DT_NEEDED will be added for every -lxxx in LDFLAGS with no check at all (not true if --as-needed is used). - Every symbol not defined in the executable, but in the library will be marked undefined in the executable .dynsym section. No additional info is stored in the executable. So, when the linker asks me for the libraries... it jut does checks? It could create the same executable without these libraries (at least when not linking statically). That would be good to know, if that's true I don't need to worry about the compatibility with Packman packages... if I'm able to create an executable I will be sure it will work (if the headers are the same). What I would do is "dd count=1 ibs=<X> obs=1 seek=<Y> conv=notrunc if=/dev/zero of=<library>" every library from Packman packages. 'X' would be the section size and 'Y' the offset obtained from "readelf -S" output. That would be done for every section that wants to be deleted. I would do the dd thing over a "strip -R <section>" since this way I don't touch the section header and so st_shndx would continue being correct. This would be good enough. Then what would make it perfect would be looking for functions through the symbol table, and from the symbol value add an "exit(0)" instruction to every function... so when a configure script wants to check ffmpeg is working it will not segfault. I would be unable to do the latter. I'm still a newbie with all this linking/ELF thing. Someone corrects me? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org