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. Unless someone can point out a flaw that causes real trouble, I'll continue making pragmatic compromises. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
