On Mon, Mar 23, 2015 at 02:54:11PM -0000, [email protected] wrote: > Not sure if this is the best list on which to ask. Please advise if there is > a better one. > > There is something of a 'trick' played with nsmodule linkage in order to > ensure they get grouped correctly. During the course of my experiments I was > caught out when many of the component manager 'create' calls failed. In the > stock moz.build files, xul is specifically set up to have > staticxulXXXstart.obj as the first module and staticxulXXXend.obj as the > last in the linker command, which creates the correct result. > > In staticXULComponentsStart.cpp we have this: > > NSMODULE_DEFN(start_kPStaticModules) = nullptr; > > which resolves to a section of kPStaticModules and a sort key of M. > > If I've understood this correctly does it not make more sense to define > start_kPStaticModules as follows? Note critically that the $key value is now > A so it is first after the sort ... > > ------------snip----------------- > /* Sections on Windows are in two parts, separated with $. When linking, > * sections with the same first part are all grouped, and ordered > * alphabetically with the second part as sort key. */ > # pragma section(".kPStaticModules$A", read) > # undef NSMODULE_SECTION > # define NSMODULE_SECTION __declspec(allocate(".kPStaticModules$A"), > dllexport) > NSMODULE_DEFN(start_kPStaticModules) = nullptr; > ------------snip----------------- > > This (appears to) create the correct results in the .map when linked using > VS*.
The order needs to be ensured for non-Windows platforms, so it doesn't really matter that the Windows build can be made to work without the files being ordered. Mike _______________________________________________ dev-builds mailing list [email protected] https://lists.mozilla.org/listinfo/dev-builds
