[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: sigprocmask.c appears to be incompatible w/ system headers

From: Bruno Haible
Subject: Re: sigprocmask.c appears to be incompatible w/ system headers
Date: Tue, 15 Mar 2011 02:09:50 +0100
User-agent: KMail/1.9.9

Godfrey, Keith wrote:
> Output of the commands are attached

In make.txt you have this command:

/bin/sh ../libtool --tag=CC   --mode=link gcc  -g -O2 -pthread  -no-undefined  
-lm     -lm -lm -lm -lm -L/global/home/keith/lib -o libgnu.la  c-ctype.lo 
c-strcasecmp.lo c-strncasecmp.lo close-hook.lo exitfail.lo localcharset.lo 
malloca.lo openat-die.lo progname.lo sockets.lo strnlen1.lo asnprintf.lo 
basename-lgpl.lo chdir-long.lo cloexec.lo dirname-lgpl.lo dup-safer.lo fcntl.lo 
fd-safer.lo filemode.lo getcwd.lo getopt.lo getopt1.lo glob.lo md5.lo 
nanosleep.lo openat-proc.lo pipe-safer.lo printf-args.lo printf-parse.lo 
save-cwd.lo strftime.lo stripslash.lo tempname.lo vasnprintf.lo  -lm  

There is no sigprocmask.lo in this list. This is normal; gnulib's sigprocmask.c
is not compiled on glibc systems. You can see from the gnulib documentation
that this source file is only compiled on mingw platforms.

Also, the generated signal.h is built with HAVE_SIGSET_T being replaced with 1,
therefore it does not redefine the 'sigset_t' type.

In <https://savannah.gnu.org/bugs/?30685> you write:
> A change (similar to Leonardo's) that seems to work while theoretically 
> maintaining sigaction
> functionality is to explicitly call the sigemptyset macro (bits/sigset.h):  
> octave-3.4.0/src/sighandlers.cc line 225 
>  //gnulib::sigemptyset (&act.sa_mask); 
>  //gnulib::sigemptyset (&oact.sa_mask); 
>  //gnulib::sigaction (sig, &act, &oact); 
>  __sigemptyset (&act.sa_mask); 
>  __sigemptyset (&oact.sa_mask); 
>  sigaction (sig, &act, &oact); 
> (only removing the namespace didn't work for me either) 

This indicates that the crucial difference is between the __sigemptyset
macro and the sigemptyset functions, both from glibc.

Or if 'sigemptyset' would work fine, then the crucial difference would
be in the function pointer indirection by which gnulib implements the
'gnulib::sigemptyset' function in term of the 'sigemptyset' function

In order to debug this, I would recommend to look at

  - the source code of the __sigemptyset macro and of the sigemptyset

  - the assembly level instructions where it crashes:

     #0  0xb785896c in sigemptyset () from 

    because it's not clear why liboctinterp-3.3.53.so would contain
    a sigemptyset function at all (since gnulib's one is not being

  - the preprocessed source file (g++ -E -dD) of the compilation unit
    that contains the gnulib::sigemptyset invocation.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]