Closed Bug 81371 Opened 19 years ago Closed 19 years ago

make windows static build

Categories

(SeaMonkey :: Build Config, defect, P2)

x86
All
defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.3

People

(Reporter: cathleennscp, Assigned: cathleennscp)

References

Details

(Keywords: memory-footprint, meta)

Attachments

(5 files)

 
Blocks: 46775
Here is a break down list of libs required per install option (win mozilla)

minimal xpcom lib (required by installer)
----------------------
bin\js3250.dll
bin\mozreg.dll
bin\nspr4.dll
bin\plc4.dll
bin\plds4.dll
bin\xpcom.dll
bin\xpistub.dll
bin\zlib.dll
bin\components\jar50.dll
bin\components\xpinstal.dll
bin\components\ucharuti.dll


browser lib
----------------------
bin\gkgfxwin.dll
bin\gkwidget.dll
bin\img3250.dll
bin\jpeg3250.dll
bin\jsj3250.dll
bin\mozctl.dll
bin\mozctlx.dll
bin\components\AcctIdl.dll
bin\components\appshell.dll
bin\components\appcomps.dll
bin\components\embedcomponents.dll
bin\components\caps.dll
bin\components\chardet.dll
bin\components\chardetc.dll
bin\components\chrome.dll
bin\components\cookie.dll
bin\components\docshell.dll
bin\components\jsdom.dll
bin\components\editor.dll
bin\components\evntloop.dll
bin\components\gfx2.dll
bin\components\gkcontent.dll
bin\components\gklayout.dll
bin\components\gkparser.dll
bin\components\gkplugin.dll
bin\components\gkview.dll
bin\components\imggif.dll
bin\components\imgjpeg.dll
bin\components\imglib2.dll
bin\components\imgpng.dll
bin\components\imgppm.dll
bin\components\imgicon.dll
bin\components\jsloader.dll
bin\components\jsurl.dll
bin\components\lwbrk.dll
bin\components\mork.dll
bin\components\mozbrwsr.dll
bin\components\mozfind.dll
bin\components\mozucth.dll
bin\components\mozxfer.dll
bin\components\nativapp.dll
bin\components\necko.dll
bin\components\nkcache.dll
bin\components\necko2.dll
bin\components\nsgif.dll
bin\components\nsjpg.dll
bin\components\nslocale.dll
bin\components\nsmng.dll
bin\components\nspng.dll
bin\components\nsprefm.dll
bin\components\oji.dll
bin\components\profile.dll
bin\components\rdf.dll
bin\components\regviewr.dll
bin\components\shistory.dll
bin\components\strres.dll
bin\components\txmgr.dll
bin\components\txtsvc.dll
bin\components\uconv.dll
bin\components\ucvcn.dll
bin\components\ucvibm.dll
bin\components\ucvja.dll
bin\components\ucvko.dll
bin\components\ucvlatin.dll
bin\components\ucvtw.dll
bin\components\ucvtw2.dll
bin\components\urildr.dll
bin\components\wallet.dll
bin\components\webbrwsr.dll
bin\components\wlltvwrs.dll
bin\components\xpc3250.dll
bin\components\xppref32.dll
bin\plugins\npnul32.dll
bin\components\xmlextras.dll
bin\components\transformiix.dll


mail lib
----------------------
bin\msgbsutl.dll
bin\components\addrbook.dll
bin\components\emitter.dll
bin\components\mime.dll
bin\components\msgbase.dll
bin\components\msgcompo.dll
bin\components\msgdb.dll
bin\components\msgimap.dll
bin\components\msglocal.dll
bin\components\msgnews.dll
bin\components\vcard.dll
bin\components\signed.dll
bin\components\smime.dll
bin\components\import.dll
bin\components\importOE.dll
bin\components\impOutlk.dll
bin\components\impEudra.dll
bin\components\impText.dll
bin\components\absyncsv.dll
bin\components\mozldap.dll
bin\nsldap32v40.dll


psm lib
----------------------
bin\nssckbi.dll
bin\components\pipnss.dll
bin\components\pippki.dll
I'm in the process of merging my changes into the STATIC_BUILD_20010523_BRANCH
I'm still stuck on the unresolved externals.  Everything I have will be checked
in by the end of the day.

