bug-findutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: findutils on interix


From: Markus Duft
Subject: Re: findutils on interix
Date: Thu, 26 May 2011 09:10:42 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110506 Lightning/1.0b3pre Thunderbird/3.1.10

On 05/26/11 01:48, James Youngman wrote:
> On Wed, May 25, 2011 at 10:21 AM, Markus Duft <address@hidden> wrote:
>> On 10/28/10 14:43, Markus Duft wrote:
>> [snip]
>>>> another solution that came to my mind: i'm maintaining a library, who's 
>>>> sole purpose is to fix the incorrect behaviour of libc in some regards on 
>>>> interix (libsuacomp [1]). it does some "bad" things already ( ;p ), so 
>>>> maybe i could override the sysconf() function (it already overrides approx 
>>>> 70 functions...), and make it return a sane value in the _SC_ARG_MAX case. 
>>>> that would make the whole problem disappear, and even the first (pushed) 
>>>> patch unnecessary.
>>>
>>> i implemented this, thus findutils can continue like before :) so the 
>>> previous (already pushed) patch is no longer necessary (sorry for consuming 
>>> your time...). actually, the patch is now harmfull, as _SC_ARG_MAX is now 
>>> the only source of "good" information... :[
>>
>> Hi!
>>
>> Sorry for reviving such an old thread... :)
>>
>> i never got an answer on the last mail, and i just saw, that there is still 
>> some quirks going on in my findutils-4.5.9 ebuild regarding this issue.
>>
>> Since i fixed sysconf() for interix through [1], it'd be neccessary to 
>> revert [2] in the findutils git repo. Is that ok for you? Doing so will 
>> require libsuacomp when building findutils. nothing has to be done on the 
>> findutils side though, as suacomp installs itself as libc.{a,so}, and thus 
>> gets in automatically.
>>
>> [1] 
>> https://sourceforge.net/p/suacomp/git/ci/624ac7406b484e60395cac3096121314a3c72efb/
>> [2] 
>> http://git.savannah.gnu.org/cgit/findutils.git/commit/?id=107af5aa0cd8cb6551e12c3ed0c21066f0fbd19f
>>
>> Thanks,
>> markus
>>
>>>
>>> i will still keep an eye on it on my interix boxes whether this works in 
>>> all situations.
>>>
>>> this is IMHO the best solution, as it takes the responsibility from 
>>> findutils to work around existing OS bugs, when there is a library, doing 
>>> this exact thing. there is not even a need to make findutils know 
>>> libsuacomp, as suacomp installs a libc.so and libc.a linker scripts into 
>>> it's prefix. as soon as this path is in the linker path, it works (and in 
>>> gentoo prefix on interix i have linker and compiler wrappers assuring this).
>>>
>>> sorry, that i didn't have that idea earlier, would have saved some work for 
>>> all of us.
>>>
>>> are you ok with this solution?
>>>
>>> markus
>>>
>>>>
>>>> what do you think?
>>>>
>>>> [1] http://sf.net/projects/suacomp
> 
> 
> I'm very happy to make further changes.
> 
> But I'm a little reluctant to make things worse for folks who use
> Interix but not suacomp.     Two options that spring immediately to
> mind:
> 
> 1. effectively disable the workaround for when suacomp ia available on
> Interix, but keep the workaround on Interic when suacomp isn't
> available.

This would need another hunk, too ... :( see [1]. otherwise, the limit is too 
low (the minimum), and it won't work with a reasonable big environment.

> 2. modify the configure script to refuse to build findutils at all on
> Interix unless suacomp is installed [i.e. "make things worse"].
> 

I'd be more for 2, as i'm currently contaminating a whole lot of packages with 
suacomp anyway (gnulib, coreutils, etc.).

However, i'd be ok with 1 (+ the additional patch) too, whatever suits 
findutils better...

[1] 
http://overlays.gentoo.org/proj/alt/browser/trunk/prefix-overlay/sys-apps/findutils/files/findutils-4.5.9-interix-arg_max-50000.patch?rev=59600

Thanks for taking the time :) Markus

> I have a strong preference for (1).
> 
> James.
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]