Fedora/f35 compile error

[Carol Bouchard]

I'm seeing the following compile error in my product which I'm not seeing
with earlier versions of Fedora.











*make[4]: Entering directory
'/builddir/build/BUILD/restraint-0.3.2/third-party/m4-1.4.18/lib'  CC
gl_avltree_oset.o  CC       binary-io.o  CC       c-ctype.o  CC
c-stack.oIn file included from /usr/include/signal.h:315,
 from ./signal.h:52,                 from c-stack.c:49:c-stack.c:55:26:
error: missing binary operator before token "("   55 | #elif
HAVE_LIBSIGSEGV && SIGSTKSZ < 16384      |
 ^~~~~~~~*

In earlier fedora versions, SIGSTKSZ is a numeric value. In rawhide, I'm
seeing
the following in file /usr/include/bits/sigstksz.h.


*/* Default stack size for a signal handler: sysconf (SC_SIGSTKSZ).  */#
undef SIGSTKSZ# define SIGSTKSZ sysconf (_SC_SIGSTKSZ)*

This looks like an issue to be addressed in Fedora and not by applying a
patch.  Please advise.

Carol

[Daniel P. Berrangé]

On Wed, Mar 03, 2021 at 09:07:48AM -0500, Carol Bouchard wrote:
>  I'm seeing the following compile error in my product which
> I'm not seeing
>  with earlier versions of Fedora.
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  *make[4]: Entering directory
>  '/builddir/build/BUILD/restraint-0.3.2/third-party/m4-1.4.18/lib'  CC
>  gl_avltree_oset.o  CC       binary-io.o  CC       c-ctype.o  CC
>  c-stack.oIn file included from /usr/include/signal.h:315,
>   from ./signal.h:52,                 from c-stack.c:49:c-stack.c:55:26:
>  error: missing binary operator before token "("   55 | #elif
>  HAVE_LIBSIGSEGV && SIGSTKSZ < 16384      |
>   ^~~~~~~~*
>  
>  In earlier fedora versions, SIGSTKSZ is a numeric value. In rawhide, I'm
>  seeing
>  the following in file /usr/include/bits/sigstksz.h.
>  
>  
>  */* Default stack size for a signal handler: sysconf (SC_SIGSTKSZ).  */#
>  undef SIGSTKSZ# define SIGSTKSZ sysconf (_SC_SIGSTKSZ)*
>  
>  This looks like an issue to be addressed in Fedora and not by applying a
>  patch.  Please advise. 
The glibc change was intentionale and unavoidable per this previous
thread:

 
https://lists.fedoraproject.org/archives/list/[e-mail].o...

So you'll need to patch the application so that it doesn't make an
assumption that SIGSTKSZ evaluates to a static constant.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

[Richard W.M. Jones]

On Wed, Mar 03, 2021 at 02:24:35PM +0000, Daniel P. Berrangé wrote:
>  On Wed, Mar 03, 2021 at 09:07:48AM -0500, Carol Bouchard wrote:
>  > I'm seeing the following compile error in my product which I'm not seeing
>  > with earlier versions of Fedora.
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
>  > *make[4]: Entering directory
>  > '/builddir/build/BUILD/restraint-0.3.2/third-party/m4-1.4.18/lib'  CC
>  > gl_avltree_oset.o  CC       binary-io.o  CC       c-ctype.o  CC
>  > c-stack.oIn file included from /usr/include/signal.h:315,
>  >  from ./signal.h:52,                 from c-stack.c:49:c-stack.c:55:26:
>  > error: missing binary operator before token "("   55 | #elif
>  > HAVE_LIBSIGSEGV && SIGSTKSZ < 16384      |
>  >  ^~~~~~~~*
>  > 
>  > In earlier fedora versions, SIGSTKSZ is a numeric value. In rawhide, I'm
>  > seeing
>  > the following in file /usr/include/bits/sigstksz.h.
>  > 
>  > 
>  > */* Default stack size for a signal handler: sysconf (SC_SIGSTKSZ).  */#
>  > undef SIGSTKSZ# define SIGSTKSZ sysconf (_SC_SIGSTKSZ)*
>  > 
>  > This looks like an issue to be addressed in Fedora and not by applying a
>  > patch.  Please advise.
>  
>  The glibc change was intentionale and unavoidable per this previous
>  thread:
>  
>   
> https://lists.fedoraproject.org/archives/list/[e-mail].o...
>  
>  So you'll need to patch the application so that it doesn't make an
>  assumption that SIGSTKSZ evaluates to a static constant. 
FWIW these were the two proposed fixes for this in OCaml (the second
one was accepted).  Not too bad, you just have to be aware that the
structure can no longer be statically allocated:

