4:25 a.m.
Hello,
it seems that both fakeroot and fakechroot fail to build in Fedora
rawhide (at least partially) because _STAT_VER is no longer declared
in the current glibc (or rather, its headers):
https://bugzilla.redhat.com/show_bug.cgi?id=1889862
https://bugzilla.redhat.com/show_bug.cgi?id=1901049
The bugzillas are filed against their respective components but
I wonder if we have any guidance from the glibc point of view about
how these components should proceed. Or is the loss of _STAT_VER an
omission and will it come back?
--
Jan Pazdziora
Product Owner, Platform Security Readiness, Red Hat
4:57 a.m.
* Jan Pazdziora:
it seems that both fakeroot and fakechroot fail to build in Fedora
rawhide (at least partially) because _STAT_VER is no longer declared
in the current glibc (or rather, its headers):
https://bugzilla.redhat.com/show_bug.cgi?id=1889862
https://bugzilla.redhat.com/show_bug.cgi?id=1901049
The bugzillas are filed against their respective components but
I wonder if we have any guidance from the glibc point of view about
how these components should proceed. Or is the loss of _STAT_VER an
omission and will it come back?
_STAT_VER will not come back, these packages have to define the value
locally. glibc won't add any _STAT_VER values.
There's a Fedora-specific hack in rawhide glibc to bring back the
__xstat and related symbols for linking. This in the process of being
upstreamed.
Thanks,
Florian
--
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
5:22 a.m.
On Wed, Nov 25, 2020 at 11:57:38AM +0100, Florian Weimer wrote:
* Jan Pazdziora:
> it seems that both fakeroot and fakechroot fail to build in Fedora
> rawhide (at least partially) because _STAT_VER is no longer declared
> in the current glibc (or rather, its headers):
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1889862
> https://bugzilla.redhat.com/show_bug.cgi?id=1901049
>
> The bugzillas are filed against their respective components but
> I wonder if we have any guidance from the glibc point of view about
> how these components should proceed. Or is the loss of _STAT_VER an
> omission and will it come back?
_STAT_VER will not come back, these packages have to define the value
locally. glibc won't add any _STAT_VER values.
Thank you.
So do you recommend for fakechroot to hardcode something like
--- a/src/libfakechroot.h
+++ b/src/libfakechroot.h
@@ -224,4 +224,14 @@ int fakechroot_try_cmd_subst (char *, const char *, char *);
int snprintf(char *, size_t, const char *, ...);
#endif
+#ifndef _STAT_VER
+#if defined (__aarch64__)
+#define _STAT_VER 0
+#elif defined (__x86_64__)
+#define _STAT_VER 1
+#else
+#define _STAT_VER 3
+#endif
+#endif
+
#endif
for all the arches?
There's a Fedora-specific hack in rawhide glibc to bring back
the
__xstat and related symbols for linking. This in the process of being
upstreamed.
Does that include __fxstatat64? And is the hack already in
glibc-2.32.9000-16.fc34 or is it on the way to rawhide?
--
Jan Pazdziora | adelton at #security, #brno
Product Owner, Platform Security Readiness, Red Hat
5:28 a.m.
* Jan Pazdziora:
So do you recommend for fakechroot to hardcode something like
--- a/src/libfakechroot.h
+++ b/src/libfakechroot.h
@@ -224,4 +224,14 @@ int fakechroot_try_cmd_subst (char *, const char *, char *);
int snprintf(char *, size_t, const char *, ...);
#endif
+#ifndef _STAT_VER
+#if defined (__aarch64__)
+#define _STAT_VER 0
+#elif defined (__x86_64__)
+#define _STAT_VER 1
+#else
+#define _STAT_VER 3
+#endif
+#endif
+
#endif
for all the arches?
Yes, the fakeroot case is really quite unusual, I think.
> There's a Fedora-specific hack in rawhide glibc to bring back
the
> __xstat and related symbols for linking. This in the process of being
> upstreamed.
Does that include __fxstatat64? And is the hack already in
glibc-2.32.9000-16.fc34 or is it on the way to rawhide?
Looking at the current rawhide buildroot, it's already there:
# eu-readelf --symbols=.dynsym /lib64/libc.so.6 | grep __fxstat64
1059: 00000000000f1880 84 FUNC GLOBAL DEFAULT 15 __fxstat64@(a)GLIBC_2.2.5
The @@ means it's available for linking.
It's missing from upstream right now, but we'll fix that before the
upstream release.
Thanks,
Florian
--
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
6:32 a.m.
On Fri, Nov 27, 2020 at 12:28:36PM +0100, Florian Weimer wrote:
* Jan Pazdziora:
>> There's a Fedora-specific hack in rawhide glibc to bring back the
>> __xstat and related symbols for linking. This in the process of being
>> upstreamed.
>
> Does that include __fxstatat64? And is the hack already in
> glibc-2.32.9000-16.fc34 or is it on the way to rawhide?
Looking at the current rawhide buildroot, it's already there:
# eu-readelf --symbols=.dynsym /lib64/libc.so.6 | grep __fxstat64
1059: 00000000000f1880 84 FUNC GLOBAL DEFAULT 15 __fxstat64@(a)GLIBC_2.2.5
The @@ means it's available for linking.
Nod, I see it there. What would you recommend to software that wants
to compile against these symbols?
--
Jan Pazdziora | adelton at #security, #brno
Product Owner, Platform Security Readiness, Red Hat
6:36 a.m.
On Fri, 2020-11-27 at 12:28 +0100, Florian Weimer wrote:
* Jan Pazdziora:
> So do you recommend for fakechroot to hardcode something like
>
> --- a/src/libfakechroot.h
> +++ b/src/libfakechroot.h
> @@ -224,4 +224,14 @@ int fakechroot_try_cmd_subst (char *, const
> char *, char *);
> int snprintf(char *, size_t, const char *, ...);
> #endif
>
> +#ifndef _STAT_VER
> +#if defined (__aarch64__)
> +#define _STAT_VER 0
> +#elif defined (__x86_64__)
> +#define _STAT_VER 1
> +#else
> +#define _STAT_VER 3
> +#endif
> +#endif
> +
> #endif
>
> for all the arches?
Yes, the fakeroot case is really quite unusual, I think.
I just fixed fakeroot build on F35 , but the same fix doesn't work for
F34 ?!?
https://bugzilla.redhat.com/show_bug.cgi?id=1889862#c16
> > There's a Fedora-specific hack in rawhide glibc to
bring back the
> > __xstat and related symbols for linking. This in the process of
> > being
> > upstreamed.
>
> Does that include __fxstatat64? And is the hack already in
> glibc-2.32.9000-16.fc34 or is it on the way to rawhide?
Looking at the current rawhide buildroot, it's already there:
# eu-readelf --symbols=.dynsym /lib64/libc.so.6 | grep __fxstat64
1059: 00000000000f1880 84 FUNC GLOBAL DEFAULT 15
__fxstat64@(a)GLIBC_2.2.5
The @@ means it's available for linking.
It's missing from upstream right now, but we'll fix that before the
upstream release.
Thanks,
Florian
--
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs,
Michael O'Neill
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Sérgio M. B.
1163
days inactive
1248
days old
5 comments
3 participants
participants (3)
-
Florian Weimer -
Jan Pazdziora -
Sérgio Basto