Hi, On Fri, 13 Mar 2009, Cristian Morales Vega wrote:
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.
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? 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). But just for entertainment purposes I answer the following questions:
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?
Yes, in case of exported constant symbols. It's not important for functions.
I don't think st_size is needed.
It is necessary for data objects (because it results in COPY relocations in the executable that have to have the correct size).
st_info must be correct, at least the binding info not sure about the type.
The type must be correct, ergo the whole st_info field.
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.
It needs to point to a sensible section, though. It doesn't have to be the same as in the original library, but it has to be correct enough to make the whole fake library a "correct" ELF file. E.g. it's custom (not strictly necessary, but nice) that STT_FUNC symbols (that are defined) have a st_shndx of a code section.
- .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.
Both would be better. They are used also at link time (for exactly the same purpose as at load time, speeding up symbol lookups).
- .gnu.version and .gnu.version_r sections... I suppose they are needed to avoid problems with versioned symbols.
Yes, both necessary.
- Perhaps .note.gnu.build-id, .comment and/or .comment.SUSE.OPTs are used to do some kind of compatibility check?
They have to be in installed libraries (by SuSE policy), but aren't needed at link time.
- I have no idea what the .jcr section contains.
java class registration, usually just an empty section (containing only a null terminator), only needed at run time.
- The .dynamic section would be good to have to know where undefined symbols from the library should be search on.
It also contains the shared lib name, pointers to various tables and assorted vital info about the shared lib itself. It's required at load and link time.
- 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.
Correct.
- The ELF header must be there and be correct.
Yes.
- 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.
Right.
- The program header isn't needed but specs say must be there for the file to be valid.
Right again (I'm also rather sure that the linker simply would refuse to link against a library not containing the program headers).
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.
Except for COPY relocs and version information. I.e. you really do want to have a real library to link against (not to mention that the link editor bitches if it doesn't find a libbla.so for a -lbla argument).
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.
Uhh. This all sounds horrible. You rather want to go with the very first hint from my mail. Generate a C source from the symbols and compile that into a library. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org