Problem with m4 in 2.3.6

Panos Maheras arcana at
Mon Jul 24 02:22:03 PDT 2000

I wrote:

>> gcc  -o m4 m4.o builtin.o debug.o eval.o format.o freeze.o input.o macro.o
>> output.o path.o stackovf.o symtab.o ../lib/libm4.a
>> stackovf.o: In function `setup_stackovf_trap':
>> /usr/src/m4-1.4/src/stackovf.c:343: the `sigstack' function is dangerous. 
>> `sigaltstack' should be used instead.

John Phillips added:

>A few of us get this problem (reason unknown).  My fix is to compile
>m4 statically before the "chroot" and then re-compile properly after
>autoconf and automake.

This seems the only workable solution to the problem right now. Those 'few of
us' happen by any chance to install LFS over a glibc 2.0 system (mine is Debian
2.1)?? After many *many* tests I'm beginning to think that it's a problem with
glibc. Let me explain:

The sigstack function is supposedly taken from siginfo.h from the kernel
headers, but guess what? The configure script DOESN'T find it (it says something
like checking for siginfo.h.... No). There are two siginfo.h files under the
/usr/include directory of the LFS system. One is: asm/siginfo.h (from the
kernel) the other is: bits/siginfo.h (from the glibc).

Now, get this: if I copy siginfo.h from /usr/include/asm to /usr/include the
configure script from m4 FINDS this file (checking for siginfo.h.... Yes) BUT
during the make step it conflicts with the /usr/include/bits/siginfo.h which has
the sigstack function defined differently and make stops. If I move
/usr/include/bits/siginfo.h to /usr/include then the configure script again
doesn't find siginfo.h. Weird??

The file from m4 that causes this problem: /src/stackovf.c says that it doesn't
matter if your system has siginfo.h or not and that it should compile anyway.
(and the package is installed without problems on a Debian 2.1 system which
doesn't have siginfo.h either statically or dynamically).

Gerard Beekmans said:

>It might have to do how the base system was installed, at least that's
>my 'educated' guess. I can't reproduce the error so I find it hard to
>test these things.

Again I'm asking anyone who has that problem: do you install LFS from a glibc
2.0 system?

>What you can try is this:
>When compiling m4 it tells you that the sigalstack function is dangerous
>and some other functions must be used. You can edit that source file and
>rename sigalstack by that other recommended function name. That way you
>might end up with a working M4 binary. If it works, let us know so I can
>update the book on this issue.

I've tried that and it didn't work because the other function (sigaltstack) does
not implement some member functions that sigstack does and when I execute make
it stops.

Balu added:

>This sounds like a libsafe or something similar to me - is something
>like this installed?

To tell you the truth I don't know. The base system is a Debian 2.1 with only
the basic packages installed plus whatever else is needed (autoconf, automake,

If this turns out to be a glibc 2.0 problem *maybe* we should follow what John
Phillips suggested: compile statically before and dynamically after (this seems
to work right now).

Take care,
Panos Maheras (arcana at

Mail archive:
IRC access: server: port: 6667 channel: #LFS
Unsubscribe: email lfs-discuss-request at and put
"unsubscribe" (without the quotation marks) in the body of the message
(no subject is required)

More information about the lfs-dev mailing list