After I migrated my prefix according to https://www.gentoo.org/support/news-items/2023-01-28-rap-prefix-sysroot.html, newly installed gdb fails to work properly: it cannot load the shared library. Reproducible: Always Steps to Reproduce: 1. Emerge openblas with FEATURES=splitdebug and CFLAGS="-ggdb -O0", and compile a simple c program foo.c: ```c #include "stdio.h" #include "cblas.h" int main() { const double x[3] = {1,2,3}; const double y[3] = {1,-2,3}; double result = cblas_ddot(3, x, 1, y, 1); printf("%lf\n", result); return 0; } ``` with gcc -O0 -ggdb foo.c -o foo -lcblas 2. Run gdb to debug this program: Actual Results: gdb foo GNU gdb (Gentoo 13.1 vanilla) 13.1 Copyright (C) 2023 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://bugs.gentoo.org/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from foo... (gdb) break cblas_ddot Breakpoint 1 at 0x1040 (gdb) run Starting program: /tmp/foo warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. warning: Could not load shared library symbols for 9 libraries, e.g. /opt/gentoo/usr/lib64/blas/openblas/libcblas.so.3. Use the "info sharedlibrary" command to see the complete listing. Do you need "set solib-search-path" or "set sysroot"? Breakpoint 1, 0x0000555555555040 in cblas_ddot@plt () (gdb) step Single stepping until exit from function cblas_ddot@plt, which has no line number information. 6.000000 Program received signal SIGSEGV, Segmentation fault. 0x0000001800000000 in ?? () gdb fails to find the corresponding shared library. Expected Results: Using double prefix hack (ln -sf ${EPREFIX} ${EPREFIX}/${EPREFIX}) or execute `set sysroot /` mitigates this issue: gdb foo GNU gdb (Gentoo 13.1 vanilla) 13.1 Copyright (C) 2023 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://bugs.gentoo.org/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from foo... (gdb) set sysroot / (gdb) break cblas_ddot Breakpoint 1 at 0x1040 (gdb) run Starting program: /tmp/foo [Thread debugging using libthread_db enabled] Using host libthread_db library "/opt/gentoo/lib64/libthread_db.so.1". Breakpoint 1.2, cblas_ddot (n=3, x=0x7fffffffd260, incx=1, y=0x7fffffffd280, incy=1) at dot.c:82 82 if (n <= 0) return 0.; I tried debug gdb using gdb and locate the problem at function solib_find_1 in solib.c, where sysroot is read, and its default value is ${EPREFIX}. On original (before migration) RAP, gdb has default sysroot of / here, which does not cause any issue.
Confirmed that prefix not migrated also have this problem. It's possible that https://github.com/gentoo/gentoo/pull/25896 brings this problem via `--with-sysroot=${EPREFIX}`
Just a note to say I have reproduced this. Dropping the sysroot from configure seems like the way to go, but I'd like a closer look. It's slightly counter-intuitive, given that we configure the toolchain with the prefix as the sysroot.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7766b01c2f7ac6856cd21f8261b631bb88060bda commit 7766b01c2f7ac6856cd21f8261b631bb88060bda Author: James Le Cuirot <chewi@gentoo.org> AuthorDate: 2023-02-26 23:42:33 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-03-04 02:29:33 +0000 sys-devel/gdb: Fix cross-compiling (properly) and prefix sysroot https://github.com/gentoo/gentoo/pull/25896 tried to address cross-compiling in the wrong way by setting the runtime sysroot and the libdir. The build uses the latter to find dependent libraries by default, a common technique in GNU software. This behaviour can be avoided by passing the "without-prefix" configure option for each library, allowing the runtime sysroot and the libdir to be set as they should be. Contrary to what you might expect, the sysroot should actually not be set at all except when building cross-*/gdb, otherwise the paths get double prefixed at runtime. gdb's configure script also has a --with-build-sysroot option that should be set to assist with cross-compiling. This does not influence runtime behaviour. The includedir for cross-*/gdb has been changed to prevent it from installing under /usr/${CTARGET}, where installed headers would collide with those from a cross-compiled sys-devel/gdb build. /usr/include/${CTARGET}/gdb is consistent with the files we install under /usr/share, as well as the scheme we use for multilib headers, e.g. /usr/include/i686-pc-linux-gnu. Closes: https://bugs.gentoo.org/896008 Signed-off-by: James Le Cuirot <chewi@gentoo.org> Closes: https://github.com/gentoo/gentoo/pull/29819 Signed-off-by: Sam James <sam@gentoo.org> .../gdb/{gdb-13.1.ebuild => gdb-13.1-r1.ebuild} | 23 +++++++++++----------- sys-devel/gdb/gdb-9999.ebuild | 23 +++++++++++----------- 2 files changed, 22 insertions(+), 24 deletions(-)
