crosstool-NG creating and using sysroot

I am creating a cross compile tool chain for x86 host to rPi 4 using crosstool-ng. The pi has:

• libc.so -> GLIB 2.36
• libstdc++.so -> GLIBCXX_3.4.30, GLIBC_2.34
• kernel -> 6.12.20
• gcc -> 12.2.0

So when I configured I chose the closest match but "downgraded" where there was no exact match. So In crosstool-ng I ended up with:

• C-library Version 2.36 Match
• C compiler Version (gcc) No 12.2 option only 12.4 so choose 11.5 downgrade
• Operating System linux version 6.12.11, closest to my 6.12.20 target downgrade
• C++ compiler I couldn't find option to set version for this worrying but I think ok looking at the produced libstd++.

all built fine.

I am now about to set-up my root system. I have read https://crosstool-ng.github.io/docs/toolchain-usage/ and I am going for option 3. sperate sysroot and staging install area. However there are some points I do not understand.

My intension it to build some libraries not using the tool chain. One of which is qt.

My original intention was to create a sysroot from the pi. I have coped over from the pi

.
├── lib -> usr/lib/
└── usr
    ├── include
    ├── lib
    ├── local
    └── src

and fixed any broken symlink. My thoughts were that I would then have available for the tool chain all the libs that I have on pi, then anything built and placed in staging area I can copy over to pi.

What I don't understand is that now I have 2 sysroots. My one created by crosstool-ng and one copied from the pi. Which should I use? Or should I merge them in some way. If I merge them in some way which lib would take precedence? E.g. libstd++ ,which one should I choose, the one from the pi or the one from the toolchain?

For example libstd++. In the toolchain sysroot I get

strings ./lib/libstdc++.so.6|grep -i glibcxx
...
GLIBCXX_3.4.29
...
GLIBC_2.34

in the sysroot from my pi I get

$ strings /usr/lib/aarch64-linux-gnu/libstdc++.so.6.0.30 |grep -i glib
...
GLIBCXX_3.4.30
...
GLIBC_2.34

So in my eyes I would be ok to use the one from the pi, and in-fact that's what I want to do for stuff to run on the pi!

I am sure this question shows a fundamental misunderstanding of the sysroot and the deployment of anything built with the compiler but that's why I am asking the questions. :)

I found the thing that worked best for me was to use the sysroot I retrieved off of my target. I needed to add some extra flags due to the structure of the raspberry pi's sysroot. Namely

-B/<path to  r pi system.o files>/

and

CMAKE_INSTALL_RPATH

as both of