https://pagure.io/fedora-ocaml/c/dfb5e954a04f59b0456cc4c0ddf3acaf22e0ff07...

https://github.com/ocaml/ocaml/pull/10266/files

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html

[Carol Bouchard]

Thank you Daniel and Richard.  I'm going to have to study this some to
understand how this solves the compile issue cause the glibc code isn't
gone.  It's still there.

Carol

On Wed, Mar 3, 2021 at 11:31 AM Richard W.M. Jones <rjones(a)redhat.com&gt;
wrote:

>  On Wed, Mar 03, 2021 at 02:24:35PM +0000, Daniel P. Berrangé wrote:
>  > On Wed, Mar 03, 2021 at 09:07:48AM -0500, Carol Bouchard wrote:
>  > > I'm seeing the following compile error in my product which I'm not
>  seeing
>  > > with earlier versions of Fedora.
>  > >
>  > >
>  > >
>  > >
>  > >
>  > >
>  > >
>  > >
>  > >
>  > >
>  > >
>  > > *make[4]: Entering directory
>  > > '/builddir/build/BUILD/restraint-0.3.2/third-party/m4-1.4.18/lib'  CC
>  > > gl_avltree_oset.o  CC       binary-io.o  CC       c-ctype.o  CC
>  > > c-stack.oIn file included from /usr/include/signal.h:315,
>  > >  from ./signal.h:52,                 from c-stack.c:49:c-stack.c:55:26:
>  > > error: missing binary operator before token "("   55 | #elif
>  > > HAVE_LIBSIGSEGV && SIGSTKSZ < 16384      |
>  > >  ^~~~~~~~*
>  > >
>  > > In earlier fedora versions, SIGSTKSZ is a numeric value. In rawhide,
>  I'm
>  > > seeing
>  > > the following in file /usr/include/bits/sigstksz.h.
>  > >
>  > >
>  > > */* Default stack size for a signal handler: sysconf (SC_SIGSTKSZ).
>  */#
>  > > undef SIGSTKSZ# define SIGSTKSZ sysconf (_SC_SIGSTKSZ)*
>  > >
>  > > This looks like an issue to be addressed in Fedora and not by applying
>  a
>  > > patch.  Please advise.
>  >
>  > The glibc change was intentionale and unavoidable per this previous
>  > thread:
>  >
>  >
>
> https://lists.fedoraproject.org/archives/list/[e-mail].o...
>  >
>  > So you'll need to patch the application so that it doesn't make an
>  > assumption that SIGSTKSZ evaluates to a static constant.
>
>  FWIW these were the two proposed fixes for this in OCaml (the second
>  one was accepted).  Not too bad, you just have to be aware that the
>  structure can no longer be statically allocated:
>
>
>
> https://pagure.io/fedora-ocaml/c/dfb5e954a04f59b0456cc4c0ddf3acaf22e0ff07...
>
>  https://github.com/ocaml/ocaml/pull/10266/files
>
>  Rich.
>
>  --
>  Richard Jones, Virtualization Group, Red Hat
>  http://people.redhat.com/~rjones
>  Read my programming and virtualization blog: http://rwmj.wordpress.com
>  virt-builder quickly builds VMs from scratch
>  http://libguestfs.org/virt-builder.1.html
>  _______________________________________________
>  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/[e-mail]
>  Do not reply to spam on the list, report it:
>  https://pagure.io/fedora-infrastructure
>

[Florian Weimer]

* Carol Bouchard:

>  Thank you Daniel and Richard.  I'm going to have to study this
> some to
>  understand how this solves the compile issue cause the glibc code
>  isn't gone.  It's still there. 
SIGSTKSZ is no longer a (preprocessor) constant.  If you use it in place
where a variable is expected, it works.  But you can't use it in
preprocessor conditionals anymore.

Thanks,
Florian

[Carol Bouchard]

