Date: Wed, 27 Mar 2002 19:07:03 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: BOUWSMA Beery <freebsd-user@dcf77-zeit.netscum.dyndns.dk> Cc: hackers@freebsd.org, Jonathan Buzzard <jonathan@buzzard.org.uk>, "Garrett A. Wollman" <wollman@freebsd.org> Subject: Re: How to correctly detect POSIX 1003.1b features on FreeBSD? Message-ID: <3CA288D7.E8D042A@mindspring.com> References: <20020312140904.A799@bbn.com> <3C8E742C.7C2E63B8@mindspring.com> <20020312193514.A2226@bbn.com> <20020313005940.GB32410@elvis.mu.org> <20020312201314.A2345@bbn.com> <3C8EB31E.19382903@mindspring.com> <20020312214007.A2526@bbn.com> <200203201907.g2KJ71R03929@beerswilling.netscum.dyndns.dk> <3C990F76.B66BEBF9@mindspring.com> <200203272243.g2RMh0Q01586@beerswilling.netscum.dyndns.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
BOUWSMA Beery wrote: > > Moin, moin! > %s wrote on %.3s, %lld Sep 1993 Your mailer is misconfigured... > > o The mlockall() function takes a flags argument that > > is an inclusive OR of one of several manifest > > constants. > > > > So basically, if you test for the manifest constants before > > making a call that uses them, then you are safe, e.g.: [ ... ] > /usr/bin/gcc -s -o radioclkd radioclkd.o > radioclkd.o: In function `Catch': > radioclkd.o(.text+0xd73): undefined reference to `munlockall' > radioclkd.o: In function `main': > radioclkd.o(.text+0x11e3): undefined reference to `mlockall' > *** Error code 1 FreeBSD is broken. It defines the manifests in scope, but specifically avoids the generation of the system call stubs by include "munlockall.o" and "mlockall.o" in /usr/src2/lib/libc/alpha/sys/Makefile.inc and /usr/src2/lib/libc/i386/sys/Makefile.inc in the "NOASM=" list of objects. Most of these objects have wrappers that are defined in the directory /usr/src2/lib/libc/gen or elsewhere in .c files. Actually, the undefined reference, and the fact that there was a "SYS_munlockall" defined in /usr/include/sys/syscalls.h should have been enough to send you to the libc sources. In any case, there are two possible explanations: o Listing these object files in the "NOASM=" was a mistake. Fix it by removing them from the "NOASM=" lines. o Listing these object files in the "NOASM=" was a bungled attempt to remove these system calls from the namespace, because they were incompletely implemented, and the bungling was in not "#if 0" outing the code and the manifest constants defined for the calls. Fix it by either completing the removal by changing the header files, OR Fix it by completing the implementation, and remove them from the "NOASM=" lines. In either case, my feature test code, though inelegant (as I said it was when I posted it), is correct. That leaves the FreeBSD code, and your code. You need to determine whether or not this was an error in the inclusion process for the calls, or an error in the exclusion process for the calls, befor you will know which is the right thing to do. Alternately, you could just implement the calls for FreeBSD, rather than leaving them stubbed out in the kernel, and then it's irrelevent what the intent was. Patches for implementing one of the options are welcome: o "#if 0" out the manigfests and function prototypes, until the implementation is complete. o Remove the object files from the "NOASM=" list, so that the stubbed-out system calls are defined in libc, even though they are stubbed out. Note: This seems wrong to me o Finish the implementation of the stubbed out system calls, and remove the object files from the "NOASM=" list so that they are properly defined. Pretty trivial to do the first two. The last one is harder; I personally can't really see a lot of value in having the system calls int he first place, so I imagine if the code is going to get done, it will be done by someone who wants to use them. Say someone who wants this badly enough to feature-test for the calls in code they are writing, instead of ignoring them... ;^). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CA288D7.E8D042A>