Open upsj opened 2 years ago
The file is included wrongly as $PREFIX/lib/*-gdb.py
. Can you figure out the reason and send a PR to fix it?
I am somewhat new to conda, so I have three questions to investigate this further
# Probably don't want to do this for cross-compilers
# mkdir -p ${PREFIX}/share/gdb/auto-load/usr/lib/
# cp ${SRC_DIR}/gcc_built/${CHOST}/sysroot/lib/libstdc++.so.6.*-gdb.py ${PREFIX}/share/gdb/auto-load/usr/lib/
seems to suggest so, but it might need the target triplet x86_64-conda-linux-gnu
as a prefix, to match the location of libstdc++.so
.so
is provided by multiple packages:
./libstdcxx-ng-9.5.0-hf86b28c_16/lib/libstdc++.so.6.0.28
./gxx_impl_linux-64-9.5.0-h6c5bc03_16/lib/libstdc++.so.6.0.28-gdb.py
./gcc_bootstrap_linux-64-9.5.0-hf039093_10/lib/libstdc++.so.6.0.28-gdb.py
./gcc_bootstrap_linux-64-9.5.0-hf039093_10/x86_64-conda-linux-gnu/lib/libstdc++.so.6.0.28
./gcc_impl_linux-64-9.5.0-h6c5bc03_16/x86_64-conda-linux-gnu/lib/libstdc++.so.6.0.28
is libstdcxx-ng even necessary in that case? I'd assume that gxx_impl will be the one that is used in the end?
I can already tell you that the relevant line is make -C $CHOST/libstdc++-v3/python prefix=${PREFIX} install
in install-g++.sh
, but didn't dig further. If gcc used the library from libstdcxx-ng, at least the relative path would be correct, but if it used the one from gxx_impl, it would be missing the x86_64-conda-linux-gnu/
prefix.
It seems like gxx_impl_linux-64 9.5.0 should work fine. Can you try updating gxx_impl_linux-64 in your env?
Not sure what you're saying - I built gxx_impl_linux-64 9.5.0, and it contains the correct file, but in the wrong location. I'll see if I can fix it. In general, putting the file into auto-load
regardless of whether we're cross-compiling or not seems safe, since the (not binary, but structural) layout of the types is pretty much architecture-independent.
@upsj Were you able to make any more progress on this? This issue has been bugging me for a while now. Your write up helped me understand what was going on but I haven't been able to figure out a good workaround for this.
@isuruf can you please explain why this code is commented out? https://github.com/conda-forge/ctng-compilers-feedstock/blob/54154d3669138f9e9bb879889c7e930d1634e77b/recipe/install-g%2B%2B.sh#L31-L33
Without the *-gdb.py
in the right place you don't get pretty-printing for libstdc++ symbols in debuggers. I see there is a file under $CONDA_PREFIX/lib/-gdb.py
and I'm not sure how it gets there.
Solution to issue cannot be found in the documentation.
Issue
On most system package managers, libstdc++ provides an automatic integration into
gdb
by placing a file intoshare/gdb/auto-load
that loads the pretty-printers that are present inshare/gcc-x.x.x/python/libstdcxx
. This integration seems to be missing from conda, which makes debugging binaries that were compiled with conda's C++ compiler unnecessarily tedious.Two possible solutions to this would be 1. creating a custom
gdbinit
file that sets the auto-load safe-path and loads the file or 2. creating the file in the expected location forlibstdc++.so
in the first place, which can be seen by running gdb on a simple C++ test program:Installed packages
Environment info