Commit Graph

13 Commits

Author SHA1 Message Date
Mike Hommey
8c10235da0 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
203b345279 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
99fdc4c1d6 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
ea02cd029a Bug 920908 - Use EXPAND_PATH_LIBNAME when linking against libxul/libmozalloc. r=gps 2013-09-27 08:07:44 +09:00
Mike Hommey
fcb2bbfcb9 Backout expandlibs part of bug 812179 for breaking bug 603370. r=me 2013-03-06 11:11:43 +01:00
Yati Sagade
999eeb2111 Bug 812179 - Removed hacks for Python < 2.6 from config/ [r=ted] 2013-02-27 22:30:56 +05:30
Ryan VanderMeulen
5f2a19ee6e Revert c39d36167b99 due to a horribly munged backout. 2012-06-10 19:44:50 -04:00
Ryan VanderMeulen
6d6c4efbab Backout the bug 754202 backout due to orange. 2012-06-10 19:37:47 -04:00
Mike Hommey
7800030eb8 Bug 757339 - Make expandlibs commands generate dependencies like gcc does. r=ted 2012-06-08 08:59:02 +02:00
Gervase Markham
82ff7027aa Bug 716478 - update licence to MPL 2. 2012-05-21 12:12:37 +01:00
Mike Hommey
a84cacdc0f 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
40c393b235 Bug 644081 - Use relative paths as much as possible in expandlibs.py. r=ted 2011-03-25 19:50:29 +01:00
Mike Hommey
e0ba81d2eb Bug 584474 part 9 - Replace fakelibs with a more sophisticated library expansion system. r=ted 2011-02-25 15:05:08 +01:00