Re: poudriere loop: llvm19-19.1.7: missed shlib PORTREVISION chase
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 at quick glance it sounds like a bug in pkg I ll have a look at it next week Bapt
Re: poudriere loop: llvm19-19.1.7: missed shlib PORTREVISION chase
Guido Falsi 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
> >
> > 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
Re: poudriere loop: llvm19-19.1.7: missed shlib PORTREVISION chase
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
Re: poudriere loop: llvm19-19.1.7: missed shlib PORTREVISION chase
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 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 the '*:32' lines confuse poudriere. Posting this hoping this is helpful in fixing the issue. -- Guido Falsi
