13 Коммитов

Автор	SHA1	Сообщение	Дата
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