repo https://github.com/sass/libsass
the generated slibtool.cfg is empty (0 bytes), so it fails something like:
slibtool.cfg
0:00:01.889 => libsass-3.6.6-r1: running do_configure... slibtoolize: install: cp /usr/share/slibtool/slibtool.m4 /builddir/libsass-3.6.6/m4 slibtoolize: install: cp /usr/share/slibtool/ltmain.sh /builddir/libsass-3.6.6/script slibtoolize: install: cp /usr/share/slibtool/ar-lib /builddir/libsass-3.6.6/script configure.ac:23: warning: The macro 'AC_GNU_SOURCE' is obsolete. configure.ac:23: You should run autoupdate. /builddir/autoconf-2.72/lib/autoconf/specific.m4:489: AC_GNU_SOURCE is expanded from... configure.ac:23: the top level configure.ac:19: installing 'script/compile' configure.ac:40: installing 'script/config.guess' configure.ac:40: installing 'script/config.sub' configure.ac:15: installing 'script/install-sh' configure.ac:15: installing 'script/missing' GNUmakefile.am:37: warning: source file '$(SASS_SASSC_PATH)/sassc.c' is in a subdirectory, GNUmakefile.am:37: but option 'subdir-objects' is disabled automake: warning: possible forward-incompatibility. automake: At least one source file is in a subdirectory, but the 'subdir-objects' automake: automake option hasn't been enabled. For now, the corresponding output automake: object file(s) will be placed in the top-level directory. However, this automake: behavior may change in a future Automake major version, with object automake: files being placed in the same subdirectory as the corresponding sources. automake: You are advised to start using 'subdir-objects' option throughout your automake: project, to avoid future incompatibility. GNUmakefile.am: installing 'script/depcomp' parallel-tests: installing 'script/test-driver' Makefile.conf:92: warning: source file 'memory/allocator.cpp' is in a subdirectory, Makefile.conf:92: but option 'subdir-objects' is disabled src/GNUmakefile.am:29: 'Makefile.conf' included from here Makefile.conf:92: warning: source file 'memory/shared_ptr.cpp' is in a subdirectory, Makefile.conf:92: but option 'subdir-objects' is disabled src/GNUmakefile.am:29: 'Makefile.conf' included from here checking for a BSD-compatible install... /usr/bin/install -c checking whether sleep supports fractional seconds... yes checking filesystem timestamp resolution... 0.01 checking whether build environment is sane... yes checking for a race-free mkdir -p... mkdir -p checking for gawk... no checking for mawk... no checking for nawk... no checking for awk... awk checking whether gmake LIBTOOL=rlibtool sets $(MAKE)... yes checking whether gmake LIBTOOL=rlibtool supports nested variables... yes checking xargs -n works... yes checking for x86_64-chimera-linux-musl-gcc... clang checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether the compiler supports GNU C... yes checking whether clang accepts -g... yes checking for clang option to enable C11 features... none needed checking whether clang understands -c and -o together... yes checking whether gmake LIBTOOL=rlibtool supports the include directive... yes (GNU style) checking dependency style of clang... gcc3 checking whether the compiler supports GNU C++... yes checking whether clang++ accepts -g... yes checking for clang++ option to enable C++11 features... none needed checking dependency style of clang++... gcc3 checking for stdio.h... yes checking for stdlib.h... yes checking for string.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for strings.h... yes checking for sys/stat.h... yes checking for sys/types.h... yes checking for unistd.h... yes checking for wchar.h... yes checking for minix/config.h... no checking whether it is safe to define __EXTENSIONS__... yes checking whether _XOPEN_SOURCE should be defined... no checking for x86_64-chimera-linux-musl-ar... ar checking for x86_64-chimera-linux-musl-dlltool... no checking for dlltool... dlltool checking for x86_64-chimera-linux-musl-dllwrap... no checking for dllwrap... no checking for x86_64-chimera-linux-musl-windres... no checking for windres... windres checking for x86_64-chimera-linux-musl-ar... (cached) ar checking for gawk... (cached) awk checking for flex... no checking for lex... no checking for a sed that does not truncate output... /usr/bin/sed checking for bison... no checking for byacc... no checking for x86_64-chimera-linux-musl-ar... (cached) ar checking for x86_64-chimera-linux-musl-nm... nm checking for x86_64-chimera-linux-musl-ranlib... ranlib checking whether ln -s works... yes checking for unistd.h... (cached) yes checking for size_t... yes checking build system type... x86_64-chimera-linux-musl checking host system type... x86_64-chimera-linux-musl checking for GNU libc compatible malloc... yes checking for floor... yes checking for getcwd... yes checking for strtol... yes checking for library containing dlopen... none required configure: Building libsass (3.6.6) checking that generated files are newer than configure... done configure: creating ./config.status config.status: creating include/sass/version.h config.status: creating GNUmakefile config.status: creating src/GNUmakefile config.status: creating src/support/libsass.pc config.status: creating slibtool.cfg slibtool: error logged in slbt_fs_map_input(), line 37: path not found: Makefile. slibtool: < returned to > slbt_lib_get_txtfile_ctx_impl(), line 68. slibtool: < returned to > slbt_get_mkvars_flags(), line 135. config.status: creating src/config.h config.status: executing depfiles commands 0:00:05.913 => libsass-3.6.6-r1: running do_build... Making all in src gmake[1]: Entering directory '/builddir/libsass-3.6.6/build/src' gmake all-am gmake[2]: Entering directory '/builddir/libsass-3.6.6/build/src' rlibtool --mode=compile clang -DHAVE_CONFIG_H -I. -I/builddir/libsass-3.6.6/src -I/builddir/libsass-3.6.6/include -Wall -O2 -ffile-prefix-map=/builddir/libsass-3.6.6=. -Wformat -Werror=format-security -ftrivial-auto-var-init=zero -fstack-clash-protection -fno-omit-frame-pointer -fsanitize=signed-integer-overflow,integer-divide-by-zero -fsanitize-trap=signed-integer-overflow,integer-divide-by-zero -fno-sanitize-recover -flto=thin -pipe -O2 -fdiagnostics-color=always -g2 -MT cencode.lo -MD -MP -MF .deps/cencode.Tpo -c -o cencode.lo /builddir/libsass-3.6.6/src/cencode.c rlibtool --mode=compile clang++ -DHAVE_CONFIG_H -I. -I/builddir/libsass-3.6.6/src -I/builddir/libsass-3.6.6/include -Wall -O2 -std=c++11 -ffile-prefix-map=/builddir/libsass-3.6.6=. -Wformat -Werror=format-security -ftrivial-auto-var-init=zero -fstack-clash-protection -fno-omit-frame-pointer -fsanitize=signed-integer-overflow,integer-divide-by-zero -fsanitize-trap=signed-integer-overflow,integer-divide-by-zero -fno-sanitize-recover -flto=thin -pipe -O2 -fdiagnostics-color=always -g2 -MT ast.lo -MD -MP -MF .deps/ast.Tpo -c -o ast.lo /builddir/libsass-3.6.6/src/ast.cpp rlibtool: fdcwd: {.fdcwd=AT_FDCWD, .realpath="/builddir/libsass-3.6.6/build/src"}. rlibtool --mode=compile clang++ -DHAVE_CONFIG_H -I. -I/builddir/libsass-3.6.6/src -I/builddir/libsass-3.6.6/include -Wall -O2 -std=c++11 -ffile-prefix-map=/builddir/libsass-3.6.6=. -Wformat -Werror=format-security -ftrivial-auto-var-init=zero -fstack-clash-protection -fno-omit-frame-pointer -fsanitize=signed-integer-overflow,integer-divide-by-zero -fsanitize-trap=signed-integer-overflow,integer-divide-by-zero -fno-sanitize-recover -flto=thin -pipe -O2 -fdiagnostics-color=always -g2 -MT ast_values.lo -MD -MP -MF .deps/ast_values.Tpo -c -o ast_values.lo /builddir/libsass-3.6.6/src/ast_values.cpp rlibtool: lconf: found "/builddir/libsass-3.6.6/build/slibtool.cfg". rlibtool: error logged in slbt_get_lconf_flags(), line 798: flow error: unexpected condition or other. gmake[2]: *** [GNUmakefile:769: cencode.lo] Error 2 [truncated]
We encountered a similar issue on Aeryn where we use slibtool as the libtool implementation. In our case we did get slibtool.cfg written but it had an empty AR value. When this happens slibtool falls back to ar but as we're a llvm-by-default distro binutils ar isn't installed by default and llvm-ar isn't picked up.
ar
llvm-ar
That issue seems to be that libsass has a very unusual structure where the project contains a Makefile and a GNUmakefile where the former doesn't have AR defined (which seems to be how slibtool picks up the value).
We encountered a similar issue on Aeryn where we use slibtool as the libtool implementation. In our case we did get slibtool.cfg written but it had an empty AR value. When this happens slibtool falls back to ar but as we're a llvm-by-default distro binutils ar isn't installed by default and llvm-ar isn't picked up. That issue seems to be that libsass has a very unusual structure where the project contains a Makefile and a GNUmakefile where the former doesn't have AR defined (which seems to be how slibtool picks up the value).
Thanks for the very useful comments! If you could possibly join #slibtool on the oftc network -- even if temporarily -- that'd be well appreciated and will likely speed things up, as I'd like to fix this via a generic, sound logic.
I can somewhat reproduce this, with autoreconf -fi && configure resulting in a populated slibtool.cfg that contains AR="" and a GNUmakefile that contains AR = ar (that's on a linux system that has gcc as the only installed compiler).
autoreconf -fi && configure
GNUmakefile
Now the question is whether to treat this as a llvm handling problem or a GNUmakefile handling problem -- I find the latter to be more generic than the former, but would like hear what others think.
If we end up agreeing on this being a GNUmakefile handling problem, and assuming that the GNUmakefile in the Aeryn build does contain AR = llvm-ar, then one possible solution would be for slibtool to scan Makefile for the AR variable (as well as similar ones), and then, should a GNUmakefile file exist, to scan it for all variables that are still empty,
slibtool
Login to comment on this ticket.