Hi, Strange - the segmentation fault disappears if I link with the debug-version of libboost_signals (-lboost_signals-gcc-d-1_33_1)! It seams to me that some assert statements contain required code (removed in release version if signals)?!
I get an segmentation fault if I try to link against libboost_signals-gcc-1_33_1 or libboost_signals-gcc-mt-1_33_1! The application consist only of an empty main function and the binary is linked against the signals library. I've appended an output (tusc.out) of tusc (trace unix system calls) which indicates, that exit(11) is called and so a core dump created.
Can you run the program under gdb debugger, and when hittin segfault produce backtrace with the "backtrace" command. That will be more usefull, in any case, then syscall trace.
I'm not familiar with gdb! What I did (hopefully correct):
[src]$ /opt/langtools/bin/gdb32 test
HP gdb 5.2 for PA-RISC 1.1 or 2.0 (narrow), HP-UX 11.00
and target hppa1.1-hp-hpux11.00.
Copyright 1986 - 2001 Free Software Foundation, Inc.
Hewlett-Packard Wildebeest 5.2 (based on GDB) is covered by the
GNU General Public License. Type "show copying" to see the conditions to
change it and/or distribute copies. Type "show warranty" for
warranty/support.
..
(gdb) run
Starting program: /eda-home/kowalke/Projects/test/debug/src/test
Program received signal SIGSEGV, Segmentation fault
si_code: 0 - SEGV_UNKNOWN - Unknown Error.
0xc0017cd8 in