I agree with Jeff here. Sorry, Jim. I know life is too complicated to 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. If you want to make an assumption at run time, then you really have to make sure that they way you were compiled encodes versions requirement that demand a platform where your assumptions are true. The libc stub/not-stub checks at build time do not give you this. When you link against a libc that provides a real definition for the foobar syscall, the foobar symbol has the same symbol version as the older libc that defined an ENOSYS stub for foobar. In fact, libc itself may very well be built so that it works on kernel vintages both with or without foobar, so that you cannot tell at link time whether foobar will return ENOSYS at runtime even when using the very same libc. 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. Thanks, Roland -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
