On Fri, 21 Apr 2023 08:51:07 -0600 Tom Tromey wrote: > I applied this patch and re-ran autoconf, then tried a build. > It failed, and looking in gdb/config.log I see: > > configure:28348: gcc -o conftest -I../../binutils-gdb/gdb/../include > -I../bfd -I../../binutils-gdb/gdb/../bfd -g -O2 -L../bfd > -L../libiberty conftest.c -lbfd -liberty -lncursesw -lm >&5 > /bin/ld: cannot find -lbfd > > ... which is what I guess I would have predicted. This is likely because the first '-l../bfd' precedes the '-L../bfd' and I have attached a new more complete patch that should correct this oversight. Additionally I made a second patch for libctf which has the same issue. > IIUC you are using some kind of libtool replacement. I don't know > exactly how but it seems to me that some other sort of fix is needed. > > Perhaps the line: > > CC="./libtool --quiet --mode=link $CC" > > could also use whatever variable(s) you are setting to pass in your > alternative setup? Looking at your build log, I don't see anything > special passed to configure, so perhaps that also has to change on > your side. When using an alternative libtool implementation it is set in the user's environment with the $MAKEFLAGS variable. export MAKEFLAGS='LIBTOOL=rlibtool' However some build systems where I believe gdb is an example will somehow lose $MAKEFLAGS during the build process through the use of recursive make where the $MAKE variable also needs to be set. export MAKE='make LIBTOOL=rlibtool' Ideally it would be nice to not rely on the $LIBTOOL variable during the configure process. If you are interested there is more information at the slibtool upstream git repo. https://dev.midipix.org/cross/slibtool Additionally the directions on how to use this in Gentoo is documented at their wiki. https://wiki.gentoo.org/wiki/Slibtool > Anyway, I'm sorry, but I don't think this patch can go in as-is. > > thanks, > Tom Thank you for testing and apologies that I should of looked closer before submitting my first patch.