Re: remote XOpenDisplay in Solaris (SunOS 5.6)

["Jerry Miller" <gmiller@cs.sunysb.edu>]

----- Original Message -----
From: David Korn <dkorn@pixelpower.com>
To: 'Jerry Miller' <gmiller@cs.sunysb.edu>; <help-gcc@gnu.org>
Sent: Friday, February 23, 2001 11:46 AM
Subject: RE: remote XOpenDisplay in Solaris (SunOS 5.6)


>
> >-----Original Message-----
> >From: Jerry Miller [ mailto:gmiller@cs.sunysb.edu ]
> >Sent: 23 February 2001 16:16
>
> >Does anyone have an idea why Motif applications that
> >used to run either locally or with a remote display now
> >only work locally, causing a Segmentation fault as soon
> >as XtVaAppInitialize () (or its more primitive component,
> >XOpenDisplay()) is called in a remote-display run?
>
>   If something has suddenly changed like this, it's probably because
> you've installed a new library somewhere, which is being pulled in by
> dynamic linking, and isn't compatible with the version the application
> is expecting to find.
>
------------------------
I'm not sure what is dynamically linked in terms of object
modules under UNIX in general or Solaris specifically.
Any idea of some potential candidates?

One thing did occur to me.  Do you (or does anyone)
know whether window managers use ipc and/or rpc
(interprocess control and remote process control)
routines in dealing with GUI's and other window
managers???  And if so, is it possible to create some
kind of "X-sniffer" on the display host to emulate the
window manager and intercept X requests?????
------------------------
> >the software do not have this problem.  When I
> >#define out calls from main() to other local functions,
> >I still have it bombing, unless I also comment out a
> >number of calls to external functions from the local
> >functions that are never called!
>
>   The first thing that happens at startup of an application is that the
> constructors for any C++ class objects of static storage duration are
---------------------------
Is this true of straight C code as well, e.g., ordinary static local
functions?
I'm not using C++ at all, so I'd be really surprised if it did anything more
automatically than to initialize static and global variables.  I've never
heard
Kernighan and Ritchie mention anything about functions starting themselves
with no provocation from main()!
---------------------------
> called automagically.  It sounds like the problem is in one of these
> constructors, since removing the function calls from main doesn't make
> any difference; these constructors are called before main starts, anyway.
>
>   The reason that removing the calls in the other functions finally makes
> it work is because when they've been removed, that gets rid of all the
> references to a particular object module in the altered lib, which means
> that it doesn't get pulled in at all by the linker, which means that its
> static objects aren't pulled in, which means that the faulty constructor
> isn't run.
>
>   Note that if there is no C++ in the Motif/X libs you're using, this may
> turn out not to be the explanation after all!
>
---------------------------
I'm not aware of any.  How would I tell?  As far as I know, there are no
.hpp files in /usr/include/X11 or Xm, but libX11.a doesn't become
libX11.app.
---------------------------
> >meaningless, even in the unlikely event the
> >debugger isn't introducing its own uncertainty
> >(a la Heisenberg?)
>
>   Look up 'heisenbug' in the jargon file :)
---------------------------
:)  I can guess - it's one that goes into hiding or pops up elsewhere when
    you add a printf () or something to see what's going on, right?
---------------------------
>
> >Rather than waste any more time on trial and
> >error, I thought I'd see whether there's a
> >window manager guru out there who might
> >have answers or suggestions.
>
>   I'm not that, and nor do I really know a lot about the mysteries of
> dynamically linked libraries, but what I've suggested is certainly up
> there in the 'top five possibilities to investigate' list.  See if the
> last modified date on any of your lib files is around the time when it all
> stopped working.
>
------------------------------
Thanks for the ideas, Dave.  Every little bit helps, and I appreciate the
quick response.
------------------------------
>     hth,
>      DaveK
> --
> we are not seats or eyeballs or end users or consumers.
> we are human beings - and our reach exceeds your grasp.
>                     deal with it.                      - cluetrain.org
>
------------------------------
Heavy concept!  ;)
------------------------------
>
> **********************************************************************
> 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
> **********************************************************************
>