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

[Ileana Dumitrescu]

On 19/10/2024 16:57, Maxim Cournoyer wrote:
> Hello Ileana,
>
> Ileana Dumitrescu <endometriosis95@gmail.com> writes:
>
> > 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 what I've been told elsewhere too.  Hence my interest in having
> libtool support it, if that's not too difficult.
>
> > > 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.
>
> The libtool manual doesn't outright says that libtool should NOT be used
> standalone. It doesn't warn against the current gotchas (cannot change
> CC, cannot cross-compile). Hence I'd perhaps consider it a bug.

This section of the libtool manual should help you understand how to use
a system-specific libtool script installed in your binary directory:
https://www.gnu.org/software/libtool/manual/libtool.html#Configuring-libtool

libtool can be used standalone as long as it has been configured for the
"compiler suite and operating system that are used to compile your
package." Cross-compilation is also possible if libtool has been
configured to do it.

To allow CC to be overridden, libtool would not set all of the
configuration variables it needs for the newly set compiler, so it would
not operate correctly. libtool would need to reconfigure itself if CC
was changed during execution... This might be possible if an option was
added to libtool to reconfigure itself, but I am open to other
suggestions for ways to approach making libtool more dynamic for users.

> I'll see if I can get to some required level of M4-foo to attempt some
> partial fix (to get started). I've been trying stuff but without success
> so far, due to the layering of M4 then shell script and still being a
> bit unclear on the expansion order/variables used.
>
> Thank you.

--
Ileana Dumitrescu

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

OpenPGP_0x6570EA01146F7354.asc
Description: OpenPGP public key

OpenPGP_signature.asc
Description: OpenPGP digital signature