Jim Meyering píše v Po 24. 08. 2009 v 11:14 +0200:
> Roland McGrath wrote:
> > I agree with Jeff here. Sorry, Jim. I know life is too complicated to
>
> Heh, no need to feel sorry, Roland, unless its for the code pollution.
> It's fixed properly, now. And it's not even that ugly.
>
> > keep track of, but that's just how it is. A robustly-written application
> > really needs to distinguish the build-time vs runtime dependencies it has.
> ...
> > The bottom line is that a properly portable program has to check for ENOSYS
> > at runtime now if the function in question has ever existed in a libc
> > capable of running on a kernel that does not support that system call.
>
> You should know well that we have to strike a balance here.
> There is a limit. Work-arounds like this are worthwhile only
> when the older kernels are in frequent-enough use that not applying
> the work-around would cause significant risk or discomfort.
>
> For example, if I were to make coreutils programs run flawlessly on 2.4.*
> or earlier kernels even when configured/built against modern headers and
> libraries, I suspect there would be significant performance degradation
> in a few key tools. If the degradation didn't impact maintainability,
> and were negligible when running on modern systems, then it might be ok.
AFAIK glibc has its minimum kernel requirement and it should be 2.6.18
(RHEL 5) now. In my opinion the rest of user space should expect this as
the minimal version too.
> Unless someone can point out a flaw that causes real trouble,
> I'll continue making pragmatic compromises.
Dan
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