In our code base (restraint), we patch and recompile the m4 code base.
https://github.com/tar-mirror/gnu-m4
In their code, they have the following which fails to compile when SIGSTKSZ
< 16384 is interpreted.
This is going to be a challenge to make work.

# define SIGSTKSZ 8192
#ifndef SIGSTKSZ
# define SIGSTKSZ 16384
#elif HAVE_LIBSIGSEGV && SIGSTKSZ < 16384
/* libsigsegv 2.6 through 2.8 have a bug where some architectures use
   more than the Linux default of an 8k alternate stack when deciding
   if a fault was caused by stack overflow.  */
# undef SIGSTKSZ
# define SIGSTKSZ 16384
#endif

On Wed, Mar 3, 2021 at 3:05 PM Florian Weimer <fweimer(a)redhat.com&gt; wrote:

>  * Carol Bouchard:
>
>  > Thank you Daniel and Richard.  I'm going to have to study this some to
>  > understand how this solves the compile issue cause the glibc code
>  > isn't gone.  It's still there.
>
>  SIGSTKSZ is no longer a (preprocessor) constant.  If you use it in place
>  where a variable is expected, it works.  But you can't use it in
>  preprocessor conditionals anymore.
>
>  Thanks,
>  Florian
>
>

[Daniel P. Berrangé]

On Wed, Mar 03, 2021 at 03:13:29PM -0500, Carol Bouchard wrote:
>  In our code base (restraint), we patch and recompile the m4 code
> base.
>  https://github.com/tar-mirror/gnu-m4
>  In their code, they have the following which fails to compile when SIGSTKSZ
>  < 16384 is interpreted.
>  This is going to be a challenge to make work.
>  
>  # define SIGSTKSZ 8192
>  #ifndef SIGSTKSZ
>  # define SIGSTKSZ 16384
>  #elif HAVE_LIBSIGSEGV && SIGSTKSZ < 16384
>  /* libsigsegv 2.6 through 2.8 have a bug where some architectures use
>     more than the Linux default of an 8k alternate stack when deciding
>     if a fault was caused by stack overflow.  */
>  # undef SIGSTKSZ
>  # define SIGSTKSZ 16384
>  #endif 
AFAICT libsigsegv 2.8 is a release dating from 2009, obsoleted by the
2.9 release in 2010.

I'd question whether this code really need to workaround a bug in
something that is 11 years old.

IOW, I'd suggest just deleting this hack entirely.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

[Carol Bouchard]

Thank you.  I may very well do that.

Carol

On Thu, Mar 4, 2021 at 4:57 AM Daniel P. Berrangé <berrange(a)redhat.com&gt;
wrote:

>  On Wed, Mar 03, 2021 at 03:13:29PM -0500, Carol Bouchard wrote:
>  > In our code base (restraint), we patch and recompile the m4 code base.
>  > https://github.com/tar-mirror/gnu-m4
>  > In their code, they have the following which fails to compile when
>  SIGSTKSZ
>  > < 16384 is interpreted.
>  > This is going to be a challenge to make work.
>  >
>  > # define SIGSTKSZ 8192
>  > #ifndef SIGSTKSZ
>  > # define SIGSTKSZ 16384
>  > #elif HAVE_LIBSIGSEGV && SIGSTKSZ < 16384
>  > /* libsigsegv 2.6 through 2.8 have a bug where some architectures use
>  >    more than the Linux default of an 8k alternate stack when deciding
>  >    if a fault was caused by stack overflow.  */
>  > # undef SIGSTKSZ
>  > # define SIGSTKSZ 16384
>  > #endif
>
>  AFAICT libsigsegv 2.8 is a release dating from 2009, obsoleted by the
>  2.9 release in 2010.
>
>  I'd question whether this code really need to workaround a bug in
>  something that is 11 years old.
>
>  IOW, I'd suggest just deleting this hack entirely.
>
>
>  Regards,
>  Daniel
>  --
>  |: https://berrange.com      -o-
>  https://www.flickr.com/photos/dberrange :|
>  |: https://libvirt.org         -o-
>  https://fstop138.berrange.com :|
>  |: https://entangle-photo.org    -o-
>  https://www.instagram.com/dberrange :|
>
>

[Carol Bouchard]

It's going to require more than removing the hack due to the following:

/* Storage for the alternate signal stack.  */
static union
{
  char buffer[SIGSTKSZ];

