bug-libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#9492: cannot override CC when using system copy of libtool ("The wro


From: Maxim Cournoyer
Subject: bug#9492: cannot override CC when using system copy of libtool ("The wrong-gcc problem")
Date: Sat, 19 Oct 2024 22:57:59 +0900
User-agent: Gnus/5.13 (Gnus v5.13)

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.

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.

-- 
Maxim





reply via email to

[Prev in Thread] Current Thread [Next in Thread]