Re: Fedora/f35 compile error
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora/f35 compile error
Thank you for the details Daniel! On Mon, Mar 15, 2021 at 10:22 AM Daniel P. Berrangé 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 :| > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora/f35 compile error
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 :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora/f35 compile error
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é 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/msg0.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 :| > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora/f35 compile error
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/msg0.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 :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora/f35 compile error
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é
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 :|
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Fedora/f35 compile error
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 :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Fedora/f35 compile error
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 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 wrote:
>
>> Thank you. I may very well do that.
>>
>> Carol
>>
>> On Thu, Mar 4, 2021 at 4:57 AM Daniel P. Berrangé
>> 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 :|
>>>
>>>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Fedora/f35 compile error
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 wrote:
> Thank you. I may very well do that.
>
> Carol
>
> On Thu, Mar 4, 2021 at 4:57 AM Daniel P. Berrangé
> 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 :|
>>
>>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Fedora/f35 compile error
Thank you. I may very well do that. Carol On Thu, Mar 4, 2021 at 4:57 AM Daniel P. Berrangé 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 :| > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora/f35 compile error
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 :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora/f35 compile error
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 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 > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora/f35 compile error
* 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora/f35 compile error
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
wrote:
> On Wed, Mar 03, 2021 at 02:24:35PM +, 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/devel@lists.fedoraproject.org/thread/BR5DU2NSKRZAJHEUWOI4H6ZIQQNVAXAR/#JAEAW2T2YSEIRSB62ESBDLL62OBUSLXU
> >
> > 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?branch=fedora-35-4.12.0
>
> 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@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Fedora/f35 compile error
On Wed, Mar 03, 2021 at 02:24:35PM +, 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/devel@lists.fedoraproject.org/thread/BR5DU2NSKRZAJHEUWOI4H6ZIQQNVAXAR/#JAEAW2T2YSEIRSB62ESBDLL62OBUSLXU
>
> 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?branch=fedora-35-4.12.0
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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Fedora/f35 compile error
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/devel@lists.fedoraproject.org/thread/BR5DU2NSKRZAJHEUWOI4H6ZIQQNVAXAR/#JAEAW2T2YSEIRSB62ESBDLL62OBUSLXU
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 :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Fedora/f35 compile error
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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