dprice, can you attatch your diff to this bug, so we can try it out?  
thanks!!!  :-)
how to make it work...
After you apply the forthcoming patch....

set MOZ_STATIC_COMPONENT_LIBS=1
build the tree
copy xpcom/components/nsStaticComponent.h into xpfe/bootstrap/
nmake -f makefile.win in xpfe/bootstrap

you should see 1406 unresolved externals.
oh yeah....
set MOZ_NO_ACTIVEX_SUPPORT=1
dprice, I got it to build, but had to mock 3 files to get to it, and here is the
diff of my hack, to get around unable to find InstallCleanupDefines.h (I'm not
sure if that's the correct way to fix it though)

cvs server: Diffing .
Index: ScheduledTasks.cpp
===================================================================
RCS file: /cvsroot/mozilla/xpinstall/src/ScheduledTasks.cpp,v
retrieving revision 1.32
diff -u -r1.32 ScheduledTasks.cpp
--- ScheduledTasks.cpp  2001/05/17 05:51:27     1.32
+++ ScheduledTasks.cpp  2001/06/01 01:00:51
@@ -30,7 +30,7 @@
 #include "nsInstall.h" // for error codes
 #include "prmem.h"
 #include "ScheduledTasks.h"
-#include "InstallCleanupDefines.h"
+#include "..\cleanup\InstallCleanupDefines.h"

 #include "nsSpecialSystemDirectory.h"
 #include "nsDirectoryService.h"
Index: nsSoftwareUpdate.cpp
===================================================================
RCS file: /cvsroot/mozilla/xpinstall/src/nsSoftwareUpdate.cpp,v
retrieving revision 1.82
diff -u -r1.82 nsSoftwareUpdate.cpp
--- nsSoftwareUpdate.cpp        2001/05/23 01:21:04     1.82
+++ nsSoftwareUpdate.cpp        2001/06/01 01:00:51
@@ -49,7 +49,7 @@
 #include "nsInstallTrigger.h"
 #include "nsInstallVersion.h"
 #include "ScheduledTasks.h"
-#include "InstallCleanupDefines.h"
+#include "..\cleanup\InstallCleanupDefines.h"

 #include "nsTopProgressNotifier.h"
 #include "nsLoggingProgressNotifier.h"
Index: nsAppRunner.cpp
===================================================================
RCS file: /cvsroot/mozilla/xpfe/bootstrap/nsAppRunner.cpp,v
retrieving revision 1.279.2.2
diff -u -r1.279.2.2 nsAppRunner.cpp
--- nsAppRunner.cpp     2001/05/31 04:40:36     1.279.2.2
+++ nsAppRunner.cpp     2001/06/01 01:02:15
@@ -65,7 +65,7 @@
 #include "nsIWindowWatcher.h"
 #include "nsProcess.h"

-#include "InstallCleanupDefines.h"
+#include "..\..\xpinstall\cleanup\InstallCleanupDefines.h"

 // Interfaces Needed
 #include "nsIXULWindow.h"


Anyway, then I tried to build xpfe/bootstrap and I'm getting this build problem:
S:\mozilla\xpfe\bootstrap>nmake /f makefile.win

Microsoft (R) Program Maintenance Utility   Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.

nsAppRunner.cpp
nsSetupRegistry.cpp
nsWindowCreator.cpp
nsNativeAppSupportBase.cpp
nsNativeAppSupportWin.cpp
showOSAlert.cpp
NMAKE : fatal error U1073: don't know how to make
'..\..\dist\WIN32_D.OBJ\bin\components\mozucth.lib'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual
Studio\VC98\Bin\NMAKE.EXE"' : return code '0x2'
Stop.

Have you seen this before? 
I'm making real good progress within the last 3 hrs...
got link errs from 1625 down to 640 now.  :-)
can you send me what you've done so far?
STATUS: I am now down to 21 unresolved externals, after spending many hours on 
this over the weekend.  :-)

dprice, we should hookup later today.
STATUS: 
dprice and I just spent another 1.5 hr and got it down to 11 link err.  I just 
passed him my diff, makefile.win and my build output result, and he will try to 
pick this up and get it working on his tree...  :-)

The goal is to try get his stuff reviewed and checked into the branch as soon as 
we can... 
 
