bfin c++ problem

bfin c++ problem

[Waldemar Brodkorb]

Hi,

recently Thomas Petazzoni reported an issue for the internal
toolchain support in Buildroot targeting Blackfin to me.

It seem a simple c++ hello world program can't be compiled:
cat t.c
#include <iostream>
int main(void) { std::cout << "hello, world\n"; }

./output/host/usr/bin/bfin-buildroot-linux-uclibc-g++ -o t t.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

It seems not specific to ___gtdf2, I have seen other symbols in
other buildsystems.

./output/host/usr/bin/bfin-buildroot-linux-uclibc-g++ -v                                                                                                               
Using built-in specs.
COLLECT_GCC=/home/wbx/buildroot/output/host/usr/bin/bfin-buildroot-linux-uclibc-g++.br_real
COLLECT_LTO_WRAPPER=/home/wbx/buildroot/output/host/usr/libexec/gcc/bfin-buildroot-linux-uclibc/6.1.0/lto-wrapper
Target: bfin-buildroot-linux-uclibc
Configured with: ./configure
--prefix=/home/wbx/buildroot/output/host/usr
--sysconfdir=/home/wbx/buildroot/output/host/etc --enable-static
--target=bfin-buildroot-linux-uclibc
--with-sysroot=/home/wbx/buildroot/output/host/usr/bfin-buildroot-linux-uclibc/sysroot
--disable-__cxa_atexit --with-gnu-ld --disable-libssp
--disable-multilib --with-gmp=/home/wbx/buildroot/output/host/usr
--with-mpfr=/home/wbx/buildroot/output/host/usr
--with-pkgversion='Buildroot 2016.08-git-01367-gdf60d48'
--with-bugurl=http://bugs.buildroot.net/ --disable-libquadmath
--disable-libsanitizer --disable-tls --disable-libmudflap
--enable-threads --with-mpc=/home/wbx/buildroot/output/host/usr
--without-isl --without-cloog --disable-decimal-float
--enable-languages=c,c++
--with-build-time-tools=/home/wbx/buildroot/output/host/usr/bfin-buildroot-linux-uclibc/bin
--enable-shared --disable-libgomp
Thread model: posix
gcc version 6.1.0 (Buildroot 2016.08-git-01367-gdf60d48) 

binutils 2.26.1, gcc 6.1.0 is used.

At least two patches are applied on top of gcc 6.1.0,
one for Bug 68468 and one for Bug 71721.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68468
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71721

ADI GNU Toolchain 2014R1 can compile the test program.

Does anyone have an idea?

best regards
 Waldemar

Re: bfin c++ problem

[Oliver Kullmann]

Hello,

a C++ compiler is not required to recognise "main(void)":
the correct C++ is

#include <iostream>
int main() { std::cout << "hello, world\n"; }

Oliver

On Thu, Jul 21, 2016 at 02:04:03AM +0200, Waldemar Brodkorb wrote:
> Hi,
> 
> recently Thomas Petazzoni reported an issue for the internal
> toolchain support in Buildroot targeting Blackfin to me.
> 
> It seem a simple c++ hello world program can't be compiled:
> cat t.c
> #include <iostream>
> int main(void) { std::cout << "hello, world\n"; }
> 
> ./output/host/usr/bin/bfin-buildroot-linux-uclibc-g++ -o t t.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
> 
> It seems not specific to ___gtdf2, I have seen other symbols in
> other buildsystems.
> 
> ./output/host/usr/bin/bfin-buildroot-linux-uclibc-g++ -v                                                                                                               
> Using built-in specs.
> COLLECT_GCC=/home/wbx/buildroot/output/host/usr/bin/bfin-buildroot-linux-uclibc-g++.br_real
> COLLECT_LTO_WRAPPER=/home/wbx/buildroot/output/host/usr/libexec/gcc/bfin-buildroot-linux-uclibc/6.1.0/lto-wrapper
> Target: bfin-buildroot-linux-uclibc
> Configured with: ./configure
> --prefix=/home/wbx/buildroot/output/host/usr
> --sysconfdir=/home/wbx/buildroot/output/host/etc --enable-static
> --target=bfin-buildroot-linux-uclibc
> --with-sysroot=/home/wbx/buildroot/output/host/usr/bfin-buildroot-linux-uclibc/sysroot
> --disable-__cxa_atexit --with-gnu-ld --disable-libssp
> --disable-multilib --with-gmp=/home/wbx/buildroot/output/host/usr
> --with-mpfr=/home/wbx/buildroot/output/host/usr
> --with-pkgversion='Buildroot 2016.08-git-01367-gdf60d48'
> --with-bugurl=http://bugs.buildroot.net/ --disable-libquadmath
> --disable-libsanitizer --disable-tls --disable-libmudflap
> --enable-threads --with-mpc=/home/wbx/buildroot/output/host/usr
> --without-isl --without-cloog --disable-decimal-float
> --enable-languages=c,c++
> --with-build-time-tools=/home/wbx/buildroot/output/host/usr/bfin-buildroot-linux-uclibc/bin
> --enable-shared --disable-libgomp
> Thread model: posix
> gcc version 6.1.0 (Buildroot 2016.08-git-01367-gdf60d48) 
> 
> binutils 2.26.1, gcc 6.1.0 is used.
> 
> At least two patches are applied on top of gcc 6.1.0,
> one for Bug 68468 and one for Bug 71721.
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68468
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71721
> 
> ADI GNU Toolchain 2014R1 can compile the test program.
> 
> Does anyone have an idea?
> 
> best regards
>  Waldemar

