Re: Fixing trunk build on OpenBSD

On 15/02/2012 4:53 a.m., Alex Rousskov wrote:
> 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.

Because some simple objects are constructed in the wrong library? I dont
think so.

IMO there is no reason for libipc to be running those constructors. It
could be pulling the packet data out into a buffer and passing it to a
handler registered by libmgr. Same way UDP packet handling works through
comm_read handlers from the upper level ICP/HTCP/DNS/WCCP components. On
the sending side, the Mgr:: objects inherit from Ipc::TypedMsgHdr, so it
could (does already?) provide a virtual pack() function which they
implement to pack themselves into a buffer that Ipc::Send...() controls.

I got very close to that with the Subscription attempt earlier. Just
went way too far on the handler split.

Working like UDP will also make it very easy to do some magic foo under
the hood on Windows etc and actually use localhost UDP for the
transport, instead of raw Unix sockets on POSIX systems.

>
> 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.

Amos
Received on Wed Feb 15 2012 - 13:49:01 MST