On 19/10/2024 16:57, Maxim Cournoyer wrote: > Hello Ileana, > > Ileana Dumitrescu 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