Closed
Bug 920908
Opened 11 years ago
Closed 11 years ago
Use EXPAND_PATH_LIBNAME when linking against libxul/libmozalloc
Categories
(Firefox Build System :: General, defect)
Firefox Build System
General
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla27
People
(Reporter: glandium, Assigned: glandium)
References
Details
Attachments
(1 file, 1 obsolete file)
17.64 KB,
patch
|
gps
:
review+
|
Details | Diff | Splinter Review |
Currently, we're linking against libxul and libmozalloc with the "usual" -Lpath -llib arguments. Except on some platforms (mainly, windows). For various reasons, and to make things better for bug 905973, I want to use EXPAND_PATH_LIBNAME instead. Expandlibs_exec will do the right thing and still use the dynamic library.
Assignee | ||
Comment 1•11 years ago
|
||
While I was here, I removed DYNAMIC_XPCOM_LIBS, which is not used anymore, and both DYNAMIC_XPCOM_LIBS and XPCOM_FROZEN_LDOPTS, that are not used at all in js/src. I also changed expandlibs_exec to use makeutil, and to *not* expose the dynamic libraries as dependencies. This matches the current behaviour. There is, however, an additional dummy *_order_only rule added for these dependencies, which is not directly useful, but will be indirectly used in bug 905973. Note that isDynamicLib won't do the right thing on windows with import libs, which have the same extension as static libs, but this, too, matches the current behavior.
Attachment #810400 -
Flags: review?(gps)
Assignee | ||
Updated•11 years ago
|
Attachment #810400 -
Attachment is obsolete: true
Attachment #810400 -
Flags: review?(gps)
Comment 3•11 years ago
|
||
Comment on attachment 810451 [details] [diff] [review] Use EXPAND_PATH_LIBNAME when linking against libxul/libmozalloc Review of attachment 810451 [details] [diff] [review]: ----------------------------------------------------------------- Seeing a bunch of hardcoded foo in configure.in replaced with dynamic lookup makes me happy. I think. I suppose this increases the risk we accidentally add a new library dependency to libxul, does it not? Conceivably it's possible we start linking against a new non-shipped library, don't notice, and builds blow up. I'm trying to think if that's a valid concern or not.
Attachment #810451 -
Flags: review?(gps) → review+
Comment 4•11 years ago
|
||
Comment on attachment 810451 [details] [diff] [review] Use EXPAND_PATH_LIBNAME when linking against libxul/libmozalloc Review of attachment 810451 [details] [diff] [review]: ----------------------------------------------------------------- There weren't any -L arguments in the configure variables before. I was worried about shared libraries, not static. Derp.
Assignee | ||
Comment 5•11 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/c6cb5b72f8d6
Comment 6•11 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/c6cb5b72f8d6
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla27
Updated•6 years ago
|
Product: Core → Firefox Build System
You need to log in
before you can comment on or make changes to this bug.
Description
•