169: Run tests with low max_cmd_len FAILED (cmdline_wrap.at:48) ## ------------- ## ## Test results. ## ## ------------- ## ERROR: 148 tests were run, 14 failed (5 expected failures). 21 tests were skipped. ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.1_desktop_gnome_test-20240307-085905 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-14 * clang/llvm (if any): clang version 16.0.6 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/16/bin Configuration file: /etc/clang/clang.cfg /usr/lib/llvm/16 16.0.6 Python 3.11.5 Available Rust versions: [1] rust-bin-1.71.1 * php cli (if any): HEAD of ::gentoo commit b0c8f272306380619ba7df45568337cab07453ba Author: Repository mirror & CI <repomirrorci@gentoo.org> Date: Thu Mar 7 08:49:00 2024 +0000 2024-03-07 08:48:59 UTC emerge -qpvO dev-build/libtool [ebuild U ] dev-build/libtool-2.4.7-r2 [2.4.7-r1] USE="-vanilla"
Created attachment 886926 [details] emerge-info.txt
Created attachment 886927 [details] dev-build:libtool-2.4.7-r2:20240307-122438.log
Created attachment 886928 [details] emerge-history.txt
Created attachment 886929 [details] environment
Created attachment 886930 [details] etc.clang.tar.xz
Created attachment 886931 [details] etc.portage.tar.xz
Created attachment 886932 [details] logs.tar.xz
Created attachment 886933 [details] qlist-info.txt
Created attachment 886934 [details] temp.tar.xz
Created attachment 886935 [details] tests.tar.xz
Several issues have been filed upstream. https://dev.midipix.org/cross/slibtool/issue/64 https://dev.midipix.org/cross/slibtool/issue/65 https://dev.midipix.org/cross/slibtool/issue/66 Some of the failures are likely issues with the GNU libtool testsuite.
Current status using the Gentoo ebuild with slibtool-9999. ERROR: 150 tests were run, 12 failed (5 expected failures). 19 tests were skipped. Some tests need rdclibtool to pass. 28: build and dynamically load a module FAILED (demo.at:407) 30: deplibs_check_method FAILED (demo.at:469) 34: hardcoding library path FAILED (demo.at:613) 38: override pic_flag at configure time FAILED (pic_flag.at:60) 117: dynamically ltdl preload static modules FAILED (mdemo.at:631) 120: ltdl dryrun FAILED (mdemo.at:708) 145: config.lt FAILED (early-libtool.at:220)
More details on the specific failing tests. 28: build and dynamically load a module FAILED (demo.at:407) 34: hardcoding library path FAILED (demo.at:613) https://dev.midipix.org/cross/slibtool/issue/64 30: deplibs_check_method FAILED (demo.at:469) https://dev.midipix.org/cross/slibtool/issue/65 117: dynamically ltdl preload static modules FAILED (mdemo.at:631) https://dev.midipix.org/cross/slibtool/issue/66 38: override pic_flag at configure time FAILED (pic_flag.at:60) Sets: C_pic_flag='-fpic -DPIC' CXX_pic_flag='-fpic -DPIC' Then passes to configure: lt_cv_prog_compiler_pic="$C_pic_flag" lt_cv_prog_compiler_pic_CXX="$CXX_pic_flag"` And then greps stdout for ' -fpic' which is missing with slibtool which doesn't respect these internal configure variables. The config.log shows that it respects the variables, but I am not sure how GNU libtool learns of their existence? Possibly dubious test. 120: ltdl dryrun FAILED (mdemo.at:708) ./mdemo.at:708: cmp "$before" "$after" stdout: .libs/temp/temp/before .libs/temp/temp/after differ: char 1100, line 21 ./mdemo.at:708: exit code was 1, expected 0 120. mdemo.at:676: FAILED (mdemo.at:708) It modifies the internal opt_dry_run variable in the ./libtool script with sed to force a dry run for ltdl. Then ensures this is true by comparing the contents of slibtool's .libs directory with what it expects GNU libtool to create which is regardless never true. Dubious test... 145: config.lt FAILED (early-libtool.at:220) Builds with GNU libtool and then expects slibtool to be able to finish the build, dubious test.
The current status with slibtool-0.5.36: ERROR: 150 tests were run, 8 failed (5 expected failures). 19 tests were skipped. 38: override pic_flag at configure time FAILED (pic_flag.at:60) 120: ltdl dryrun FAILED (mdemo.at:708) 145: config.lt FAILED (early-libtool.at:220) It is possible to support 38, but it is questionable if that is worth doing or even a good idea? The test changes the value the pic_flag variable inside the generated libtool from the default " -fPIC -DPIC" to " -fpic -DPIC" and passes by grepping the stdout for "-fpic". However this is of questionable usefulness to any real project and it might not be wise to wise to follow the default GNU libtool value here unconditionally. As discussed about 120 and 145 are not applicable to slibtool. Additionally this issue is running the GNU libtool testsuite with slibtool instead of the newly built libtool package. While this is very helpful for slibtool and has found several obscure failures and regressions this does not seem helpful for the libtool package. Perhaps it should by default force the use of GNU libtool for the testsuite and allow running it with slibtool optionally with an USE flag?
