[v3] gcc-runtime: Move gdb pretty printer file to auto-load location

When debugging a C++ program on target using libcstdc++, gdb does not
find the pretty printer python support, this is because the init file is
installed into /usr/lib which is excluded from gdb's default list of
directories to load config's from, where as defaults to load from
datadir is still on, it therefore does not load this file

warning: File "/usr/lib/libstdc++.so.6.0.33-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".

This leaves the libstdc++ pretty-printers disabled even though added via
IMAGE_INSTALL += "gcc-runtime-dbg"

Comment on adding missing runtime dependency on datetime python module for the pretty
printer to work/load successfully.

Once the pretty-printer gdb file is moved out of libdir, it may become
empty therefore delete it if its empty.

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
v2: Fix build on mingw
v3: Remove depending on datetime python module

 meta/recipes-devtools/gcc/gcc-runtime.inc | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

On Sat, 2024-02-03 at 22:00 -0800, Khem Raj wrote:
> When debugging a C++ program on target using libcstdc++, gdb does not
> find the pretty printer python support, this is because the init file is
> installed into /usr/lib which is excluded from gdb's default list of
> directories to load config's from, where as defaults to load from
> datadir is still on, it therefore does not load this file
> 
> warning: File "/usr/lib/libstdc++.so.6.0.33-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
> 
> This leaves the libstdc++ pretty-printers disabled even though added via
> IMAGE_INSTALL += "gcc-runtime-dbg"
> 
> Comment on adding missing runtime dependency on datetime python module for the pretty
> printer to work/load successfully.
> 
> Once the pretty-printer gdb file is moved out of libdir, it may become
> empty therefore delete it if its empty.
> 
> Signed-off-by: Khem Raj <raj.khem@gmail.com>
> ---
> v2: Fix build on mingw
> v3: Remove depending on datetime python module
> 
>  meta/recipes-devtools/gcc/gcc-runtime.inc | 12 +++++++++++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc b/meta/recipes-devtools/gcc/gcc-runtime.inc
> index 64b6168ba76..dbc9141000d 100644
> --- a/meta/recipes-devtools/gcc/gcc-runtime.inc
> +++ b/meta/recipes-devtools/gcc/gcc-runtime.inc
> @@ -85,6 +85,8 @@ do_install () {
>  		cd ${B}/${TARGET_SYS}/$d/
>  		oe_runmake 'DESTDIR=${D}' MULTIBUILDTOP=${B}/${TARGET_SYS}/$d/ install
>  	done
> +	install -d ${D}${datadir}/gdb/auto-load/${libdir}
> +	mv ${D}${libdir}/libstdc++*-gdb.py ${D}${datadir}/gdb/auto-load/${libdir}
>  	if [ -d ${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/include ]; then
>  		install -d ${D}${libdir}/${TARGET_SYS}/${BINV}/include 
>  		mv ${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/include/* ${D}${libdir}/${TARGET_SYS}/${BINV}/include
> @@ -99,6 +101,9 @@ do_install () {
>  	if [ -d ${D}${infodir} ]; then
>  		rmdir --ignore-fail-on-non-empty -p ${D}${infodir}
>  	fi
> +	if [ -d ${D}${libdir} ]; then
> +		rmdir --ignore-fail-on-non-empty -p ${D}${libdir}
> +	fi
>  }
>  
>  do_install:append:class-target () {
> @@ -182,9 +187,14 @@ RRECOMMENDS:${PN}-dbg = ""
>  
>  # include python debugging scripts
>  FILES:${PN}-dbg += "\
> -    ${libdir}/libstdc++.*-gdb.py \
>      ${datadir}/gcc-${BINV}/python/libstdcxx \
> +    ${datadir}/gdb/auto-load \
>  "
> +# Needed by libstdcxx pretty printer, however it is disabled intentionally
> +# as it adds build time dependency on bash and some cases e.g. no GPL3 cases
> +# bash is not availbale and builds fails
> +# So it needs to be added manually to images sadly.
> +# RDEPENDS:${PN}-dbg += "python3-datetime"
>  
>  FILES:libg2c = "${target_libdir}/libg2c.so.*"
>  SUMMARY:libg2c = "Companion runtime library for g77"

I'm going to go with the v3 since adding python as a runtime dependency
to gcc-runtime complicates the build dependency chains too much.

If we want to have this working properly, we probably need to stage it
into the sysroots and install it as it's own package.

Cheers,

Richard