297386 - Software Update breaks OS/2 build

Status: RESOLVED FIXED

(Toolkit :: Application Update, defect)

Description

[Rich Walsh]

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.

Comment 1

[Darin Fisher]

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.

Comment 2

[Mike Kaply [:mkaply]]

I got the build bustage in libmar fixed.

Darin, is there some documented way to test this stuff?

Comment 3

[Darin Fisher]

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.

Comment 4

[Peter Weilbacher]

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?

Comment 5

[Darin Fisher]

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.

Comment 6

[Mike Kaply [:mkaply]]

Attachment: Add OS/2 path and reorganize #ifdefs a bit

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.

Comment 7

[Ronny Perinke]

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

Comment 8

[Darin Fisher]

It looks like this patch was checked in on 6/13 by mkaply.  Marking FIXED.