gdb: Don't overwrite CC when checking for BFD support

  In gdb/acinclude.m4 'libtool' is hard coded within the provided custom
CC variable which results in a failure when using slibtool instead of
GNU libtool where the two different libtool implementations are
incompatible when both are used during the same build process at once.

This can be solved by using the default value for CC instead where
autotools is capable of providing an adequate value by default. I
attached a patch doing this.

A bug report was issued here:
https://sourceware.org/bugzilla/show_bug.cgi?id=30295

Please see comment 3 with the explanation where before I was missing
the real issue.
  

>>>>> orbea via Gdb-patches <gdb-patches@sourceware.org> writes:

> This can be solved by using the default value for CC instead where
> autotools is capable of providing an adequate value by default. I
> attached a patch doing this.

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.

I think for ordinary gdb builds, using libtool here is required.

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.

Anyway, I'm sorry, but I don't think this patch can go in as-is.

thanks,
Tom
  

On Fri, 21 Apr 2023 08:51:07 -0600
Tom Tromey <tom@tromey.com> 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.