[Top][All Lists]

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

[Octave-bug-tracker] [bug #30685] Segmentation fault in ./run-octave [si

From: Keith Godfrey
Subject: [Octave-bug-tracker] [bug #30685] Segmentation fault in ./run-octave [sigemptyset() in liboctinterp-3.3.52.so]
Date: Sat, 12 Mar 2011 18:20:31 +0000
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110302 Iceweasel/3.5.16 (like Firefox/3.5.16)

Follow-up Comment #30, bug #30685 (project octave):

I'd guess that gnulib is behaving properly - it provides a standard API w/
basic functionality (eg., 32 signal handlers instead of 1024 under current
debian/fedora) in a small and portable code base that can substitute when
equivalent OS-level calls aren't present. Gnulib data structures won't
necessarily be compatible w/ the OS versions, if the later are even present.

The problem would seem to be that the octave configuration system is allowing
calls to both gnulib and the OS libs (and headers). When adequate OS libs are
present, they should be used exclusively. When not, the gnulibs should be
called. Alternatively, always use the GNU libs and headers. The problem comes
when mixing the two.

On that note, I'd think that this bug should be re-targeted internally as a
configuration (or make) bug. 

As a workaround for those wishing to compile from scratch, putting an '#ifdef
NEVER' / #endif pair around the entirety of gnulib/sigprocmask.c, removing all
'gnulib::' from src/sighandlers.cc, and recompiling seemed to produce a stable
build, for as much as I've been able to test it at least.


Reply to this item at:


  Message sent via/by Savannah

reply via email to

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