Depends on: 85536
Assignee: dprice → waterson
No longer depends on: 85536
taking for now...
Quick update on the Win32 build status on STATIC_BUILD_20010523_BRANCH:

- fixed the GFX problem by splitting GFX into two libraries, gkgfx and
  gkgfxwin

  - had to re-order build so parent directory is built before child

  - had to add |_declspec(export)| and |_declspec(import)| stuff (under
    auspices of NS_GFX) to several classes

- cleaned up some bustage when building on Win95.

Still to do:

- Finish meta-component stuff for mail and psm. This is almost done; attaching
  work-in-progress patch to apply to the new branch.

Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → mozilla0.9.2
Depends on: 85536
Ok, meta-module stuff is ready and working on the new branch. The crypto module
builds (and works, even!), and the mail module builds if you apply the patch
from bug 85536.

So _now_ what's left is

- getting the commercial build working
- figuring out what we wanna do with the packager
- getting some QA on the branch
Depends on: 85770
cathleen, can you r= the above changes? leaf, sr=? They're large, but
mechanical. Here's the gist.

First, we want to explicitly call out component libraries so that we can either
build them as standalone DLLs when doing a ``dynamic'' build (like we do now),
or create a static library that we'll link into the final exectuable when doing
a ``static'' build. To do this, we set the LIBRARY_NAME variable to what we want
the DLL to be named (in the former case), or what we want the static library to
be named (in the latter).

If we're doing a static build, then we also need to know the |NSGetModule| entry
point into the component, so that we can glom these together into an
automatically-generated jump-table as the final part of the build. To do this,
we set the COMPONENT_NAME variable to the C++ symbol that is declared with
NS_IMPL_NSGETMODULE in the component. (This information is simply ignored in the
dynamic build.)

The static build also needs to differentiate between the ``sub-libraries'' that
are linked together to create the final ``component library'', and the
``dependent libraries'' that the comopnent relies upon. Examples of the former
are layoutbase_s.lib and layouthtmlbase_s.lib, which are linked together to
create the final layout.lib. An example of the latter is gkgfx.lib, which the
layout component depends on, but isn't actually linked into layout.lib. To make
this distinction, I introduced the SUB_LIBRARIES variable to contain the
sub-libraries, and left LLIBS to contain any dependent libraries.

Second, we need to call out any ``utility libraries'' that need to get linked
into the final executable, but aren't part of any component. For example, GFX,
zlib, and the old imglib code. We do this by setting EXPORT_LIBRARY=1.

Finally, we need to do both the above for any ``meta-components'' that we
create. A meta-component is a gargantuan DLL that's created out of several
single component libraries (e.g., ``mail'' combines all of the mail components).
To this end, there is a META_COMPONENT variable, which duplicates the above
behavior, but makes the build remember that the libraries should be associated
with said meta-component, instead of the final executable.

To achieve the above, I ripped out the logic that was ``hard-coded'' to know
about building DLLs (e.g., MAKE_OBJ_TYPE=DLL), and moved it to some generic
rules in rules.mak, shuffled LLIBS into SUB_LIBRARIES, etc.

Like the changes that cls made to the Unix build system, we now collect the
COMPONENT_NAME and LIBRARY_NAME values into files that we use to produce the
final bits that we'll link together. Because nmake doesn't have the fancy string
munging capabilities that gmake does, I had to whack dll.inc and exe.inc so that
I could insert a list of libraries to link against.

I think that's pretty much it for build system changes. I'll break the
code-level changes up into different bugs, and then post a unified patch back
here in case anyone want to look at it in its full glory.
Depends on: 86025
Depends on: 86027
r=cathleen 
for win32 build system changes  :-)
sr=leaf (after merge conflicts with the trunk). it even builds on windows 98!
Depends on: 86958
Keywords: footprint, meta
Keywords: donttest
Target Milestone: mozilla0.9.2 → ---
Hey cathleen, I'm gonna give you this bug, and you can close it out once we
finish fixing 85770 and the other installer-related issues we talked about today...
Assignee: waterson → cathleen
Status: ASSIGNED → NEW
Depends on: 87003
Depends on: 87004
marking FIXED. 
all depending issues are resolved, landed to the tree.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla0.9.3
v fixed.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.