Re: bfin c++ problem

[Jonathan Wakely]

On 21 July 2016 at 04:05, Oliver Kullmann wrote:
> Hello,
>
> a C++ compiler is not required to recognise "main(void)":

That's incorrect.

Although I consider (void) parameter lists to be an abomination in
C++, "int main(void)" has exactly the same type as "int main()" which
is one of the types that all implementations must support.

Re: bfin c++ problem

[Oliver Kullmann]

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.
> 
> Although I consider (void) parameter lists to be an abomination in
> C++, "int main(void)" has exactly the same type as "int main()" which
> is one of the types that all implementations must support.

Where did you get this?
The Standard Subsection 3.6.1 says

  All implementations shall allow both of the following definitions of
  main:

    int main()
and
    int main(int argc char* argv[])

That's it!

Oliver

Re: bfin c++ problem

[Jonathan Wakely]

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.
>>
>> Although I consider (void) parameter lists to be an abomination in
>> C++, "int main(void)" has exactly the same type as "int main()" which
>> is one of the types that all implementations must support.
>
> Where did you get this?
> The Standard Subsection 3.6.1 says
>
>   All implementations shall allow both of the following definitions of
>   main:
>
>     int main()
> and
>     int main(int argc char* argv[])
>
> That's it!

It's 2016 not 2011.

The Standard (i.e. C++14) specifies the *types* of main function that
all implementations support. int main() and int main(void) are the
same type.

In any case, additional implementation-defined forms have always been
allowed, and G++ allows int main(void), so telling the OP it isn't
correct isn't very helpful. That's not the cause of his error.

Re: bfin c++ problem

[Jonathan Wakely]

On 21 July 2016 at 12:40, 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.
>>>
>>> Although I consider (void) parameter lists to be an abomination in
>>> C++, "int main(void)" has exactly the same type as "int main()" which
>>> is one of the types that all implementations must support.
>>
>> Where did you get this?
>> The Standard Subsection 3.6.1 says
>>
>>   All implementations shall allow both of the following definitions of
>>   main:
>>
>>     int main()
>> and
>>     int main(int argc char* argv[])
>>
>> That's it!
>
> It's 2016 not 2011.
>
> The Standard (i.e. C++14) specifies the *types* of main function that
> all implementations support. int main() and int main(void) are the
> same type.

The old wording you're looking at was modified by
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1003

Re: bfin c++ problem

[Oliver Kullmann]

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.
> >>
> >> Although I consider (void) parameter lists to be an abomination in
> >> C++, "int main(void)" has exactly the same type as "int main()" which
> >> is one of the types that all implementations must support.
> >
> > Where did you get this?
> > The Standard Subsection 3.6.1 says
> >
> >   All implementations shall allow both of the following definitions of
> >   main:
> >
> >     int main()
> > and
> >     int main(int argc char* argv[])
> >
> > That's it!
> 
> It's 2016 not 2011.
> 
> The Standard (i.e. C++14) specifies the *types* of main function that
> all implementations support. int main() and int main(void) are the
> same type.
>

If you could provide some evidence, that would be helpful.
I think it's wrong what you are saying.

Where is the concept of "same type" defined?
There is defined the "equivalence of types", for the purpose of
overloading, and as the Standard defines, main can not be overloaded,
and can not be called.

Also
http://en.cppreference.com/w/cpp/language/main_function
does not list "int main(void)" as a possibility.

Sure, the C++ standard is, like almost all standards, not a precise
definition, but has to be interpreted. But the interpretation, that
"main(void)" is not required, seems common.

> In any case, additional implementation-defined forms have always been
> allowed, and G++ allows int main(void), so telling the OP it isn't
> correct isn't very helpful. That's not the cause of his error.

Sure, it solves the problem: just get rid off the "void", problem
solved.

Re: bfin c++ problem

[Oliver Kullmann]

> The old wording you're looking at was modified by
> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1003

There it says

  All implementations shall allow both
  function of () returning int and ...
  as the type of main.

That is rather unclear, unfortunately.
The question is what "the type" means.
As far as I am aware, 8.3.5 only *mentions* the "equivalence of types",
but does not say where this is applicable.

And in any case, for that to work, the option "std=c++14" had to be
used, or?