  /* These other members are for proper alignment.  There's no
     standard way to guarantee stack alignment, but this seems enough
     in practice.  */
  long double ld;
  long l;
  void *p;
} alternate_signal_stack;

On Thu, Mar 4, 2021 at 6:48 AM Carol Bouchard <cbouchar(a)redhat.com&gt; wrote:

>  Thank you.  I may very well do that.
>
>  Carol
>
>  On Thu, Mar 4, 2021 at 4:57 AM Daniel P. Berrangé <berrange(a)redhat.com&gt;
>  wrote:
>
> > On Wed, Mar 03, 2021 at 03:13:29PM -0500, Carol Bouchard wrote:
> > > In our code base (restraint), we patch and recompile the m4 code base.
> > > https://github.com/tar-mirror/gnu-m4
> > > In their code, they have the following which fails to compile when
> > SIGSTKSZ
> > > < 16384 is interpreted.
> > > This is going to be a challenge to make work.
> > >
> > > # define SIGSTKSZ 8192
> > > #ifndef SIGSTKSZ
> > > # define SIGSTKSZ 16384
> > > #elif HAVE_LIBSIGSEGV && SIGSTKSZ < 16384
> > > /* libsigsegv 2.6 through 2.8 have a bug where some architectures use
> > >    more than the Linux default of an 8k alternate stack when deciding
> > >    if a fault was caused by stack overflow.  */
> > > # undef SIGSTKSZ
> > > # define SIGSTKSZ 16384
> > > #endif
> >
> > AFAICT libsigsegv 2.8 is a release dating from 2009, obsoleted by the
> > 2.9 release in 2010.
> >
> > I'd question whether this code really need to workaround a bug in
> > something that is 11 years old.
> >
> > IOW, I'd suggest just deleting this hack entirely.
> >
> >
> > Regards,
> > Daniel
> > --
> > |: https://berrange.com      -o-
> > https://www.flickr.com/photos/dberrange :|
> > |: https://libvirt.org         -o-
> > https://fstop138.berrange.com :|
> > |: https://entangle-photo.org    -o-
> > https://www.instagram.com/dberrange :|
> >
> >

[Carol Bouchard]

I'm going to reach out to glib team.  I wished all I had to do is remove
their preprocessor code but I don't think it is that simple.
I much appreciate your help on this issue.

Carol

On Thu, Mar 4, 2021 at 7:02 AM Carol Bouchard <cbouchar(a)redhat.com&gt; wrote:

>  It's going to require more than removing the hack due to the
> following:
>
>  /* Storage for the alternate signal stack.  */
>  static union
>  {
>    char buffer[SIGSTKSZ];
>
>    /* These other members are for proper alignment.  There's no
>       standard way to guarantee stack alignment, but this seems enough
>       in practice.  */
>    long double ld;
>    long l;
>    void *p;
>  } alternate_signal_stack;
>
>  On Thu, Mar 4, 2021 at 6:48 AM Carol Bouchard <cbouchar(a)redhat.com&gt; wrote:
>
> > Thank you.  I may very well do that.
> >
> > Carol
> >
> > On Thu, Mar 4, 2021 at 4:57 AM Daniel P. Berrangé <berrange(a)redhat.com&gt;
> > wrote:
> >
> >> On Wed, Mar 03, 2021 at 03:13:29PM -0500, Carol Bouchard wrote:
> >> > In our code base (restraint), we patch and recompile the m4 code base.
> >> > https://github.com/tar-mirror/gnu-m4
> >> > In their code, they have the following which fails to compile when
> >> SIGSTKSZ
> >> > < 16384 is interpreted.
> >> > This is going to be a challenge to make work.
> >> >
> >> > # define SIGSTKSZ 8192
> >> > #ifndef SIGSTKSZ
> >> > # define SIGSTKSZ 16384
> >> > #elif HAVE_LIBSIGSEGV && SIGSTKSZ < 16384
> >> > /* libsigsegv 2.6 through 2.8 have a bug where some architectures use
> >> >    more than the Linux default of an 8k alternate stack when deciding
> >> >    if a fault was caused by stack overflow.  */
> >> > # undef SIGSTKSZ
> >> > # define SIGSTKSZ 16384
> >> > #endif
> >>
> >> AFAICT libsigsegv 2.8 is a release dating from 2009, obsoleted by the
> >> 2.9 release in 2010.
> >>
> >> I'd question whether this code really need to workaround a bug in
> >> something that is 11 years old.
> >>
> >> IOW, I'd suggest just deleting this hack entirely.
> >>
> >>
> >> Regards,
> >> Daniel
> >> --
> >> |: https://berrange.com      -o-
> >> https://www.flickr.com/photos/dberrange :|
> >> |: https://libvirt.org         -o-
> >> https://fstop138.berrange.com :|
> >> |: https://entangle-photo.org    -o-
> >> https://www.instagram.com/dberrange :|
> >>
> >>

