On 23 June 2017 at 02:59, Kinney, Michael D <[email protected]> wrote: > David, > > Constructor order is determined by the build tool through evaluation of each > of the library instance dependencies as declared in the [LibraryClasses] > section of the INF. This is a recursive algorithm to collect all the library > instances because a module uses libs and each lib can use additional libs. > > This process is described in the EDK II Build Specification in Section 8.2.5 > Post processing. > > https://edk2-docs.gitbooks.io/edk-ii-build-specification/content/8_pre-build_autogen_stage/82_auto-generation_process.html#82-auto-generation-process > > If you want a different order, then likely one or more of the lib instances > being linked to a module does not have correct information about its lib > dependencies in the [LibraryClasses] section of the INF. If the dependencies > are specified correctly, then the order generated by the build tool should be > a valid order based on dependencies. There are some cases where there could > be ties, such that the order could be different and still correct, but there > is no way to influence the order between ties. >
Note that constructor dependencies don't apply transitively if an intermediate library in the dependency chain has no constructor. For example, if LibWithConstructorA depends on LibWithoutConstructorB, and the latter depends on LibWithConstructorC, the EDK2 tools don't guarantee that C's constructor has executed when A's constructor is invoked. I think this is a flaw in the implementation, but fixing this results in circular dependencies in many platforms that I have tried. so the best way to deal with this IMO is not to rely on constructor ordering at all, and which means you shouldn't call other libraries from the constructor of a library. -- Ard. _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
