| > The libraries (libX11.so, libXext.so, libXt.so) match those that you
> have.
>
> So what could be different? Did you say you are using your own Motif
> library?
>
> Try linking -non_shared. If that fails in the same way send me the
> executable, or you could try sending me the shared executable (uuencoded
> or as a MIME attachment).
>
>
Thats right the proplem only occurs if you link with our Motif library -
The WINTIF_COMPATIBILITYMODE env variable will have no effect otherwise
However when linked with our Motif library it is still the case that the executable fails
of linked with the UNIX4.0 X libraries and works with the OSF1 3.0 ones.
I will send you a statically linked executable uuencodeed.
|
| No reply to my last mail, but I'll try once again before closing the call, in case
it didn't reach you.
As you appreciate this is a difficult problem to track down. I need to put
together some kind of source reproducer in order to either solve or escalate the
problem. I have the source (xxlogo.c) of your reproducer, from which
XtDestroyWidget is called directly. However I need *your* Motif library (just the
shareable, not the source) to cause it to fail.
|
| Cross-posted from MOTIF conference, note 5951...
The following code example, together with the customer's own Motif library
(libXm.so), works fine with DUNIX 3.2c but suffers a segmentation fault when it
calls XtDestroyWidget under DUNIX 4.0b.
The segmentation fault only occurs with the environment variable
"WINTIF_COMPATIBILITYMODE" set to "Windows95", which modifies the behaviour of
the customer's libXm.so. The library is available via anonymous ftp from
apc013.reo.dec.com:/pub/libXm.so.
The example runs OK under DUNIX 4.0x with the DUNIX 3.2c libXt.so however. Can
the customer (ISV) ship this with his Motif library?
Richard
------------------------------ code example -------------------------------
#include <stdio.h>
#include <math.h>
#include <Xm/Xm.h>
main (argc, argv)
int argc;
char **argv;
{
XtAppContext context;
Widget shell, container, draw, scale1, scale2;
Display *display;
int i;
Visual *visual;
Colormap cmap;
unsigned int depth;
XtToolkitInitialize ();
context = XtCreateApplicationContext ();
display = XtOpenDisplay (context, NULL, NULL, "Scale",
NULL, NULL,
&argc, argv);
/* Create a temporary shell so application resources can be fetched from the
resource database */
shell = XtVaAppCreateShell (NULL, "ColourWheel",
applicationShellWidgetClass,
display, NULL);
/* Now the depth, visual and colormap is known, destory the old, temporary
shell and create a new one */
XtDestroyWidget (shell);
}
|
| I've reduced your example to the bare essentials (attached). There
appears to be some incompatibility between your vendor shell widget and
our X11R6 toolkit. If I modify either example to create a (temporary) WM
shell widget instead of an application shell widget it runs OK, but a
vendor shell widget introduces the same behaviour as the application
shell widget.
The segmentation fault occurs in XtWidgetToApplicationContext, called
from XtDestroyWidget.
If I were to formally submit the problem to engineering they would
simply point the finger at your Motif library. My informal submission
has produced no response, as I rather expected.
I suggest the best short-term solution would be to ship the Digital Unix
3.2c libXt.so with your existing library, with a note explaining the use
of the LD_LIBRARY_PATH environment variable (although I suspect you
already use this).
|