On 02/13/2012 11:31 PM, Amos Jeffries wrote: > On 23/01/2012 1:44 a.m., Amos Jeffries wrote: >> On 22/01/2012 11:24 p.m., Kinkie wrote: >>> On Sun, Jan 22, 2012 at 4:01 AM, Amos Jeffries<[email protected]> >>> wrote: >>>> On 22/01/2012 12:12 p.m., Henrik Nordström wrote: >>>>> lör 2012-01-21 klockan 22:27 +0100 skrev Kinkie: >>>>>> Hi all, >>>>>> the patch below seems to fix the build on OpenBSD. Does it make >>>>>> sense? >>>>> What is the error? >>>>> >>>>> But yes makes sense.. mgr depends on ipc I think. >>>> >>>> Yes it does. And libipc depends on libmgr right back. >>>> >>>> libmgr defines Mgr Request/Reply types with methods that use IPC, >>>> and libipc >>>> defines the Coordinator functions that create and use the >>>> MgrRequest/Reply >>>> types. I was arguing this out with Alex a while back but never got the >>>> detailed function level analysis done. >>>> >>>> Which library gets detected as broken depends on which source files >>>> have >>>> been touched recently. >>> So I understand that there really is no simple way now to fix things? >>> Maybe slicing off libmgr the Coordinator functions? >>> >> >> I'm sure there is. I just did not finish the analysis that was needed >> to find it. >> >> Amos > > > Okay, I have finally got my fingers into action again on that dependency > loop between libipc and libmgr. > > Here is the symbol table scan results: > > libipc depends on these types (the constructors/destructors): > Mgr::Request > Mgr::Inquirer > Mgr::Response > > Mgr::StoreToCommWriter::close also makes an appearance but seems to be > a loose link that appears only when scanning MGR for provided symbols > used by IPC. But disappears when scanning MGR for required symbols > needed by IPC. > > libmgr depends on: > Ipc::StoreMap > Ipc::SendMessage > Ipc::TypedMsgHdr > Ipc::ImportFdIntoComm > Ipc::Inquirer > Ipc::Forwarder > > The list of these is so long its clear that this is the "lower" level > library and libmgr should be depending on it. > > required by libipc: > U _ZN3Mgr7RequestC1ERKN3Ipc11TypedMsgHdrE > U > _ZN3Mgr8InquirerC1E8RefCountINS_6ActionEERKNS_7RequestERKSt6vectorIN3Ipc11StrandCoordESaIS9_EE > > U _ZN3Mgr8ResponseC1Ej8RefCountINS_6ActionEE > U _ZN3Mgr8ResponseC1ERKN3Ipc11TypedMsgHdrE > U _ZNK3Mgr8Response4packERN3Ipc11TypedMsgHdrE > > > > So, yes Kinkie your patch was right for a first step. But scanning > through Makefile.am I find a LOT of similar reversed lists like that > testRock one which is the only thing failing at present. Kind of strange > why they do not also fail just about everywhere. Makes me nervous about > making that change alone.
FWIW, the solution is probably to split libipc and/or libmgr into two libraries so that the resulting low- and high-level libraries can be properly ordered when linked. Changing the linking order of current libmgr and libipc cannot create a proper order since the libraries are mutually dependent. Platform-specific failures just obscure the fact that the current order is wrong and cannot be fixed without changing the libraries. I cannot object to changing the current order if it seems to help, but we should keep in mind that any perceived improvement is probably illusory. HTH, Alex.
