Closed Bug 297386 Opened 15 years ago Closed 15 years ago

Software Update breaks OS/2 build

Categories

(Toolkit :: Application Update, defect)

x86
OS/2
defect
Not set

Tracking

()

RESOLVED FIXED

People

(Reporter: dragtext, Unassigned)

References

Details

Attachments

(1 file)

Changes to Software Update have broken the OS/2 build because the new code is
platform-specific and needs to be ported.  I couldn't locate any "courtesy bugs"
advising the owners of contributed builds that this work needed to be done.  I
don't know if such bugs are customary, but they certainly are appreciated.

AFAICT, the following need to be ported:
  mozilla/toolkit/xre/nsUpdateDriver.cpp
  mozilla/toolkit/mozapps/update/src/updater/*

In addition, files in mozilla/modules/libmar compile without any changes but
mar.exe fails with a link error:
  gcc -o mar.exe -DXP_OS2 -DNO_X11  host_mar.o ../../../dist/lib/mar.lib 
  ld.exe: malformed input file (not rel or archive) ../../../dist/lib/mar.lib

Until the ports are done & the link error resolved, adding --disable-updater to
.mozconfig will sidestep the issue.
I recommend building with --disable-updater.  I anticipated OS/2 build bustage.
 Sorry for not posting broadly about this.  We're working hard to just get
things working for the main platforms.
I got the build bustage in libmar fixed.

Darin, is there some documented way to test this stuff?
libmar can be tested via the mar program.  it works much like the standard tar
program.  there isn't any documentation for testing the update service itself as
it is all very new.
Would the updater even work on OS/2 if Rich or Mike got the code working? Would
it work for cross-plattform updates? And for updates containing plattform
dependent binaries, would we need an extra server to distribute OS/2 updates or
at least somebody who created the builds and uploaded them to UMO?
Exactly, the challenge is not getting the client-side code working, but rather
the challenge is in populating the update database and managing everything
there.  Right now, we are working to make the system work for the primary builds
produced by the Mozilla Foundation: Windows, Mac, and Linux.  But, we're paving
new ground.  It sounds like a more complex problem to try to support community
generated update files.
I reordered the #ifdef at the top to be #if Windows else everyone else.

I put the pthreads in an XP_UNIX

I added an OS/2 path for threads

I added an error case if you don't have code in the threads part.
Attachment #186122 - Flags: review?(benjamin)
Attachment #186122 - Flags: review?(benjamin)
Attachment #186122 - Flags: review+
Attachment #186122 - Flags: approval-aviary1.1a2+
Attachment #186122 - Flags: superreview+
Attachment #186122 - Flags: review?(benjamin)
Attachment #186122 - Flags: review+
Attachment #186122 - Flags: review?(benjamin) → review+
This bug also applies to Windows Builds!

It's not possible to build firefox with cygwin and mingw.

look at http://forums.mozillazine.org/viewtopic.php?p=1536049#1536049


l:/building_Mozilla/source/TRUNK/mozilla/jpeg/jcmainct.c: In function
`jinit_c_main_controller':
l:/building_Mozilla/source/TRUNK/mozilla/jpeg/jcmainct.c:247: warning: 'main' is
usually a function
../../../dist/lib/libmar.a(mar_create.o):mar_create.c:(.text+0x6d): undefined
reference to `htonl@4'
../../../dist/lib/libmar.a(mar_create.o):mar_create.c:(.text+0x7e): undefined
reference to `htonl@4'
../../../dist/lib/libmar.a(mar_create.o):mar_create.c:(.text+0x8e): undefined
reference to `htonl@4'
../../../dist/lib/libmar.a(mar_create.o):mar_create.c:(.text+0x2dc): undefined
reference to `htonl@4'
../../../dist/lib/libmar.a(mar_create.o):mar_create.c:(.text+0x334): undefined
reference to `htonl@4'
../../../dist/lib/libmar.a(mar_read.o):mar_read.c:(.text+0xf0): undefined
reference to `ntohl@4'
../../../dist/lib/libmar.a(mar_read.o):mar_read.c:(.text+0xfe): undefined
reference to `ntohl@4'
../../../dist/lib/libmar.a(mar_read.o):mar_read.c:(.text+0x10b): undefined
reference to `ntohl@4'
../../../dist/lib/libmar.a(mar_read.o):mar_read.c:(.text+0x215): undefined
reference to `ntohl@4'
../../../dist/lib/libmar.a(mar_read.o):mar_read.c:(.text+0x27e): undefined
reference to `ntohl@4'
collect2: ld returned 1 exit status
make[4]: *** [mar.exe] Error 1
make[3]: *** [libs] Error 2
make[2]: *** [tier_1] Error 2
make[1]: *** [default] Error 2
make: *** [build] Error 2 

(In reply to comment #0)
> Until the ports are done & the link error resolved, adding --disable-updater to
> .mozconfig will sidestep the issue.
thanks
Depends on: 296303
It looks like this patch was checked in on 6/13 by mkaply.  Marking FIXED.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.