On 2018年06月01日 16:36, Alexander Kanavin wrote:
2018-06-01 8:38 GMT+03:00 Yu, Mingli <mingli...@windriver.com>:
I did investigate the path a lot before send out the patch, but didn't
figure out why it introduce the path for make_x86_64_sysv_elf_gas.o whose
source file is make_x86_64_sysv_elf_gas.S.
Anyway, I will try to dig more.
If you have any ideas, welcome to help provide some hint.
I'm not an expert in symbol tables and what goes into them, but I
strongly suspect the full path is introduced by linker because that .S
file has two assembly labels (trampoline, finish). The other two
assembly files have no such labels, and so their file paths are not
added to the .so. I'm also not sure why there needs to be a full path,
Thanks Alex very much for your comments!
I think the full path is introduced by linker and I'm also confused why
other two assembly files' o file not introduced in the final .so.
as opposed to just the file name, as is the case for .c files (maybe
to avoid clashes with labels of the same name in different files?).
I'm also concerned about that maybe it's necessary to have the full path.
Thanks,
We should probably just strip that one specific .o file before it's
linked into the library. Or if there is a way to prevent the labels
from being written into the symbol table by the assembler, we can use
that too. Sadly boost has its own build system, so doing such custom
tweaks may be tricky.
Alex
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core