Re: poudriere loop: llvm19-19.1.7: missed shlib PORTREVISION chase

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
> >>
> >> -- 
> >> Guido Falsi <mad@madpilot.net>
> > 
> > at quick glance it sounds like a bug in pkg I ll have a look at it next week
> > 
> > Bapt
> 
> It looks like the issue is related to this kind of pkg output:
> 
> > 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+= MULTILIB
OPTIONS_DEFAULT_amd64+= MULTILIB
OPTIONS_DEFINE_powerpc64+= MULTILIB
#OPTIONS_DEFAULT_powerpc64+= MULTILIB # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105010
MULTILIB_DESC= Build support for 32-bit and 64-bit targets
MULTILIB_CONFIGURE_ENABLE= multilib
.if (${ARCH} == amd64 || ${ARCH} == 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.
> 
> Posting this hoping this is helpful in fixing the issue.


===
Mark Millard
marklmi at yahoo.com