RE: remote XOpenDisplay in Solaris (SunOS 5.6)

[David Korn <dkorn at pixelpower dot com>]

>-----Original Message-----
>From: Jerry Miller [mailto:gmiller@cs.sunysb.edu]
>Sent: 28 February 2001 14:07

>That did it!  Thank you!

  Hooray!! 

>I hadn't experimented enough with gdb to realize that the
>"up" command was virtually equivalent to the PL/I tracebacks
>I used to rely on.  When I discovered that my function
>putmsg was being called by a shared-library routine, I did a
>"man putmsg," and sure enough, there was a conflict there!

  There's also the 'bt' command, which lists the entire stack all the way
back to the program entry point for you.

>Making it a static local function and renaming it for good
>measure has solved this mysterious problem.

  Argh!  Whoever invented the notion that DSOs could have unresolved
symbols in them is a maniac who should be shot through the ears.  Despite
the fact that the price of disk storage has fallen through the floor, it
is seemingly so important to save a few meg here and there that we have
arrived in a situation where nobody except the linker can even begin to
guess what function is actually going to be called by a function call.  It
might perhaps be not quite so bad if unresolved syms in DSOs could only
be resolved by syms from other libs, but the thought that a DSO can contain
an unresolved reference to a system function that ends up getting linked to
your own application is just annoying.  I'm used to systems where you can
write a function called printf and that's what you'll get when your app.
calls printf, but I'm just not used to the notion that the C runtime library
might suddenly start calling your function instead of it's own.

       DaveK
-- 
 All your base are belong to us!


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************