Don't export intermediate libraries

RESOLVED FIXED in mozilla1.9alpha1

Status

enhancement
P2
normal
RESOLVED FIXED
19 years ago
Last year

People

(Reporter: cls, Assigned: benjamin)

Tracking

Trunk
mozilla1.9alpha1
All
Linux
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments, 3 obsolete attachments)

Maintenance bug.  With the landing of the static binary changes, we set
EXPORT_LIBRARY to specify which libs are the ones used in the final link.  It
stands to reason that all other libs are intermediate cruft that do not need to
be symlinked/copied into $(DIST) lest someone think that they are free to use
them.  Unfortunately, we assume that these libs are in $(DIST)/lib when we build
some of the final libraries so their link lines need to change.
Priority: -- → P3
Target Milestone: --- → mozilla1.0
Target Milestone: mozilla1.0 → mozilla0.9.9
Target Milestone: mozilla0.9.9 → Future
*** Bug 170975 has been marked as a duplicate of this bug. ***
Mass reassign to default build config owner
Assignee: cls → mozbugs-build
Priority: P3 → --
Mass reassign of Build/Config bugs to Leaf.
Assignee: mozbugs-build → leaf
Target Milestone: Future → ---
Assignee: leaf → cmp
Product: Browser → Seamonkey
Mass reassign of open bugs for chase@mozilla.org to build@mozilla-org.bugs.
Assignee: chase → build
Assignee: build → nobody
Priority: -- → P2
Product: Mozilla Application Suite → Core
QA Contact: granrosebugs → build-config
Assignee: nobody → benjamin
Severity: minor → enhancement
Target Milestone: --- → mozilla1.9alpha
This patch requires other treewide work which is not complete yet, so I'm not requesting review yet. It stops shipping static libs by default to dist/lib, and it changes the static build system to look in <objdir>/staticlib instead of dist/lib (so that the libs in dist/lib can be stuff we actually want to ship like xpcomglue etc).
This patch is an example of what needs to happen treewide (but this patch is just for XPCOM): libs which are intended to become SHARED_LIBRARY_LIBS are not shipped anywhere and are referenced from their tree locations.

I'd like someone to look over the concept and then grant blanket-r to make these kinds of changes treewide.
Chase/cls/bryner/mento, anyone care to validate or pick at my approach here?
Comment on attachment 211181 [details] [diff] [review]
static libs in XPCOM

Have at it!
Attachment #211181 - Flags: review+
Attachment #213067 - Flags: review?(mark) → review+
I still have a few platform-specific fixes to land before this lands, but this is the meaty part of removing intermediate and static libs from dist/lib... intermediate libs aren't installed anywhere: static libs are installed to <objdir>/staticlib
Attachment #217323 - Flags: review?(mark)
...reading...
Attachment #217323 - Attachment is obsolete: true
Attachment #217323 - Flags: review?(mark)
this one build Firefox at least for me on mac, with some changes that I checked in today
Attachment #220677 - Attachment is obsolete: true
Attachment #220744 - Flags: review?(mark)
Attachment #220744 - Flags: review?(mark) → review?(ted.mielczarek)
Ted, I haven't updated that patch in a while, so it may need unbitrotting or fixing. If you want to actually test it, I can attach a new one; this one is probably only good for inspection.
I won't have time to give this a good look until probably Monday, so if you can attach a fresh patch by then I'd appreciate it.
Un-bitrotted, probably.

I'm doing a full set of builds (three platforms, multiple products, static and nonstatic).
Attachment #253788 - Flags: review?(ted.mielczarek)
Attachment #220744 - Attachment is obsolete: true
Attachment #220744 - Flags: review?(ted.mielczarek)
Comment on attachment 253788 [details] [diff] [review]
Move static libs to staticlib/, rev. 2.2

r=me
Looks good, I don't envy the massive search and replace that goes along with this!
Attachment #253788 - Flags: review?(ted.mielczarek) → review+
Attachment #255911 - Flags: review?(timeless)
Attachment #255911 - Flags: review?(timeless) → review+
Fixed on trunk!

$ find dist/lib
dist/lib/libasn1.a
dist/lib/libcertdb.a
dist/lib/libcerthi.a
dist/lib/libcrmf.a
dist/lib/libcryptohi.a
dist/lib/libdbm.a
dist/lib/libfreebl.a
dist/lib/libfreebl3.chk
dist/lib/libfreebl3.dylib
dist/lib/libjar.a
dist/lib/libmozjs.dylib
dist/lib/libmozz.a
dist/lib/libnspr4.a
dist/lib/libnspr4.dylib
dist/lib/libnss.a
dist/lib/libnss3.dylib
dist/lib/libnssb.a
dist/lib/libnssckbi.dylib
dist/lib/libnssckfw.a
dist/lib/libnssdev.a
dist/lib/libnsspki.a
dist/lib/libpk11wrap.a
dist/lib/libpkcs12.a
dist/lib/libpkcs7.a
dist/lib/libplc4.a
dist/lib/libplc4.dylib
dist/lib/libplds4.a
dist/lib/libplds4.dylib
dist/lib/libsectool.a
dist/lib/libsecutil.a
dist/lib/libsmime.a
dist/lib/libsmime3.dylib
dist/lib/libsoftokn.a
dist/lib/libsoftokn3.chk
dist/lib/libsoftokn3.dylib
dist/lib/libssl.a
dist/lib/libssl3.dylib
dist/lib/libunicharutil_external_s.a
dist/lib/libunicharutil_s.a
dist/lib/libxpcom.dylib
dist/lib/libxpcom_core.dylib
dist/lib/libxpcomglue.a
dist/lib/libxpcomglue_s.a
dist/lib/libxpistub.dylib
dist/lib/libxpt.a

Not all of these need to be there (I'd argue none of the .dylibs need to be there), but that can be handled separately.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
This probably caused bug 372593.
Depends on: 374921
No longer depends on: 374921
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.