Closed Bug 31845 Opened 25 years ago Closed 24 years ago

OS/2 Build enablement

Categories

(SeaMonkey :: Build Config, defect, P3)

Other
OS/2
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: hctrinh, Assigned: cls)

Details

Attachments

(7 files)

Update rules.mk and config.mk to enable OS/2 build.
This bug is a follow on the 25555 in which a Makefile bundle was 
deemed not acceptable due to OS/2 specific block. As a result, changes 
to config.mk and rules.mk is necessary per attached. We plan to 
further contribute makefile later in a separate bug.
Um, a big chunk of that patch resurrects the libs build phase.  Is that really
necessary?  Same goes for the zap* targets.  We can start phasing in some of the
patch immediately (like the BIN_SUFFIX & VACPP changes).  But we really need to
figure out if the OS/2 build really needs the overhead of the libs build pass.
Status: NEW → ASSIGNED
What happened to the libs phase?

The zap* rules are simply utilities for clearing out specific sets of files 
short of a full clean.
The build phase was removed a couple of weeks ago.  It has been gone from the
windows build for a couple of months now and it has been slated for removal for
the unix build since then.  Now, the libs and binaries are compiled and
"installed" during the install phase.  Eventually, if we can overcome the
recursive idl dependency problems, we're going to look into a single pass build
again.
As long as there are no forward dependencies, we should be okay. I moved all 
our linkage to the install phase last spring to avoid having a separate build 
order in the top makefile. We can't link against libraries that haven't been 
built.
Chris, we break as early as xpcom/tools/registry because there we have to link 
with mozjs.lib. Sticking with the old three-pass system seems preferable to 
creating and maintaining a separate build order. Building libs during export is 
likely a no-op because of xpidl-generated headers; otherwise it would just be a 
matter of adding include paths for those not yet in dist/include.
I'm a bit curious as to why you need to link against mozjs in
xpcom/registry/tools when no other platform does.  I didn't see any extra mozjs
linkage in the patch attached to bug #25555 nor this one.  
I noticed that, so suggested Huynh try removing it. His reply: "I comment out 
the $(MOZ_JS_LIBS) from the  Makefile's LIBS statement and get a bunch of 
unresolved externals!!!" Strange, because from a copy of our old Makefile.in 
with the OS/2 blocks, I see we didn't need it then though there was a -lmozjs 
among the LIBS.
Hrm.  I have no qualms with juggling the build order especially when the
alternative is to resurrect an unneeded build phase.  Can you give me the list
of Makefile.in's that have mozjs added to LIBS? In theory, js is a standalone
module so there shouldn't be a problem building libmozjs before xpcom.  However,
I believe that liveconnect requires some xpcom headers.  We may have to make the
toplevel makefile explicitly traverse js/src/liveconnect after it does xpcom.
The 2 places where MOZ_JS_LIBS is added to LIB was: xpcom\tools\registry and 
xpcom\test. 
The list below covers all MOZ_JS_LIBS (both LIBS and EXTRA_DSO_LDOPTS). I've 
been wondering though if the unresolved symbols aren't coming from code that 
got snipped. That may explain why we break there whereas the other platforms 
don't. From the list, it's apparent that the dependency is limited to the test 
programs built before mozjs.lib.

