Closed
Bug 31845
Opened 24 years ago
Closed 24 years ago
OS/2 Build enablement
Categories
(SeaMonkey :: Build Config, defect, P3)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: hctrinh, Assigned: cls)
Details
Attachments
(7 files)
32.41 KB,
patch
|
Details | Diff | Splinter Review | |
34.47 KB,
patch
|
Details | Diff | Splinter Review | |
6.83 KB,
patch
|
Details | Diff | Splinter Review | |
2.84 KB,
patch
|
Details | Diff | Splinter Review | |
2.84 KB,
patch
|
Details | Diff | Splinter Review | |
14.96 KB,
patch
|
Details | Diff | Splinter Review | |
679 bytes,
patch
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•24 years ago
|
||
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.
Reporter | ||
Comment 10•24 years ago
|
||
The 2 places where MOZ_JS_LIBS is added to LIB was: xpcom\tools\registry and xpcom\test.
Comment 11•24 years ago
|
||
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
Reporter | ||
Comment 12•24 years ago
|
||
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
Comment 13•24 years ago
|
||
Those are all in xpcom and nsprpub, if I'm not mistaken. Huynh, could you email me your full xpcom build log?
Reporter | ||
Comment 14•24 years ago
|
||
Reporter | ||
Comment 15•24 years ago
|
||
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.
Reporter | ||
Comment 16•24 years ago
|
||
Assignee | ||
Comment 17•24 years ago
|
||
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.
Assignee | ||
Comment 18•24 years ago
|
||
Assignee | ||
Comment 19•24 years ago
|
||
Comment 20•24 years ago
|
||
Looks okay. What is WANT_MOZILLA_CONFIG_OS_VERSION?
Assignee | ||
Comment 21•24 years ago
|
||
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.
Assignee | ||
Comment 22•24 years ago
|
||
Comment 23•24 years ago
|
||
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?
Assignee | ||
Comment 24•24 years ago
|
||
The extra space doesn't appear to cause a problem under linux. I've added it to my local tree.
Assignee | ||
Comment 25•24 years ago
|
||
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.
Assignee | ||
Comment 26•24 years ago
|
||
Patches checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 27•24 years ago
|
||
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.
Reporter | ||
Comment 28•24 years ago
|
||
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.
Reporter | ||
Comment 29•24 years ago
|
||
Assignee | ||
Comment 30•24 years ago
|
||
Oops. Sorry about that. Checked in a fix.
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•