[Daniel P. Berrangé]

On Thu, Mar 04, 2021 at 07:02:27AM -0500, Carol Bouchard wrote:
>  It's going to require more than removing the hack due to the
> following:
>  
>  /* Storage for the alternate signal stack.  */
>  static union
>  {
>    char buffer[SIGSTKSZ];
>  
>    /* These other members are for proper alignment.  There's no
>       standard way to guarantee stack alignment, but this seems enough
>       in practice.  */
>    long double ld;
>    long l;
>    void *p;
>  } alternate_signal_stack; 
A "simple" option is to just stop using SIGSTKSZ here, and define
your own constant - pick it based on worst case real world SIGSTKSZ
that you'll expect. Perhaps stick in an assert in the code too, to
abort the process at runtime if the real value is larger.

A alternative solution is to stop statically allocating the
struct and instead malloc it at startup. If there's no convenient
place todo the alloc, you could possibly use an __attribute__(constructor)
function that will get invoked by the dyn loader at startup for you,
before main() even runs.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

[Carol Bouchard]

Hi Daniel and other Fedora experts:

I'm trying to get the m4 package to change their code.  They're saying this
is not POSIX
compliant change so they are resisting.  See below snippet.  I don't have
the
background to this change to answer their questions. Is someone with this
background willing to jump onto the email thread to move forward with this?
Let me know and I'll add you to the thread.  Also I told them it's not a
glib
change only that Fedora is also moving in this direction but my comments
got lost in the thread.

>  > I can open a defect against POSIX if we decide that is needed,
> but want
>  > some consensus first on whether it is glibc's change that went too far,
>  > or POSIX's requirements that are too restrictive for what glibc wants 
to
do.
>  Here are a couple of questions, to understand the motivation and the
possible
>  alternative solutions to the problem:
>
>  1) As far as I understand, the issue occurs with certain x86 or x86_64
>     processors.
>
>     1.1) What has been the value of MINSIGSTKSZ on x86 and x86_64 so far?
>     1.2) What value of MINSIGSTKSZ is needed for AVX-512F support?
>     1.3) Will the trend to larger MINSIGSTKSZ values continue for Intel
>          processors? 
On Thu, Mar 4, 2021 at 8:04 AM Daniel P. Berrangé <berrange(a)redhat.com&gt;
wrote:

>  On Thu, Mar 04, 2021 at 07:02:27AM -0500, Carol Bouchard wrote:
>  > It's going to require more than removing the hack due to the following:
>  >
>  > /* Storage for the alternate signal stack.  */
>  > static union
>  > {
>  >   char buffer[SIGSTKSZ];
>  >
>  >   /* These other members are for proper alignment.  There's no
>  >      standard way to guarantee stack alignment, but this seems enough
>  >      in practice.  */
>  >   long double ld;
>  >   long l;
>  >   void *p;
>  > } alternate_signal_stack;
>
>  A "simple" option is to just stop using SIGSTKSZ here, and define
>  your own constant - pick it based on worst case real world SIGSTKSZ
>  that you'll expect. Perhaps stick in an assert in the code too, to
>  abort the process at runtime if the real value is larger.
>
>  A alternative solution is to stop statically allocating the
>  struct and instead malloc it at startup. If there's no convenient
>  place todo the alloc, you could possibly use an __attribute__(constructor)
>  function that will get invoked by the dyn loader at startup for you,
>  before main() even runs.
>
>  Regards,
>  Daniel
>  --
>  |: https://berrange.com      -o-
>  https://www.flickr.com/photos/dberrange :|
>  |: https://libvirt.org         -o-
>  https://fstop138.berrange.com :|
>  |: https://entangle-photo.org    -o-
>  https://www.instagram.com/dberrange :|
>
>