dom\src\build\Makefile.in
editor\base\Makefile.in
gfx\src\os2\Makefile.in
gfx\tests\Makefile.in
htmlparser\tests\outsinks\Makefile.in
intl\strres\tests\Makefile.in
js\src\liveconnect\Makefile.in
js\src\xpconnect\loader\Makefile.in
js\src\xpconnect\shell\Makefile.in
js\src\xpconnect\src\Makefile.in
js\src\xpconnect\tests\Makefile.in
js\src\xpconnect\tests\components\Makefile.in
layout\base\tests\Makefile.in
layout\build\Makefile.in
layout\html\tests\Makefile.in
mailnews\compose\build\Makefile.in
mailnews\compose\tests\compose2\Makefile.in
mailnews\compose\tests\geturl\Makefile.in
mailnews\compose\tests\sendlater\Makefile.in
mailnews\compose\tests\sendpage\Makefile.in
mailnews\news\build\Makefile.in
modules\libpref\src\Makefile.in
modules\oji\src\Makefile.in
netwerk\test\Makefile.in
rdf\build\Makefile.in
rdf\tests\rdfcat\Makefile.in
rdf\tests\rdfpoll\Makefile.in
widget\tests\widget\Makefile.in
xpcom\tests\Makefile.in
xpcom\tools\registry\Makefile.in
xpfe\AppCores\src\Makefile.in
xpfe\appshell\src\Makefile.in
xpfe\bootstrap\Makefile.in
xpfe\components\bookmarks\src\Makefile.in
xpfe\components\directory\Makefile.in
xpfe\components\find\src\Makefile.in
xpfe\components\search\src\Makefile.in
xpfe\components\ucth\src\Makefile.in
xpfe\components\xfer\src\Makefile.in
xpinstall\src\Makefile.in
By removing MOZ_JS_LIB from the xpcom\tools\registry\makefile LIB ststement, I 
got the follwoing errors:

error L2029: 'nsGetServiceByCID::~nsGetServiceByCID(void)' : unresolved external
error L2029: 'nsGetServiceByCID::nsGetServiceByCID(nsID const &, nsISupports *, 
unsigned int *)' : unresolved external
error L2029: 'NS_InitXPCOM(nsIServiceManager **, nsFileSpec *)' : unresolved 
external
error L2029: 'nsDebug::Assertion(char const *, char const *, char const *, int)' 
: unresolved external
error L2029: 'nsDebug::PreCondition(char const *, char const *, char const *, 
int)' : unresolved external
error L2029: 'PL_strcat' : unresolved external
error L2029: 'PL_strcpy' : unresolved external
error L2029: 'PL_strlen' : unresolved external
error L2029: 'nsAllocator::Free(void *)' : unresolved external
Those are all in xpcom and nsprpub, if I'm not mistaken. Huynh, could you email 
me your full xpcom build log?
I updated the diff files for rules.mk and config.mk. They are now 
conforming w 2 pass build. I still have to keep a libs:: section for 
OS/2 for the export pass. Please review and comment. I would 
appreciate if you all can review it quickly and commit for M14/M15.
The config.mk diff is still reverting changes made recently to config.mk for no
valid reason that I can determine.  (Recent being within the past month.)  I
will attach a patch that incorporates the os2 changes w/o reverting other
changes.
Looks okay. What is WANT_MOZILLA_CONFIG_OS_VERSION?
Sorry about the duplicate attachment. WANT_MOZILLA_CONFIG_OS_VERSION is an
existing variable in config.mk that decides whether OS_VERSION is set or not. 
And checking lxr, we no longer use OS_VERSION so it can be removed.

I just finished hand patching rules.mk.   Same problem as config.mk, lots of the
hunks were reverting recent changes.  I'm holding off on the zap* targets as
well as we just consolidated the cleanup targets so that we basically just have
clean & distclean.  
Looks fine except the lack of a space after the first colon in:

$(SIMPLE_PROGRAMS):%$(BIN_SUFFIX): %.o $(EXTRA_DEPS) Makefile Makefile.in

is fatal for us and cost me several handfuls of hair to track down. Assuming it 
won't break other platforms, could you please insert it?

The extra space doesn't appear to cause a problem under linux. I've added it to
my local tree.

Ok, I was waiting for input from Huynh before proceeding but since the patch
(+space) works for Henry, I'm going to check it in this afternoon.
Patches checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Thanks for check in the changes. I am still verifying our OS/2 build 
and will keep you informed of any minor tweaking. Again thank you very 
much.
For rules.mk, I ran into a minor glitch in the install pass of 
xpcom\build. I am attaching the diff for DEF_OBJ for OS/2.
Oops. Sorry about that. Checked in a fix.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: