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 <unknown_procedure> () (gdb) backtrace #0 0xc0017cd8 in <unknown_procedure> () warning: Attempting to unwind past bad PC 0xc0017cd8 #1 0xc0027400 in <unknown_procedure> () #2 0xc0027400 in <unknown_procedure> () Error accessing memory address 0x3e7: Bad address.