Re: findutils on interix

[Markus Duft]

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