For a few days now I noticed some programs not working, like "lzma" or "xz" from the "xz-utils". They segfault and "xz --help" says: $ /usr/bin/xz --help /usr/bin/xz: unrecognized option '--' /usr/bin/xz: Try `/usr/bin/xz --help' for more information. So I went to compile the original source, and the gdb(1) backtrace shows them to die in "_getopt_internal()". I thought my system to be inconsistent somehow, because a friend reports these programs working. I already re-installed the package. It gets its libs from archlinux package locations: $ ldd /usr/bin/xz linux-gate.so.1 => (0xb80a4000) liblzma.so.0 => /usr/lib/liblzma.so.0 (0xb806e000) libpthread.so.0 => /lib/libpthread.so.0 (0xb8056000) libc.so.6 => /lib/libc.so.6 (0xb7f0e000) /lib/ld-linux.so.2 (0xb80a5000) It is possibly a problem with getopt_long(). Most programs work(!), ie. I only noticed this with "xz", "lzma" and friends, both the packages and hand-compiled versions. I use the bash commandline all the time with many programs calling getopt_long(), they all work. Backtrace: (gdb) run Starting program: /home/src/bulk/lzma/xz/src/xz/xz Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. Reading symbols from system-supplied DSO at 0xb8069000...(no debugging symbols found)...done. Reading symbols from /lib/libpthread.so.0...(no debugging symbols found)...done. [Thread debugging using libthread_db enabled] Reading symbols from /lib/libc.so.6... (no debugging symbols found)...done. [New Thread 0xb7ef36c0 (LWP 32015)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb7ef36c0 (LWP 32015)] 0xb7fa84dc in _getopt_internal_r () from /lib/libc.so.6 (gdb) bt incomplete CFI data; unspecified registers (e.g., eax) at 0xb7fa838a...#0 0xb7fa84dc in _getopt_internal_r () from /lib/libc.so.6 #1 0xb7fa946e in _getopt_internal () from /lib/libc.so.6 #2 0xb7fa96b9 in getopt_long () from /lib/libc.so.6 #3 0x0804980d in parse_real () #4 0x08049a07 in args_parse () #5 0x0804b18e in main () $ pac o /lib/libc.so.6 /lib/libc.so.6 is owned by glibc 2.10.1-2 $ ll /lib/libc[.-]* 393476 -rwxr-xr-x 1 root root ? 1.6M 2009-05-23 05:54 /lib/libc-2.10.1.so* 393470 lrwxrwxrwx 1 root root ? 14 2009-05-23 05:54 /lib/libc.so.6 -> libc-2.10.1.so* Did somebody else observe something like this? I already searched the web ("_getopt_internal_r SIGSEGV"), but there's nothing specific, although other programs had problems like this years ago. Any pointers appreciated. clemens