[Bug c/61395] Linker cannot find symbols in object files compiled with recent GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61395 mimamer at gmail dot com changed: What|Removed |Added Status|RESOLVED|CLOSED Resolution|FIXED |INVALID --- Comment #5 from mimamer at gmail dot com --- (change status to INVALID, erroneously had it changed before)
[Bug c/61395] Linker cannot find symbols in object files compiled with recent GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61395 --- Comment #4 from mimamer at gmail dot com --- I'm sorry to bother you one more time. All symbols are marked as hidden in libgcc.a, true. But they become "local default" when I create a shared libgcc.so from it. Just to help me understand what is going on I tried globalizing the __divdi symbol in my libgcc.so with objcopy, but I still cannot successfully link it. Why? (Thanks again.) (And btw, creating my own t-* files seems like horror.)
[Bug c/61395] Linker cannot find symbols in object files compiled with recent GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61395 --- Comment #3 from Andrew Pinski --- (In reply to mimamer from comment #2) > Well, since this did work for 4.3.4, what is the proper way to build > libgcc.so? The proper way is to edit the t-* files under libgcc for your target. > No, I cannot specify my own triplet, the target is a custom OS > under development. That is an incorrect, you can define your own new triplet something like arch-*-miameros .
[Bug c/61395] Linker cannot find symbols in object files compiled with recent GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61395 mimamer at gmail dot com changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #2 from mimamer at gmail dot com --- Well, since this did work for 4.3.4, what is the proper way to build libgcc.so? No, I cannot specify my own triplet, the target is a custom OS under development.
[Bug c/61395] Linker cannot find symbols in object files compiled with recent GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61395 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED URL||c support. I created a ||shared libgcc.so version ||from libgcc.a using 'ld' ||and specifying ||--whole-archive (as well as ||the other usual flags). ||Now, when I try to link ||even a very simple test ||program that emits a symbol ||defined in a shared library ||such as libgcc.so the link ||step fails with GCC/ld ||complaining that the symbol ||(e.g., __divdi3) cannot be ||found. I can verify that ||the symbol is available in ||libgcc.so's .symtab (as ||FUNC LOCAL DEFAULT 12) and ||specified in main.o's ||.symtab (as NOTYPE GLOBAL ||DEFAULT UND), yet when I ||try to link main.o with ||-lgcc (or libgcc.so) I get ||"Undefined reference to ||`__divdi3'". Upgrading the ||linker did not have any ||effect. I can also verify ||that the linker finds all ||input files in the right ||places, so I am completely ||at lost what is going wrong Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- The symbols in libgcc.a are marked as hidden. This is the wrong way to build a shared library version. Also -elf targets don't support shared libraries at all. If this is your own target, you should create a new target triplet instead of reusing the -elf ones.
