On Thu, Dec 22, 2005 at 10:21:52PM -0800, Steve Langasek wrote: > Break on rrd_graph_options, step into getopt_long, run bt to see what lib it > says it's in. Well, I should tell it earlier. It looks like getopt_long comes from glibc, backtrace follows.
Breakpoint 1, 0xb7d085b6 in getopt_long () from /lib/tls/i686/cmov/libc.so.6 (gdb) bt #0 0xb7d085b6 in getopt_long () from /lib/tls/i686/cmov/libc.so.6 #1 0xb78d839c in rrd_graph_options () from /usr/lib/librrd.so.2 #2 0xb78d8fda in rrd_graph () from /usr/lib/librrd.so.2 #3 0xb7c1e64b in zif_rrd_graph () from /usr/lib/php4/20050606/rrdtool.so #4 0xb72bbe82 in execute () from /usr/lib/apache/1.3/libphp4.so #5 0xb72a27f5 in zend_execute_scripts () from /usr/lib/apache/1.3/libphp4.so That does not bring me any closer to the solution. Especially because the example from my previous e-mail works correctly with exactly the same getopt_long: (gdb) r --letter-a -2 Starting program: /tmp/g/gol --letter-a -2 Breakpoint 2 at 0xb7f3c5b6 Pending breakpoint "getopt_long" resolved Breakpoint 2, 0xb7f3c5b6 in getopt_long () from /lib/tls/i686/cmov/libc.so.6 (gdb) bt #0 0xb7f3c5b6 in getopt_long () from /lib/tls/i686/cmov/libc.so.6 #1 0x0804844b in main () > > Because only apache/php4(module) is a problematic combination I suspect > > an apache. If it is sufficient for you I have no objections against > > reassigning this bug to apache package. > I'd rather see some analysis to show where the bug actually belongs instead > of guessing and reassigning. That's understandable. But this case exceeds my knowledge. Regards Artur -- Czesiu: Dlaczego wypiłaś cały dzbanek herbaty? Croolik: Bo był. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]