https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61395
Andrew Pinski <pinskia at gcc dot gnu.org> 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 <pinskia at gcc dot gnu.org> ---
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.
