Closed Bug 883 Opened 26 years ago Closed 25 years ago

BUILD: Mozilla does not build on ARM Linux

Categories

(SeaMonkey :: Build Config, defect, P1)

Product:
SeaMonkey
Component:
Build Config
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: raff, Assigned: briano)

References

(
URL
)

Details

Building Mozilla on an ARM Linux box fails (tested on Corel NetWinder).

The file mozilla/nsprpub/pr/include/md/_linux.h does not contain the
definitions for _MD_GET_SP, _MD_SET_FP, etc.

Also, gcc on ARM Linux defines, by default, characters as unsigned, while
an explicit manifest for all Linux platforms defines HAVE_SIGNED_CHAR.
So, either the manifest must be undefined or an explicit compilation flag
must be added.

The enclosed file contains the changes to make the build work
(I also added extra flags for C++ to overcome a current limitation of NetWinder
standard libraries - they shouldn't hurt, assumed Mozilla does not use C++
exceptions and rtti, but they can be removed when these libraries get fixed).

With these changes Mozilla correctly builds on NetWinder using LessTif.
moz-export crashes while loading, but mozilla-export start and can be used
for a while (then it crashes or hung the system).
Status: NEW → ASSIGNED
Adding wtc@netscape.com.

We just got a NetWinder!  So we can test this stuff.  Thanks.

marking assigned.
In order to build on NetWinder you also need to apply the fix for bug #881
(standard I/O files are not constant in glibc).
Also, to build with LessTif (and w/out the static version of the library -
that didn't seem to get built) you need the fix for bug #887.

I have more notes about building on NetWinder at http://www.netwinder.org/~raff/
Hi Raff,

I applied your patch to mozilla/nsprpub, and now our
emulated threads work!  Thanks!  I was unable to make
them work.

If you are interested, you can attempt a pthreads-based
build by setting the environment variable USE_PTHREADS
to 1.

Your stderr fix is a good one.  We should never assume
stderr is a constant that can be used in a static
initializer.
is this fixed ?

-re
I only applied the nsprpub portion of the patch.
Setting all current Open/Normal to M4.
Component: Platform: Lesstif on Linux → XFE
Old bug...raff...can this be Verified now?
Component: XFE → Build Config
Product: MozillaClassic → Browser
isn't this fixed?
Severity: normal → major
Priority: P2 → P1
Target Milestone: M4 → M3
All fixed...yes?
Target Milestone: M3 → M7
rickg moved this to M7.  So I figure it is not fixed.
Reassigning to briano.
Assignee: ramiro → briano
Status: ASSIGNED → NEW
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
I'm assuming this is fixed.  Up until xpcom/libxpt went into the code,
I was building successfully on sidewinder:

http://cvs-mirror.mozilla.org/webtools/tinderbox/showlog.cgi?tree=SeaMonkey-Ports

Closing the bug.
Status: RESOLVED → VERIFIED
Rubber-stamping as verified.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.