Do you have a completed patch for option [1] (making it work somewhat
on Interix only, and better on Interix+suacomp) at all?
On Thu, May 26, 2011 at 8:10 AM, Markus Duft <markus.d...@salomon.at> wrote:
> On 05/26/11 01:48, James Youngman wrote:
>> On Wed, May 25, 2011 at 10:21 AM, Markus Duft <markus.d...@salomon.at> 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.
>>
>
>
>
