Re: How to make a program static (for bug regression)?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/11/2010 01:19 PM, test-request@xxxxxxxxxxxxxxxxxxxxxxx wrote:
> Message: 7 Date: Thu, 11 Nov 2010 12:50:19 -0700 From: stan 
> <gryt2@xxxxx> Subject: Re: How to make a program static (for bug 
> regression)? To: test@xxxxxxxxxxxxxxxxxxxxxxx Message-ID: 
> <BLU0-SMTP747604BC2EFA94EC125122EE320@xxxxxxx> Content-Type: 
> text/plain; charset="US-ASCII" On Thu, 11 Nov 2010 11:42:12 -0800 
> Chuck Forsberg WA7KGX N2469R <caf@xxxxxxxx> 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     caf@xxxxxxxx   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
test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test


[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Photo Sharing]     [Yosemite Forum]     [KDE Users]

  Powered by Linux