Closed Bug 10383 Opened 21 years ago Closed 20 years ago

[PP]xlibrgb does not detect target machine endianness


(Core Graveyard :: Tracking, defect, P3)



(Not tracked)



(Reporter: zuperdee, Assigned: blizzard)





(2 files)

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 =
     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 =
     xlib_rgb_init: compiled for little endian, but this is a big endian

     ------------------------- 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
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, 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.
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. :-)
Marking Verified.
Please ignore the spam.  Changing address.
Assignee: blizzard → blizzard
bustage from my reassign
Closed: 21 years ago20 years ago
bustage from my reassign
Seems the problem appeared again:
Today I tried  (tip_2000-06-05-08-M16) to print via libXp/Xprt and the response
-- snip --
Loading page specified via openDialog
Opening file cookies.txt failed
Opening file cookperm.txt failed
in SetSecurityButton
Enabling Quirk StyleSheet
Enabling Quirk StyleSheet
Document: Done (2.608 secs)
*** check number of frames in content area 
Document 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
-- 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
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
Off-topic: Who changed component from "other" to "tracking" (I wasn't !!!!).
BUG_ACTIVITY doesn't show the change...
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.