Re: Errors when compiling C++ using cross GCC

[Mark G <markg735 at gmail dot com>]

On Sun, Nov 20, 2016 at 1:10 PM, Kai Ruottu <kai.ruottu@wippies.com> wrote:
> One note about the issue I saw weird here. It can be the default for a "only
> one version at a time"
> GCC build/install but one must know what to do when wanting to install more
> than one GCC version
> for the target...

So I am only trying to build and install gcc-6.2.0. I empty out
/opt/cross every time I build GCC. There is nothing else in there.

> /opt/cross/lib/gcc/arm-linux-gnueabihf/6.2.0/../../../../arm-linux-gnueabihf/lib/libstdc++.so:(*IND*+0x0):
> multiple definition of `ldexpl@GLIBCXX_3.4.3'

But the odd thing is that the linker is reporting the other definition
is within the same exact file. That's what is so odd.

> /opt/cross/lib/gcc/arm-linux-gnueabihf/6.2.0/libstdc++.so
>
> should be the library being linked.  In a possible previous gcc-5.4.0
> install it could have been :

I'm confused where you are getting the notion that I have gcc-5.4.0
installed somewhere.

> Ok, then there is the question about what one has in the $sysroot/lib and
> $sysroot/usr/lib
> (and $sysroot/*lib/$target in Debian-like target systems)  for the C++
> support. Has one the

The current rootfs of my target is very Debian-like.

> "target system's own 'installed libstdc++.so' there?  And did it have any
> influence to the
> results if it was there during the GCC build?  It shouldn't have and
> generally it shouldn't be
> there, neither any C++ headers in '$sysroot/usr/include/c++' for the 'native
> GCC on the target'.

Doesn't seem like it is (if you take a look at the -v output). The
error message is saying libstdc++.so contains duplicate symbols within
itself which is pretty odd.

> When copying stuff into the target sysroot one must think what to do with
> the extra C++ etc
> stuff when the aim is to copy "only the (standard) C library stuff for the
> target" :(  Usually one
> unpacks only the glibc and Linux kernel headers install packages into the
> sysroot, not copies
> all the installed stuff from the target system...

It's been a few weeks but this was the way I originally tried building
it and it failed in various other ways. I did believe sysroot is in
fact supposed to work with an actual root filesystem.

> So my advice is that you check if you had a "clean barely C" installation in
> your target sysroot
> when building gcc-6.2.0. Neither any "previous" libstdc++.so's in your
> $prefix/$target/lib.  I'm

I'm not quite sure I follow. But keep in mind:

  * My sysroot is in fact read-only.
  * I clean up everything when building GCC. So the build trees (for
both binutils and and GCC) and all of /opt is wiped each time.

> filesystem on the target" after the installation. If you had a "previous
> libstdc++.so" to be found
> before the right one in sysroot, there is your problem...

To the best of my understanding GCC wants to build its own libstdc++.
So it's building that but not glibc. I tried disabling GCC's build of
libstdc++ and it wasn't able to compile C++ code at all.

According to the command line for collect2 it looks like the right
library path ordering is being set.

Thanks,
Mark