Commit Graph

13 Commits

Author SHA1 Message Date
Mike Hommey
b4265f0fa8 Bug 1077151 - Always use expandlibs descriptors when they exist. r=mshal
Currently, when there is both an expandlibs descriptor and an actual static
library, expandlibs picks the static library. This has the side effect that
if there are object files in the static library that aren't directly used,
they're dropped when linking, even when they export symbols that would be
exported in the final linked binary.

In most cases in the code base, files are not dropped that way. The most
notable counter-example is xpcomglue, where actually not dropping files
leads to link failure because of missing symbols those files reference
(yes, that would tend to say the glue is broken in some way).

On the opposite side, there is mozglue, which does have both a descriptor
and a static library (the latter being necessary for the SDK), and that
linking as a static library drops files that shouldn't be dropped (like
jemalloc). We're currently relying on -Wl,--whole-archive for those files
not to be dropped, but that won't really be possible without much hassle
in a world where mozglue dependencies live in moz.build land.

Switching expandlibs to use descriptors when they exist, even when there
is a static library (so, the opposite of the current behavior) allows to
drop -Wl,--whole-archive and prepare for a better future. However, as
mentioned, xpcomglue does still require to be linked through the static
library, so we need to make it a static library only.

To achieve that, we make NO_EXPAND_LIBS now actually mean no expandlibs
and use that to build the various different xpcomglues.
2014-10-04 10:33:00 +09:00
Mike Hommey
034163d15c Bug 1059255 - Stop building stdc++compat as a real library. r=mshal
Incidentally, this makes the build fail because stdc++compat.o then appears
twice on the libxul linkage command line. This, in turn, is because
widget/xremoteclient creates both a program and an intermediate library for
libxul. The Program() template adds stdc++compat to the directory data,
which ends up being added to libxul as well. The same kind of issue arises
when linking the gtest-enabled libxul.

While eventually we'll be able to avoid those problems, it's not the case
yet, so work around the issue by making expand-libs skip .desc files that
appear multiple times.
2014-09-11 12:19:28 +09:00
Mike Hommey
3424efc9f3 Bug 1043869 - Derive build dependencies for programs and libraries from make backend data instead of getting them from expandlibs. r=mshal 2014-07-29 08:59:56 +09:00
Mike Hommey
c3db565b17 Bug 920908 - Use EXPAND_PATH_LIBNAME when linking against libxul/libmozalloc. r=gps 2013-09-27 08:07:44 +09:00
Mike Hommey
6a1a76f8ee Backout expandlibs part of bug 812179 for breaking bug 603370. r=me 2013-03-06 11:11:43 +01:00
Yati Sagade
54fcbb6e17 Bug 812179 - Removed hacks for Python < 2.6 from config/ [r=ted] 2013-02-27 22:30:56 +05:30
Ryan VanderMeulen
891e38e528 Revert c39d36167b99 due to a horribly munged backout. 2012-06-10 19:44:50 -04:00
Ryan VanderMeulen
f497d31a0a Backout the bug 754202 backout due to orange. 2012-06-10 19:37:47 -04:00
Mike Hommey
a659d7e6ee Bug 757339 - Make expandlibs commands generate dependencies like gcc does. r=ted 2012-06-08 08:59:02 +02:00
Gervase Markham
ca171eec44 Bug 716478 - update licence to MPL 2. 2012-05-21 12:12:37 +01:00
Mike Hommey
711ac49c3c Bug 719742 - Make expandlibs properly handle the case where OBJ_SUFFIX is .i_o on Linux PGO first pass. r=ted 2012-01-25 10:34:14 +01:00
Mike Hommey
739718b90e Bug 644081 - Use relative paths as much as possible in expandlibs.py. r=ted 2011-03-25 19:50:29 +01:00
Mike Hommey
6ef83c9db5 Bug 584474 part 9 - Replace fakelibs with a more sophisticated library expansion system. r=ted 2011-02-25 15:05:08 +01:00