Closed Bug 10383 Opened 21 years ago Closed 20 years ago
[PP]xlibrgb does not detect target machine endianness
Hi Blizzard, After fixing a compilation error for Executor on the SeaMonkey-Ports page, I get this output, which causes an orange tree... Executor is the Motif machine, but now that the Motif port is using your Xlibrgb stuff as well for the GFX stuff (and I am using it in various places, too), I get this: ------------------------- Output from apprunner nsComponentManager: Autoregistration begins. dir = /builds/tinderbox/SeaMonkey/SunOS_5.5.1_clobber/mozilla/obj-sparc-sun-solaris2.5.1/dist/bin/components Registered Ok *** Register XPConnect *** Register XPConnect test components *** Libjar is being registered *** Registering GFX Postscript *** Registering html library *** XPInstall is being registered nsFindComponent registration successful nsUnknownContentTypeHandler registration successful nsStreamTransfer registration successful Registering the PrefsWindow register filter service nsComponentManager: Autoregistration ends. dir = /builds/tinderbox/SeaMonkey/SunOS_5.5.1_clobber/mozilla/obj-sparc-sun-solaris2.5.1/dist/bin/components xlib_rgb_init: compiled for little endian, but this is a big endian machine. ------------------------- End of Output tinderbox: tree: SeaMonkey-Ports tinderbox: builddate: 932690021 tinderbox: status: testfailed tinderbox: build: executor SunOS/sparc 5.5.1 Clobber Motif apprunner tinderbox: errorparser: unix tinderbox: buildfamily: unix tinderbox: END
This is because the xlibrgb code, while having support for big endian machines, doesn't know how to detect them. There's probably an nspr define somewhere that will allow that to happen but I've never found it. I'm taking patches. :)
Summary: xlib_rgb_init incorrectly built for Executor Tinderbox → [PP]xlib_rgb_init incorrectly built for Executor Tinderbox
This will work. However, it's confusing. There's configuration information somewhere in the NSPR headers that contains the information about whether or not it's a little endian or big endian machine. I'm just not sure where. If I can't get an answer about it I'll apply this patch.
Can someone on a Sparc system try the patch that I just attached and see if it works?
Summary: [PP]xlib_rgb_init incorrectly built for Executor Tinderbox → [PP]xlibrgb does not detect target machine endianness
I am changing the bug summary so it better summarizes the general problem. BTW Blizzard, the Executor Tinderbox is a Sparc machine, and it is building xlibrgb for the Motif port, so if you want to check the patch in, you should be able to tell if it is working by seeing if Executor goes green when the build isn't busted. Otherwise it will be orange as it was before. And since it isn't part of the main builds, I am assuming it will be okay. I won't mind if it doesn't work, since it didn't work before on Executor anyway... You can't break something that was already broken, I say.
Ok, I've checked it in. Watching the executor build...
It looks like Executor currently has a different error turning it orange... I'll try to look into this, though it will be a little hard since I don't have any Sun Sparc hardware to work with or get experience on. BTW, I notice you still have the "XXX" comment about detecting machine endianness as a fallback if you cannot determine it at compile time. I am thinking--would it not make more sense to use Al's runtime endian detection patch as the fallback action instead? I'm thinking this would cover all bases.
Status update: For the first time in several days now, I've got Mozilla to compile again (since I just upgraded to GCC 2.95.1 on my Red Hat 6.0 system; it seems quite a bit pickier than EGCS 1.1.2 was for some reason). Anyway, I just got Mozilla compiled, and I think your compile-time endianness detection patch has a problem somewhere. Although it seems to work correctly on Executor once in a while (when it isn't giving the other error about not finding libXm.so.3, which I cannot figure out since I don't have a Sun machine myself to test it on), I now get the following on my Intel i586 system: xlib_rgb_init: compiled for big endian, but this is a little endian machine.
Ok, I've checked in something that should fix this. I wasn't including "xlibrgb.h" before the endian checks so the defines were never making it into the .c file. It was still defaulting to little endian. Try it now and let me know if it works for you.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Good news--it now works properly on my little endian Intel Pentium, and it also appears to do the right thing on the big endian Sparc-based Executor Tinderbox--at least, it seems to be going green, anyway. So I think you've finally fixed it. BTW, I am now wondering what one is to do if he wants to use XlibRGB independently of Mozilla, where he could conceivably be without the luxury of the endianness information defined in NSPR beforehand; would you suggest applying Al's runtime endianness detection patch instead in such a situation? I'm not suggesting your compile-time patch presents a new problem here; I'm just curious about this for future reference. And thank you so much for fixing this. I hope it wasn't too much trouble. I just like seeing green Tinderboxes, especially since the SeaMonkey-Ports page seems to have a shortage of them at the moment. :-)
Please ignore the spam. Changing address.
Assignee: blizzard → blizzard
Status: VERIFIED → NEW
bustage from my reassign
Status: NEW → RESOLVED
Closed: 21 years ago → 20 years ago
bustage from my reassign
Status: RESOLVED → VERIFIED
Seems the problem appeared again: Today I tried (tip_2000-06-05-08-M16) to print via libXp/Xprt and the response was: -- snip -- Loading page specified via openDialog Opening file cookies.txt failed Opening file cookperm.txt failed in SetSecurityButton WEBSHELL+ = 5 Enabling Quirk StyleSheet Enabling Quirk StyleSheet Document: Done (2.608 secs) *** check number of frames in content area Document http://www.mozilla.org/ loaded successfully WARNING: not calling OnDataAvailable, file ../../../../netwerk/base/src/nsAsyncStreamListener.cpp, line 409 xlib_rgb_init: compiled for little endian, but this is a big endian machine. -- snip -- Should this bug be reopened ?
Leger, since you are the QA contact, and have marked this as Verified Fixed before, should we re-open this, or open a new bug for it? In either case, I would think this counts as a regression, since it was Verified Fixed at some point...
I filed new bug 49879 for the problem that printing with Xprint exits with "xlib_rgb_init: compiled for little endian, but this is a big endian machine."...
Off-topic: Who changed component from "other" to "tracking" (I wasn't !!!!). BUG_ACTIVITY doesn't show the change...
You need to log in before you can comment on or make changes to this bug.