[Top][All Lists]
[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, 28 Oct 2010 16:59:00 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100913 Lightning/1.0b3pre Thunderbird/3.1.3 |
On 10/28/2010 04:16 PM, Eric Blake wrote:
[snip]
>
> That's exactly what gnulib is - a library of source code workarounds for
> broken platform functions. Are you interested in porting your
> libsuacomp fixes into gnulib, so that more GNU programs can support
> Interix out of the box?
(i'll take findutils out of the CC on the next message, and continue (if we
continue) on gnulib only ;))
yeah, right. it would be really cool to see this all merged into gnulib.
however i
see some slight problems (i don't know if we can manage to get around them...).
i'll
briefly describe what i'm doing, and you can decide on your own whether that
fits
somehow into gnulib (as i have not enough knowledge on how gnulib is
used/built/etc.)
suacomp tries to "fix" functions from the SUA libc by overriding them. this
means in
the static case to define the symbol and make suacomp link in before the libc.
in the
shared library case, this is a little more complicated (i'll use fork() as
example):
*) libc.so provides both fork() and _fork().
*) fork() calls _fork().
*) fork() is a weak external, which resolves to the suacomp _fork() if it is
there.
*) suacomp uses dlopen/dlsym to route to the real functions and modify/fix
input/output.
suacomp is linked in before libc, by installing a libc.a and libc.so file to
the PREFIX
(so better don't install suacomp in /usr ;) ), which are ld linker scripts,
assuring
suacomp before libc in all cases.
the only use case i designed all this for, is gentoo prefix (which ought to not
install
into /usr, etc.). i think you heard of it? the initial purpose was to fix
multi-core
cpu problems with make, python, etc. however it grew a little further, so it
has it's
own poll() (select() based).
thinking of gnulib, i can see a lot of potential problems, starting fex, that
gnulib
modules are copied into the packages, rather than gnulib beeing an installed
library
that is linked against (is this true always?).
in gentoo prefix (gentoo main too? idk) there is a "gnulib" ebuild, which
builds a
library of gnulib to fix some system deficiencies, but IIRC it's static only.
i'd
rather like suacomp to be static wherever possible to ease bugfixing, upgrades,
etc.
phew. i'm done ;) hope you didn't fall asleep somewhere on the way ;p
now, do you see any chance to merge the two concepts of gnulib and suacomp (or
isn't
there any need to merge concepts?)?
regards, and thanks for the proposal!
markus
>
>> this is IMHO the best solution, as it takes the responsibility from
>> findutils to work around existing OS bugs,
>
> Agreed - that is the approach that most GNU projects take - isolate the
> platform bugs into wrapper function fixes, so that the rest of the
> project can assume sane POSIX semantics.
>
- Re: findutils on interix, (continued)
- Re: findutils on interix, James Youngman, 2010/10/27
- Re: findutils on interix, Eric Blake, 2010/10/27
- Re: findutils on interix, Markus Duft, 2010/10/28
- Re: findutils on interix, Markus Duft, 2010/10/28
- Re: findutils on interix, James Youngman, 2010/10/28
- Re: findutils on interix, Markus Duft, 2010/10/28
- Re: findutils on interix, James Youngman, 2010/10/28
- Re: findutils on interix, Markus Duft, 2010/10/28
- Re: findutils on interix, Markus Duft, 2010/10/28
- Re: findutils on interix, Eric Blake, 2010/10/28
- Re: findutils on interix,
Markus Duft <=
- Re: findutils on interix, Paolo Bonzini, 2010/10/29
Re: findutils on interix, James Youngman, 2010/10/27