Hi,
Waldemar Brodkorb wrote,
> Hi Oliver,
> Oliver Kullmann wrote,
>
> > On Thu, Jul 21, 2016 at 12:40:43PM +0100, Jonathan Wakely wrote:
> > > On 21 July 2016 at 12:12, Oliver Kullmann wrote:
> > > > On Thu, Jul 21, 2016 at 11:26:42AM +0100, Jonathan Wakely wrote:
> > > >> On 21 July 2016 at 04:05, Oliver Kullmann wrote:
> > > >> > Hello,
> > > >> >
> > > >> > a C++ compiler is not required to recognise "main(void)":
> > > >>
> > > >> That's incorrect.
>
> Thanks for any advice about correct usage of C++, but I am afraid
> it does not help in any way to fix my original problem.
> Please open up a new thread to discuss this. Thanks.
>
> Anyway, even a simple C application does compile with gcc, but not
> with g++:
>
> ./output/host/usr/bin/bfin-buildroot-linux-uclibc-g++ -o t test.c
> /home/wbx/buildroot/output/host/usr/lib/gcc/bfin-buildroot-linux-uclibc/6.1.0/../../../../bfin-buildroot-linux-uclibc/bin/ld:
> t: hidden symbol `___gtdf2' in
> /home/wbx/buildroot/output/host/usr/lib/gcc/bfin-buildroot-linux-uclibc/6.1.0/libgcc.a(_gt_df.o)
> is referenced by DSO
> /home/wbx/buildroot/output/host/usr/lib/gcc/bfin-buildroot-linux-uclibc/6.1.0/../../../../bfin-buildroot-linux-uclibc/bin/ld:
> final link failed: Bad value
> collect2: error: ld returned 1 exit status
> $ cat test.c
> int main() {
> return(0);
> }
>
> $ ./output/host/usr/bin/bfin-buildroot-linux-uclibc-gcc -o t test.c
> $ file t
> t: ELF 32-bit LSB executable, Analog Devices Blackfin, version 1
> (SYSV), dynamically linked (uses shared libs), not stripped
> $
>
> Any advice? Why does the hidden symbols in libgcc.a from the
> first-stage gcc, doesn't make it into libstdc++ shared library?
>
> Buildroot first compiles gcc with --disable-shared and have then a
> libgcc.a. Afterwards the C library (uClibc-ng) is build. In the next
> step a full --enable-shared gcc including libstdc++ is build.
> This one is then somehow mislinked and then g++ can not compile
> a simple application.
>
> It must be some architecture specific problem, because we are not
> seeing this kind of issues on any other architecture at the moment.
I think this might be solved by using a linker script for
libgcc_so.so as described here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40134
But now I am fighting again with:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68468
How can the libgcc dwarf or sjlj execptions needed for C++ can be
compiled for FDPIC toolchains?
best regards
Waldemar
