On 11/11/2010 01:19 PM, [email protected] wrote: > Message: 7 Date: Thu, 11 Nov 2010 12:50:19 -0700 From: stan > <[email protected]> Subject: Re: How to make a program static (for bug > regression)? To: [email protected] Message-ID: > <[email protected]> Content-Type: > text/plain; charset="US-ASCII" On Thu, 11 Nov 2010 11:42:12 -0800 > Chuck Forsberg WA7KGX N2469R <[email protected]> wrote: >> > I would like to compile pan(1) with completely static libraries >> > so I can tell if the breakage I've reported is from some library >> > that got hosed in an update vs. something in the kernel itself. > Can you run it via gdb from an xterm? > >> > >> > Adding -static results in 52 undefined libraries. The first one >> > I looked for didn't have a static version available. > This will be the norm since they are considered bad practice. > >> > >> > Is there a reasonable way to get a statically linked version without >> > having to compile 52 libraries from source? >> > > As far as I know, no. However, you can install the debug information > packages for all of these, allowing you to use gdb to see the code as it > executes. > > First, I would install the debug package for pan, or compile it with > debugging turned on if there is none. Then run it via gdb until the > problem occurs, and look where it is. Because it isn't actually > crashing for you, it isn't as simple as > gdb pan > run > and dissect the crash. You'll have to use pan until you see the > behavior that is wrong and then look. It could take a few tries, but > you should be able to narrow it down to what is wrong. > > Because the debug packages are with optimization turned on, they will > occasionally skip lines, and jump around the source, but you should be > able to get an idea at least. > > > Pan does not crash. It appears that the data Pan gets has missing bytes - a handful or so at a time. It is not exactly repeatable; downloading the same part yielded a different pattern of corruption each of a half dozen or so times I tried it.
By the time Pan detects the error with a failed CRC or size check, the actual error event has long since receded into history. -- Chuck Forsberg WA7KGX N2469R [email protected] www.omen.com Developer of Industrial ZMODEM(Tm) for Embedded Applications Omen Technology Inc "The High Reliability Software" 10255 NW Old Cornelius Pass Portland OR 97231 503-614-0430 -- test mailing list [email protected] To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
