bug#9492: cannot override CC when using system copy of libtool ("The wrong-gcc problem")

[Ileana Dumitrescu]

On 13/10/2024 17:01, Maxim Cournoyer wrote:
> Hello,
>
> Just a heads-up that this old bug is still relevant.  It means that one
> cannot use libtool stand-alone (without Autotools) and expect
> cross-compilation or even just switching temporarily compilers
> (e.g. from 'gcc' to 'clang' via CC to test something).  Heres' what the
> failure look like:
>
> --8<---------------cut here---------------start------------->8---
> libtool: link: gcc -shared  -fPIC -DPIC  build/obj/Core/.libs/apu.c.o 
> build/obj/Core/.libs/camera.c.o build/obj/Core/.libs/cheats.c.o 
> build/obj/Core/.libs/debugger.c.o build/obj/Core/.libs/display.c.o 
> build/obj/Core/.libs/gb.c.o build/obj/Core/.libs/joypad.c.o 
> build/obj/Core/.libs/mbc.c.o build/obj/Core/.libs/memory.c.o 
> build/obj/Core/.libs/printer.c.o build/obj/Core/.libs/random.c.o 
> build/obj/Core/.libs/rewind.c.o build/obj/Core/.libs/rumble.c.o 
> build/obj/Core/.libs/save_state.c.o build/obj/Core/.libs/sgb.c.o 
> build/obj/Core/.libs/sm83_cpu.c.o build/obj/Core/.libs/sm83_disassembler.c.o 
> build/obj/Core/.libs/symbol_hash.c.o build/obj/Core/.libs/timing.c.o 
> build/obj/Core/.libs/workboy.c.o      -Wl,-soname -Wl,libsameboy.so.0 -o 
> build/lib/.libs/libsameboy.so.0.0.0
> /gnu/store/gpq3h81bzjpirwnc0fzwsph788b9rwn4-libtool-2.5.3/bin/libtool: line 
> 10778: gcc: command not found
> make: *** [Makefile:832: build/lib/libsameboy.la] Error 127
> make: *** Waiting for unfinished jobs....
> error: in phase 'build': uncaught exception:
> --8<---------------cut here---------------end--------------->8---

I have not been able to reproduce overriding CC in libtool 2.2.6, but I
do not think it would be good practice to do.

> That's when building some Make-based software that calls libtool
> directly.  Here, the libtool version was built with GCC (has baked
> CC="gcc" variable around line 326), which is what it uses when linking
> with its $archive_cmds variable defined a bit later (line 368):
>
> --8<---------------cut here---------------start------------->8---
> archive_cmds="\$CC -shared \$pic_flag \$libobjs \$deplibs \$compiler_flags 
> \$wl-soname \$wl\$soname -o \$lib"
> --8<---------------cut here---------------end--------------->8---
>
> Seems this should be able to fix?  Check for environment CC, if not set,
> defaults to gcc?  Would this simple fix be enough?

If CC is conditional, other configuration would also need to be
conditional for the C compiler set. I have attached two versions of
libtool, one with CC=gcc and the other with CC=clang. When diffing them
you can see the other variables that would need to be updated if CC was
updated at runtime for libtool.

If you want to do a quick test and change CC, you can edit the generated
libtool to do this and then revert the change after your test. However,
you could also generate multiple standalone versions of libtool and
switch which is referenced so that the other configuration variables are
set properly.

I would consider this to be more of a feature request than a bug with
libtool to allow for defaults set during configuration to be updated,
but there may be files other than libtool generated during configuration
that would also need to be updated. Generally, I recommend reconfiguring
your project whenever CC is changed.

--
Ileana Dumitrescu

GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354

libtool-clang
Description: Text document

libtool-gcc
Description: Text document

OpenPGP_0x6570EA01146F7354.asc
Description: OpenPGP public key

OpenPGP_signature.asc
Description: OpenPGP digital signature