Alle giovedì 17 gennaio 2013, Roland McGrath ha scritto:
> First do a commit that is nothing but the rename. That won't affect
> any configuration. Then do a commit adding the missing #include
> (and test it by locally removing the bsd file and doing a Hurd
> build). Finally, do a commit removin
First do a commit that is nothing but the rename. That won't affect any
configuration. Then do a commit adding the missing #include (and test it
by locally removing the bsd file and doing a Hurd build). Finally, do a
commit removing the bsd file.
Thanks,
Roland
Hi,
Alle lunedì 19 novembre 2012, Roland McGrath ha scritto:
> I don't think losing __UL_GETMAXBRK is really a problem. The reason
> for removing it was not specific to Linux, just to the
> implementation being in a shared library. It could be implemented
> in a shared library, at the cost of a
I don't think losing __UL_GETMAXBRK is really a problem. The reason for
removing it was not specific to Linux, just to the implementation being in
a shared library. It could be implemented in a shared library, at the cost
of a GOT reloc for _etext to get the main executable's value (or
conversely
Alle lunedì 19 novembre 2012, Roland McGrath ha scritto:
> sysdeps/posix is appropriate because it's implemented in terms of
> POSIX interfaces.
OK.
> It's bad to lose any functionality, though __UL_GETMAXBRK actually
> being used seems a bit unlikely. But it's easy enough to add it.
Please no
sysdeps/posix is appropriate because it's implemented in terms of POSIX
interfaces.
It's bad to lose any functionality, though __UL_GETMAXBRK actually being
used seems a bit unlikely. But it's easy enough to add it. So I'd do:
First commit: move file verbatim to sysdeps/posix/.
Second commit: ad
Hi,
the current ulimit implementation used for Hurd,
sysdeps/unix/bsd/ulimit.c, is buggy (produces wrong return values,
different function name vs weak alias), while the one for Linux
(sysdeps/unix/sysv/linux/ulimit.c) is better; thus, I decided to remove
the bsd implementation and move the li
