201602 - Implement meta component for static builds that contains all components

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect, P1)

Description

[hacker formerly known as [e-mail]]

mozcomps.dll (formerly known as gecko.dll)

Comment 1

[hacker formerly known as [e-mail]]

http://www.mozilla.org/build/static-build.html#s2.4

Comment 2

[hacker formerly known as [e-mail]]

Attachment: v1.0

This patch allows libmeta_mozcomps.so to be built when mozcomps is given as an
argument to --enable-meta-components .	The mozcomps meta module will contains
all of components that are not part of other meta components when passed
--enable-meta-components=mozcomps[,..] .  To clarify, if crypto & mozcomps are
selected as meta components, libmeta_crypto.so is built and the remainder of
the components will be linked into libmeta_mozcomps.so.  

When building the meta mozcomps library, the application binaries will
automatically revert to their non-static build state.

I wasn't able to smoketest the patch because our meta-modules broke sometime
between Monday and today (bug 201684).

Comment 3

[hacker formerly known as [e-mail]]

Comment on attachment 120223 [details] [diff] [review]
v1.0

Missed a couple of makefiles.

Comment 4

[hacker formerly known as [e-mail]]

Attachment: v1.1

Comment 5

[hacker formerly known as [e-mail]]

Attachment: v1.2

Had to drop back to the moz1.4a release to runtime test the patch.  Discovered
that TK_LIBS needs to be linked in after xpcom & nspr.

Comment 6

[Brian Ryner (not reading)]

Comment on attachment 120281 [details] [diff] [review]
v1.2

>Index: embedding/browser/gtk/src/Makefile.in
>===================================================================
>RCS file: /cvsroot/mozilla/embedding/browser/gtk/src/Makefile.in,v
>retrieving revision 1.40
>diff -u -r1.40 Makefile.in
>--- embedding/browser/gtk/src/Makefile.in	9 Mar 2003 07:08:41 -0000	1.40
>+++ embedding/browser/gtk/src/Makefile.in	12 Apr 2003 02:58:16 -0000
>@@ -64,6 +64,13 @@
> 		GtkPromptService.cpp
> endif
> 
>+# Force applications to be built non-statically
>+# when building the mozcomps meta component
>+ifneq (,$(filter mozcomps,$(MOZ_META_COMPONENTS)))
>+BUILD_STATIC_LIBS=
>+BUILD_SHARED_LIBS=1
>+endif
>+

What exactly happens to libgtkembedmoz with this patch? It normally links in
all of the static components from the basebrowser manifest in a static build. 

What is the function of BUILD_STATIC_LIBS/BUILD_SHARED_LIBS in a makefile that
builds an executable? (what would happen you didn't add this to the makefiles
for the embedding test apps and mozilla-bin?)

>Index: modules/staticmod/Makefile.in
>===================================================================
>RCS file: /cvsroot/mozilla/modules/staticmod/Makefile.in,v
>retrieving revision 1.12
>diff -u -r1.12 Makefile.in
>--- modules/staticmod/Makefile.in	30 Jan 2003 05:53:18 -0000	1.12
>+++ modules/staticmod/Makefile.in	12 Apr 2003 02:58:16 -0000
>@@ -85,23 +113,43 @@
> # Force XPCOM_TRANSLATE_NSGM_ENTRY_POINT to be defined so the macros
> # in nsIGenericFactory.h will come out in the wash.
> DEFINES += -DMETA_MODULE=\"$(LIBRARY_NAME)\" -DXPCOM_TRANSLATE_NSGM_ENTRY_POINT
>+
> ifeq ($(LIBRARY_NAME),meta_mail)
> EXTRA_DSO_LDOPTS += \
>-	$(DIST)/lib/$(LIB_PREFIX)gkgfx.$(LIB_SUFFIX) \
>-	$(DIST)/lib/$(LIB_PREFIX)rdfutil_s.$(LIB_SUFFIX) \
>+	$(LIBS_DIR) \
>+	$(call EXPAND_MOZLIBNAME,xpcom_compat gkgfx rdfutil_s) \

Why does rdfutil_s need to be in the EXPAND_MOZLIBNAME here, but a similar _s
up in intl/ was added to EXTRA_DSO_LDOPTS just like this one used to be?

Comment 7

[hacker formerly known as [e-mail]]

> What exactly happens to libgtkembedmoz with this patch? It normally links in
> all of the static components from the basebrowser manifest in a static build. 

It reverts to it's normal non-static build state just like the executables.

> What is the function of BUILD_STATIC_LIBS/BUILD_SHARED_LIBS in a makefile that
> builds an executable? (what would happen you didn't add this to the makefiles
> for the embedding test apps and mozilla-bin?)

The purpose of that ifdef it to force those executables to be built as they
would be for a non-static build.  If you didn't add them, then you would wind up
linking all of the static components into the executables as you would in a
traditional static build.  This would be bad since those same components are
being linked into libmeta_mozcomps.so as well.

> 
>>Index: modules/staticmod/Makefile.in

>>ifeq ($(LIBRARY_NAME),meta_mail)
>>EXTRA_DSO_LDOPTS += \
>>-	$(DIST)/lib/$(LIB_PREFIX)gkgfx.$(LIB_SUFFIX) \
>>-	$(DIST)/lib/$(LIB_PREFIX)rdfutil_s.$(LIB_SUFFIX) \
>>+	$(LIBS_DIR) \
>>+	$(call EXPAND_MOZLIBNAME,xpcom_compat gkgfx rdfutil_s) \
> 
> 
> Why does rdfutil_s need to be in the EXPAND_MOZLIBNAME here, but a similar _s
> up in intl/ was added to EXTRA_DSO_LDOPTS just like this one used to be?

EXPAND_MOZLIBNAME is just a shortcut for manually typing out the link list.  See
http://lxr.mozilla.org/seamonkey/source/config/rules.mk#106 .   I used it
because I needed to add xpcom_compat in that list and it's always a shared
library.  We've had issues before (notably with NSS) where linking using
/path/libfoo.so caused problems but -L/path/ -lfoo did not.

Comment 8

[hacker formerly known as [e-mail]]

Attachment: v1.3

This patch stops components from being listed twice on the link line.

Comment 9

[hacker formerly known as [e-mail]]

Patch has been checked in.