Re: Fixing trunk build on OpenBSD

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<squid3_at_treenet.co.nz>
>>> 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.
Received on Tue Feb 14 2012 - 15:53:47 MST