giuliomoro You mean ld was using it? Or is there's something in the headers that has actually changed between the versions? (again, sorry I am not experienced enough in these things).
I think the guys who maintain the g++ project choose the suite of packages. G++ usually has all the files contained in the directory where it is installed, and has a specific structure if having multiple g++ versions
e.g: root# arm-linux-gnueabihf-g++-8 -print-file-name=libc.so yields
which would be the exactly the same if you would have g++9 and run the same command
however if you run root# arm-linux-gnueabihf-g++-8 -print-file-name=libstdc++.so yielding
/usr/lib/gcc-cross/arm-linux-gnueabihf/8/libstdc++.so, and then for arm-linux-gnueabihf-g++-9
it will point you to a file in a different directory.
So my understanding is g++ uses whatever it has in its directories. And it is strongly advised not to mess up with standard libraries, therefore just use sudo apt-get install g++ version, and yeah copy additional libraries if needed to be linked with your project.
giuliomoro then why don't you grab the one from the board instead?
because glibc is used in most of the code that is written out there, and changing the version without taking care of dependencies could lead to total chaos.
giuliomoro My understanding is that it should be as easy as copying the library from the building host to the board, and run the program with LD_PRELOAD=/path/to/your/libc ./executable ?
Yes, I think this is feasible. But again your whole binary will use LD_PRELOAD=/path/to/your/libc, and there might be a call to some system function that the OS can't handle.
I can't think of a potential bug to describe that might arise from unsynced standard libraries, but I wanted to follow the best practices and avoid risky approaches at all cost.
Linking stage is not slow for me. Only the first build is slow, but that is to compile most of the code, and for minor modifications in the source afterwards it runs really quick. Always remember to pass -j5 (could be even more) for parallel jobs.