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
_
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 GL
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 th
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 expe
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 thi
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
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'
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
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
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
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
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
# de
* 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
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é
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.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
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.
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 i
17 matches
Mail list logo
