No Pixmaps loaded

Hi,

I'm porting two Motif applications from version 2.2 to 2.3.

No I have a problem with loading the XPM files into the cache, im using the XmGetPixmap() function, the return value is always XmUNSPECIFIED_PIXMAP.

When I create a simple application to prove Motif behaves correctly, the pixmaps are loaded and displayed as expected.

So I downloaded the source RPM and added some printf statements to debug the return values of the procedures to load the XPM files into the cache, I found that Motif is actually trying to load a XPM as a JPEG image, the source of the problem I was able to located in function load_jpeg in file lib/Xm/Jpeg.c the return value of setjmp(jerr.setjmp_buffer) is 2 instead of 1.

I'm using RHEL 6 Update 4.

Here an extract of the application initialization, the application is multi-threaded.

int main( ... ) {
   Widget parent;
   XtAppContext app;
   XInitThreads();
   XtToolkitThreadInitialize();
   XtSetLanguageProc( 0, 0, 0 );
   parent = XtVaOpenApplication( ... );
   exitPixmap = XmGetPixmap( XtScreen( parent ), "exit.xpm", WhitePixelOfScreen( XtScreen( parent ) ), BlackPixelOfScreen( XtScreen( parent ) ) );
   // ...
   return 0;
}

Regards sam

Forums: 

Your problem could be related

dpeterc's picture

Your problem could be related to differences between turbojpeg and jpeg libraries, and how motif treats that.

I have suggested a simple fix but it was rejected.

http://bugs.motifzone.net/long_list.cgi?buglist=1546

Try recompiling Motif with this change, to see if this helps.

Xm/ImageCache.c
the line 961 with
if (rc == 1) { /* not a jpeg file */
needs to be changed in
if (rc) { /* not a jpeg file */

And if you want to do even better job, you can convert your XPM files to PNG and simply set them from resource file of your motif application.

What you describe can happen

dpeterc's picture

What you describe can happen with same source and same binary, depending on the jpeg library it links against.

Because turbojpeg and jpeg libraries are binary compatible, but not on errors they return (depending on how turbojpeg is compiled).

You may want to check with ldd that you link to exactly the same libraries in all your test cases.