Daniel P. Berrangé wrote on 2021/10/29 21:15:
> On Fri, Oct 29, 2021 at 07:55:08AM -0400, Kaleb Keithley wrote:
> > On Fri, Oct 29, 2021 at 6:52 AM Richard W.M. Jones <rjones(a)redhat.com>
> > wrote:
> >
> > > On Thu, Oct 28, 2021 at 11:16:42AM -0400, Kaleb Keithley wrote:
> > > >
> > > > Perfect. Thank you Mamoru-san.
> > > >
> > > > armv7hl is now back in.
> > >
> > > glusterfs library is totally broken on armv7, aarch64, s390x at the
moment:
> > >
> >
> > Are you saying it wasn't broken on aarch64 and s390x before adding
Mamoru's
> > armv7hl fix? I.e. specifically 10.0-0.1rc0 ?
>
> I thought it was triggered by the introduction of libtcmalloc, but now
> I look back at the previuous libvirt build
>
>
https://koji.fedoraproject.org/koji/taskinfo?taskID=77969720
>
> glusterfs-10.0-0.1rc0.fc36
>
> was ok on aarch64 and s390x.
>
> so in fact I think it may well be that change of Mamoru that
> has somehow triggered increased static TLS usage and thus
> broken ability to dlopen libgluestfs.so
>
But my suggestion is only applied on armv7hl, not on aarch64 or s390x:
https://src.fedoraproject.org/rpms/glusterfs/c/8e29421e267d21194f9d7300c1...
So I don't think this is relevant. My guess is this is related to tcmalloc side.
The gperftools NEVR is the same in both builds, so I wonder what else
has changed that might cause it. I see changes in gcc, glibc, and
libatomic between the two glusterfs builds but not sure if any of
those are culprits
Regards,
Daniel
--
|: