On 17 March 2016 at 10:11, Laszlo Ersek <[email protected]> wrote: > Adding Ard > > On 03/17/16 08:28, Zeng, Star wrote: >> On 2016/3/17 15:16, Andrew Fish wrote: >>> >>>> On Mar 17, 2016, at 12:10 AM, Gao, Liming <[email protected]> wrote: >>>> >>>> Andrew: >>>> DxeDebugPrintErrorLevelLib has Constructor. DxeHobLib has >>>> Constructor. If DebugLib also has Constructor, the circle of >>>> Constructor() will happen and cause build break. >>>> DxeDebugPrintErrorLevelLib instance increases the possibility of the >>>> circle Constructor(). To resolve it, we can update >>>> DxeDebugPrintErrorLevelLib or DxeHobLib library instance by moving >>>> their constructor into every function API. >>>> >>> >>> Liming, >>> >>> Thanks, I came to the same conclusion. I'm making a local copy >>> DxeDebugPrintErrorLevelLib that does the HOB accesses in the driver >>> without the HobLib and that will solve our issue. I was just surprised >>> the edk2 library was not very useful in the real world. Not to mention >>> the build error message did not help find the real issue, the HOB lib. >> >> I reproduced the issue locally. With the change below to integrate >> HobLibConstructor() to GetHobList(), since all other interface of >> DxeHobLib are just to call GetHobList(), the issue is gone. What is your >> opinion? > > This could make it possible for ArmVirtPkg to remove the > ArmVirtDxeHobLib library instance. That library instance was cloned > exactly in order to break this dependency cycle, see commit ad90df8ac0. > > I think the proposal and the patch are good. >
As I have mentioned in the past, there is a general issue with the EDK2 BaseTools where a transitive dependency on a library that has a constructor is not taken into account when checking for cycles. For example, lib A depends on lib B, which has a constructor lib B depends on lib C, which has no constructor lib C depends on lib D, which has a constructor lib D depends on lib A, which has no constructor In this case, the build will happily succeed, but which constructor executes first (lib B or lib D) is undefined, and there is generally no correct solution as either constructor could transitively depend on the other library having been constructed already. So I think it would be a good step to fix the build tools to detect this case, but I am afraid it will expose errors in many places in the code base. I am kind of glad someone else is hitting this right now, since the last time I brought it up, nobody really cared afair. Thanks, Ard. _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
