app-arch/xz-utils-5.6.2 silently builds no shared library on mips(64) (stage1, n32 and n64) Stage 3 then fails since it expects a library to be there.
Created attachment 895881 [details] build log (mips64 n64 stage1)
[...] checking whether the mips64-unknown-linux-gnuabi64-gcc linker (/usr/mips64-unknown-linux-gnuabi64/bin/ld -m elf) supports shared libraries... /usr/mips64-unknown-linux-gnuabi64/bin/ld: unrecognised emulation mode: elf Supported emulations: elf64btsmip elf64ltsmip elf32btsmipn32 elf32ltsmipn32 elf32btsmip elf32ltsmip no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... unsupported checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... no checking whether to build shared libraries... no checking whether to build static libraries... yes [...]
Interestingly, this part of configure is expanded from === echo echo "Initializing Libtool:" LT_PREREQ([2.4]) LT_INIT([win32-dll]) LT_LANG([Windows Resource]) === so it doesnt even come from xz-utils...
Libtool hasn't changed for a while, so this is unlikely to be the problem. Where does it get the emulation name from? From /usr/share/aclocal/libtool.m4 : ==== mips64*-*linux*) # Find out what ABI is being produced by ac_compile, and set linker # options accordingly. echo '[#]line '$LINENO' "configure"' > conftest.$ac_ext if AC_TRY_EVAL(ac_compile); then emul=elf case `$FILECMD conftest.$ac_objext` in *32-bit*) emul="${emul}32" ;; *64-bit*) emul="${emul}64" ;; esac case `$FILECMD conftest.$ac_objext` in *MSB*) emul="${emul}btsmip" ;; *LSB*) emul="${emul}ltsmip" ;; esac case `$FILECMD conftest.$ac_objext` in *N32*) emul="${emul}n32" ;; esac LD="${LD-ld} -m $emul" fi rm -rf conftest* ;; ======
in the seed stage, file works and gcc works... dilfridge-mips64 ~ # gcc -o minimum minimum.c dilfridge-mips64 ~ # file minimum minimum: ELF 64-bit MSB pie executable, MIPS, MIPS-III version 1 (SYSV), dynamically linked, interpreter /lib64/ld.so.1, for GNU/Linux 3.2.0, not stripped
(In reply to Andreas K. Hüttel from comment #4) > Libtool hasn't changed for a while, so this is unlikely to be the problem. > Where does it get the emulation name from? > > From /usr/share/aclocal/libtool.m4 : we don't run autoreconf in the ebuild (for circular dep reasons), lasse built this release using libtool in arch which is a new beta....
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=25171b1f5847b461145906ac2bc230c462f62c21 commit 25171b1f5847b461145906ac2bc230c462f62c21 Author: Sam James <sam@gentoo.org> AuthorDate: 2024-06-15 22:41:30 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-06-15 22:45:26 +0000 app-arch/xz-utils: workaround libtool bug preventing shared library build * Fix detection of `file` with libtool-2.5.0 (which xz-5.4.7, xz.5.6.2 had dist tarballs created with). This only affects some targets. See bug #934370. See https://git.savannah.gnu.org/cgit/libtool.git/commit/?h=development&id=9a4a02615c9e7cbcfd690ed31874822a7d6aaea2. * Add a sanity check for targets which support shared libraries where we verify liblzma.so is in the image. Use tc-is-static-only to handle the concern from bug #450436. Bug: https://bugs.gentoo.org/450436 Closes: https://bugs.gentoo.org/934370 Signed-off-by: Sam James <sam@gentoo.org> app-arch/xz-utils/xz-utils-5.4.7-r1.ebuild | 155 ++++++++++++++++++++++ app-arch/xz-utils/xz-utils-5.6.2-r1.ebuild | 203 +++++++++++++++++++++++++++++ app-arch/xz-utils/xz-utils-9999.ebuild | 15 +++ 3 files changed, 373 insertions(+)
commit d284d49b7c692ad11cdeefd84345faa61295bb3a (HEAD -> master, origin/master, origin/HEAD) Author: Alfred Wingate <parona@protonmail.com> Date: Mon Jul 29 20:57:10 2024 +0300 patches: new patch to fix finding file on mips64 Signed-off-by: Alfred Wingate <parona@protonmail.com> Closes: https://github.com/gentoo/elt-patches/pull/3 Signed-off-by: Sam James <sam@gentoo.org>
