Re: fully supporting static linking in NetBSD (was: ar "zero" flag)

["Greg A. Woods; Planix, Inc." <woods%planix.ca@localhost>]

On 15-Aug-08, at 6:22 AM, Havard Eidnes wrote:
> > at the very least, it makes some debugging *way* more easy.
>
> This is hearsay

Not at all.

Have you seen how much overhead, complexity, and sheer convolution is  
involved in doing even the same level of symbolic debugging for  
dynamic linked applications as one does normally with traditional  
symbolic debuggers on static binaries?

And that's just for traditionally symbolic debuggers -- the world gets  
almost infinitely more complex when fully dynamic runtime link-loading  
is thrown at some of the more modern debugging tools and tricks.

Yes, it can be done -- Apple's Xcode-3.0 does a fair job from what  
I've seen in limited (but live) demonstrations -- however it is  
definitely _WAY_ far _MUCH_ easier to debug static linked binaries.   
There's simply no comparison.  It's really painful debugging something  
when your debugger has more bugs than the target code.  This kind of  
complexity, especially in this arena, is very painful.

In fact I would say, strongly, that if a bug can be reproduced in a  
static binary then one is far better off trying to use even "gdb" on  
that static binary to debug the problem than one would be trying to  
use any symbolic debugger with a binary that loads shared libraries  
(or worse, dynamic runtime modules).

Perhaps you've forgotten just how well "gdb", for example, works with  
static-linked code that's been compiled _entirely_ with "-g" (i.e.  
including all libraries, etc.)?

I'm not having full joy with GCC properly using the lib*_debug.a  
library variants on NetBSD-4 yet but indeed now with NetBSD-4 it is  
possible to easily build a system with debug libraries such that any  
program can simply be relinked, still with identical object code, but  
now incorporating the full debug symbols for everything including all  
libraries.

--
                                        Greg A. Woods; Planix, Inc.
                                        <woods%planix.ca@localhost>