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
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.
Hi,
thanks for your answer, but I think your patch will not solve my problem. Since when I write a simple Motif application just to display the pixmap on a XmPushButton that works with the libraries provides by Red Hat Enterprise Linux 6.
The problem is even more frustrating since the other application using the same source to load the pixmaps works normal.
Regards sam
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.
Hi,
thanks for your help.
I found the problem, it was linker problem. A third party we don't have the source to recompile it links against the wrong jpeg library.
Regards sam