[Daniel P. Berrangé]

On Mon, Mar 15, 2021 at 09:50:18AM -0400, Carol Bouchard wrote:
>  Hi Daniel and other Fedora experts:
>  
>  I'm trying to get the m4 package to change their code.  They're saying this
>  is not POSIX
>  compliant change so they are resisting.  See below snippet.  I don't have
>  the
>  background to this change to answer their questions. Is someone with this
>  background willing to jump onto the email thread to move forward with this?
>  Let me know and I'll add you to the thread.  Also I told them it's not a
>  glib
>  change only that Fedora is also moving in this direction but my comments
>  got lost in the thread. 
Looking at this thread:

  https://lists.gnu.org/archive/html/bug-m4/2021-03/msg00000.html

it appears that all the right people I'd expect are already involved
in the discussion from the GLibC / Gnulib side.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

[Carol Bouchard]

Since Fedora is also making the change, I'm wondering whether this voice
should also
be heard.  They're assuming it's just GLib.

Carol

On Mon, Mar 15, 2021 at 10:09 AM Daniel P. Berrangé <berrange(a)redhat.com&gt;
wrote:

>  On Mon, Mar 15, 2021 at 09:50:18AM -0400, Carol Bouchard wrote:
>  > Hi Daniel and other Fedora experts:
>  >
>  > I'm trying to get the m4 package to change their code.  They're saying
>  this
>  > is not POSIX
>  > compliant change so they are resisting.  See below snippet.  I don't have
>  > the
>  > background to this change to answer their questions. Is someone with this
>  > background willing to jump onto the email thread to move forward with
>  this?
>  > Let me know and I'll add you to the thread.  Also I told them it's not a
>  > glib
>  > change only that Fedora is also moving in this direction but my comments
>  > got lost in the thread.
>
>  Looking at this thread:
>
>    https://lists.gnu.org/archive/html/bug-m4/2021-03/msg00000.html
>
>  it appears that all the right people I'd expect are already involved
>  in the discussion from the GLibC / Gnulib side.
>
>  Regards,
>  Daniel
>  --
>  |: https://berrange.com      -o-
>  https://www.flickr.com/photos/dberrange :|
>  |: https://libvirt.org         -o-
>  https://fstop138.berrange.com :|
>  |: https://entangle-photo.org    -o-
>  https://www.instagram.com/dberrange :|
>
>

[Daniel P. Berrangé]

On Mon, Mar 15, 2021 at 10:16:58AM -0400, Carol Bouchard wrote:
>  Since Fedora is also making the change, I'm wondering whether
> this voice
>  should also
>  be heard.  They're assuming it's just GLib. 
Fedora isn't making a change on its own. Fedora has simply pulled in
the latest version of GLibC that contains the change. It will affect
any distro which subsequently pulls in this GLibC code, which is
pretty much all of them eventually.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

[Carol Bouchard]

Thank you for the details Daniel!

On Mon, Mar 15, 2021 at 10:22 AM Daniel P. Berrangé <berrange(a)redhat.com&gt;
wrote:

>  On Mon, Mar 15, 2021 at 10:16:58AM -0400, Carol Bouchard wrote:
>  > Since Fedora is also making the change, I'm wondering whether this voice
>  > should also
>  > be heard.  They're assuming it's just GLib.
>
>  Fedora isn't making a change on its own. Fedora has simply pulled in
>  the latest version of GLibC that contains the change. It will affect
>  any distro which subsequently pulls in this GLibC code, which is
>  pretty much all of them eventually.
>
>  Regards,
>  Daniel
>  --
>  |: https://berrange.com      -o-
>  https://www.flickr.com/photos/dberrange :|
>  |: https://libvirt.org         -o-
>  https://fstop138.berrange.com :|
>  |: https://entangle-photo.org    -o-
>  https://www.instagram.com/dberrange :|
>
>

[Christoph Karl]

Hello!

On 03.03.21 at 15:07 Carol Bouchard wrote:
>  */* Default stack size for a signal handler: sysconf (SC_SIGSTKSZ). 
> */#
>  undef SIGSTKSZ# define SIGSTKSZ sysconf (_SC_SIGSTKSZ)* 
Same for package rcs.
(Detected by upcoming autoconf-2.71 copr build.)

Christoph