tech-userlevel archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: liblzf incompatibility
hi,
can you reply?
YAMAMOTO Takashi
> hi,
>
>> hi,
>>
>>> On Mon, Jun 11, 2012 at 11:45:11PM -0400, Thor Lancelot Simon wrote:
>>>> On Tue, Jun 12, 2012 at 01:58:12AM +0000, YAMAMOTO Takashi wrote:
>>>> > hi,
>>>> >
>>>> > is there a near-future plan to use liblzf for any in-tree stuff?
>>>> > otherwise i'd suggest to disable it because it only causes problems.
>>>> > see PR/46426.
>>>>
>>>> I have code that uses it, both in userspace and the kernel, but I never
>>>> checked it in because I ran into a build problem with src/common. Let me
>>>> see what I can do about both issues.
>
> any progress?
>
> if you don't want to remove it, how about renaming it?
>
> YAMAMOTO Takashi
>
>>>
>>> I am looking at the PR, and I don't really think I agree that our liblzf
>>> is "incompatible with the upstream version".
>>>
>>> Unfortunately, the upstream version can be compiled with either of two
>>> different APIs. I think the bug is actually in programs whose autoconf
>>> logic detects liblzf without detecting which API is in use.
>>
>> as far as i know, there's no reasonable way to detect the compile-time
>> option. so assuming the default is reasonable.
>>
>>>
>>> I chose the API that was more general, which I do think was the correct
>>> decision.
>>
>> i think the option is for users who embed the library into their
>> applications, not for general purpose OSes like us.
>>
>> YAMAMOTO Takashi
>>
>>>
>>> Thor
Home |
Main Index |
Thread Index |
Old Index