On Sun, Nov 20, 2016 at 1:10 PM, Kai Ruottu <kai.ruottu@xxxxxxxxxxx> 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
