linuxconf seg faults in a VC on a Sparc 10.
stack trace is: #0 0x7851c in HELP_FILE::HELP_FILE () #1 0x50271d60 in global constructors keyed to pam_check_pass () at pam.cc:14 #2 0x50275d48 in __do_global_ctors_aux () #3 0x5026dfb8 in _init () #4 0x5022d7d4 in dl_open_worker (a=0xe4038) at dl-open.c:144 #5 0x5000ce44 in _dl_catch_error () at dl-error.c:99 #6 0x5022d968 in _dl_open () at dl-open.c:155 #7 0x500c10fc in dlopen_doit (a=0xefffc8f8) at dlopen.c:39 #8 0x5000ce44 in _dl_catch_error () at dl-error.c:99 #9 0x500c18e4 in _dlerror_run (operate=0x500c10c8 <dlopen_doit>, args=0xefffc8f8) at dlerror.c:122 #10 0x500c10b0 in __dlopen_check (file=0xefffcaa8 "/usr/lib/linuxconf/redhat/redhat.so.1.14.0", mode=258) at dlopen.c:50 #11 0x7b4c0 in module_loadcheck () #12 0x7b750 in module_loaddistmod () #13 0x32ef4 in main () #14 0x50173750 in __libc_start_main () at ../sysdeps/generic/libc-start.c:78 (gdb)
This smells like the setjmp/longjmp stuff in glibc we dealt with before. We need to verify that our patch to setjmp/longjmp survived the move to glibc 2.1, or alternatively that equivalent functionality was included in glibc 2.1
Fixed in linuxconf-1.14r4 -- linuxconf was making shared libraries out of code that was not compiled -fPIC. It's a bug on the sparc that not compiling -fPIC broke it, but it was also a bug in linuxconf not to compile -fPIC...