Date: Fri, 31 Jan 2025 18:37:24 -0800 From: Mark Millard <marklmi@yahoo.com> To: Guido Falsi <mad@madpilot.net>, Baptiste Daroussin <bapt@FreeBSD.org>, Nuno Teixeira <eduardo@freebsd.org>, FreeBSD Mailing List <freebsd-ports@freebsd.org> Subject: Re: poudriere loop: llvm19-19.1.7: missed shlib PORTREVISION chase Message-ID: <38DA5A67-D8FF-4FC7-815F-552B2B9D36BF@yahoo.com> References: <38DA5A67-D8FF-4FC7-815F-552B2B9D36BF.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Guido Falsi <mad_at_madpilot.net> wrote on Date: Fri, 31 Jan 2025 21:04:20 UTC : > On 31/01/25 19:13, Baptiste Daroussin wrote: >> > On Fri 31 Jan 18:18, Guido Falsi wrote: > >> On 27/01/25 10:56, Nuno Teixeira wrote: > >>> Hello Rainer, > >>> > >>> > Wouldn't this be the right time to get Bapt@ involved? After = all, he has > >>> > worked intensively on the pkg updates. > >>> > >>> Yes it is. I'm CC'ing bapt@. > >> > >> Since this issue was pestering me while testing multiple ports with > >> unnecessarily lengthy rebuilds I took a look. > >> > >> I have posted a pull request for poudriere [1] with a = fix/workaround that > >> works for me and allows me to have a functional build machine. > >> > >> I'm not sure if this fix is completely correct, but maybe it can be = useful > >> to other people as a work around. > >> > >> > >> [1] https://github.com/freebsd/poudriere/pull/1204 > >> > >> --=20 > >> Guido Falsi <mad@madpilot.net> > >=20 > > at quick glance it sounds like a bug in pkg I ll have a look at it = next week > >=20 > > Bapt >=20 > It looks like the issue is related to this kind of pkg output: >=20 > > pkg query %b gcc13 > libubsan.so.1:32 > libubsan.so.1 > libstdc++.so.6:32 > libstdc++.so.6 > libquadmath.so.0:32 > libquadmath.so.0 > liblto_plugin.so > libitm.so.1:32 > libitm.so.1 > libgomp.so.1:32 > libgomp.so.1 > libgfortran.so.5:32 > libgfortran.so.5 > libgccjit.so.0 > libgcc_s.so.1:32 > libgcc_s.so.1 > libcp1plugin.so.0 > libcc1plugin.so.0 > libcc1.so.0 > libatomic.so.1:32 > libatomic.so.1 > libasan.so.8:32 > libasan.so.8 Is that related to amd64 (and powerpc64) having MULTILIB enabled for lang/gcc* 's and so building both 64-bit and 32-bit targets inside the same package?: # grep MULTIL /usr/ports/lang/gcc13/Makefile OPTIONS_DEFINE_amd64+=3D MULTILIB OPTIONS_DEFAULT_amd64+=3D MULTILIB OPTIONS_DEFINE_powerpc64+=3D MULTILIB #OPTIONS_DEFAULT_powerpc64+=3D MULTILIB # = https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D105010 MULTILIB_DESC=3D Build support for 32-bit and 64-bit targets MULTILIB_CONFIGURE_ENABLE=3D multilib .if (${ARCH} =3D=3D amd64 || ${ARCH} =3D=3D powerpc64) && = ${PORT_OPTIONS:MMULTILIB} If you do not need 32-bit on 64-bit, might disabling MULTILIB be sufficient? Note: I do not know why, but aarch64 does not get MULTILIB to also span armv7 (aarch32). So aarch64 might not have this problem being visible as stands. > the '*:32' lines confuse poudriere. >=20 > Posting this hoping this is helpful in fixing the issue. =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?38DA5A67-D8FF-4FC7-815F-552B2B9D36BF>