Anyway, just removing the "void" seems to me the clearest solution.

And according to
  C++ Standard Core Language Defect Reports and Accepted Issues,
  Revision 96

  Issues with DR, accepted, DRWP, and WP status are NOT part of the
  International Standard for C++.
Don't know about "CD3", but it appears that is still not "in", or?

Re: bfin c++ problem

[Jonathan Wakely]

On 21 July 2016 at 13:37, Oliver Kullmann <o.kullmann@swansea.ac.uk> wrote:
>> The old wording you're looking at was modified by
>> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1003
>
> There it says
>
>   All implementations shall allow both
>   function of () returning int and ...
>   as the type of main.
>
> That is rather unclear, unfortunately.
> The question is what "the type" means.

The type of the function. It's entirely clear, give up.


> As far as I am aware, 8.3.5 only *mentions* the "equivalence of types",
> but does not say where this is applicable.

int main(void) and int main() declare the same function. It has the
same type, because it's the same function.

> And in any case, for that to work, the option "std=c++14" had to be
> used, or?

No, for several reasons including that G++ applies DRs retroactively
and G++ has **always** accepted int main(void) as a valid definition
for main.

But in any case the OP is using GCC 6, so the default is -std=gnu++14.

Seriously, why are you still banging on about this?


> Anyway, just removing the "void" seems to me the clearest solution.

But doesn't fix the OP's problem and is totally irrelevant.

> And according to
>   C++ Standard Core Language Defect Reports and Accepted Issues,
>   Revision 96
>
>   Issues with DR, accepted, DRWP, and WP status are NOT part of the
>   International Standard for C++.
> Don't know about "CD3", but it appears that is still not "in", or?

Irrelevant, the modified wording is part of C++14, which is the only
C++ standard that is still an ISO standard.

Is there any need for this continued pedantry?  The OP's code is valid.

Give it a rest.

Re: bfin c++ problem

[Oliver Kullmann]

> > That is rather unclear, unfortunately.
> > The question is what "the type" means.
> 
> The type of the function. It's entirely clear, give up.
> 
>

that's now an argument?

> > As far as I am aware, 8.3.5 only *mentions* the "equivalence of types",
> > but does not say where this is applicable.
> 
> int main(void) and int main() declare the same function. It has the
> same type, because it's the same function.
>

You won't find this in the standard.

Which is a problem!
Being involved with the "safety-and-security" industry, I can see the
enormous problems caused by such "standards". Nevertheless, the C++
standard has an important social role.

> > And in any case, for that to work, the option "std=c++14" had to be
> > used, or?
> 
> No, for several reasons including that G++ applies DRs retroactively
> and G++ has **always** accepted int main(void) as a valid definition
> for main.
>
> But in any case the OP is using GCC 6, so the default is -std=gnu++14.
>

That's fine.

> Seriously, why are you still banging on about this?
> 

Because we are language lawyers!

> 
> > Anyway, just removing the "void" seems to me the clearest solution.
> 
> But doesn't fix the OP's problem and is totally irrelevant.
> 

"Totally irrelevant"? The laywer knows that "totally" does not add, but
substracts from "irrelevant" ;-)
Would you teach such code, as Hello-World, the first program a C++ learner sees?

> > And according to
> >   C++ Standard Core Language Defect Reports and Accepted Issues,
> >   Revision 96
> >
> >   Issues with DR, accepted, DRWP, and WP status are NOT part of the
> >   International Standard for C++.
> > Don't know about "CD3", but it appears that is still not "in", or?
> 
> Irrelevant, the modified wording is part of C++14, which is the only
> C++ standard that is still an ISO standard.
> 
> Is there any need for this continued pedantry?  The OP's code is valid.
> 
> Give it a rest.

It's up to gcc anyway. Doesn't matter to me.
Don't worry.

Re: bfin c++ problem

[Waldemar Brodkorb]

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.

Thanks in advance
 Waldemar

Re: [Buildroot] bfin c++ problem

[Waldemar Brodkorb]

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

Re: [Buildroot] bfin c++ problem

[Waldemar Brodkorb]

Hi,
Waldemar Brodkorb wrote,

> 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?

I found a solution for this one, but still struggling with the next 
problem, see patches and debug logs on the buildroot mailinglist:
http://lists.busybox.net/pipermail/buildroot/2016-August/169254.html

Thanks
 Waldemar

Re: [Buildroot] bfin c++ problem

[Waldemar Brodkorb]

Hi,
Waldemar Brodkorb wrote,

> Hi,
> Waldemar Brodkorb wrote,
> 
> > 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?
> 
> I found a solution for this one, but still struggling with the next 
> problem, see patches and debug logs on the buildroot mailinglist:
> http://lists.busybox.net/pipermail/buildroot/2016-August/169254.html

I found a workaround, but opened a bug report to hopefully get the bug really
fixed:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74748

best regards
 Waldemar