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@xxxxxxxxxx> 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@xxxxxxxxxx> wrote:Thank you. I may very well do that.CarolOn Thu, Mar 4, 2021 at 4:57 AM Daniel P. Berrangé <berrange@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure