Date: Tue, 3 Aug 1999 10:36:30 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: djgpp-workers AT delorie DOT com cc: DJ Delorie Subject: __stub_foo macros in header files Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com This issue was raised by the new feature in GNU `tail' (from the upcoming Textutils), whereby you could say something like "tail --forever --pid=PID" and have `tail' track changes to the file until the process with the named PID exits (presumably, that process was writing the file tracked by `tail'). The implementation calls "kill (pid, 0)" and looks at the value this returned and at errno. Since we don't support sending signals to other processes, `tail' should print a message when invoked with --pid, to the effect that the feature isn't supported. The question is how does the configure script know to configure Textutils for DJGPP so that this message is printed at run time. The Textutils maintainer suggested to use the __stub_foo feature of Autoconf-generated scripts. To wit: if the header, or any other header assert.h pulls in, defines a macro __stub_foo, this tells the configure script that the function `foo', while it exists in the library, is merely a stub that doesn't do anything useful. Using this feature, we could define __stub_fork, which will make it obvious that anything that depends on fork will not work, including passing signals to other processes. (We cannot define __stub_kill, because `kill' actually works when the PID is the caller's pid or zero.) I've seen similar problems in other packages before, but I never understood this __stub feature (it was invented for glibc), so until now the solution was to use #ifdef __MSDOS__, which is not nice. So, the question is: can we define __stub_fork (and maybe a few others) in some and make include it? Can we add this to v2.03? Can this break something? Textutils are very close to release, so it would be nice if we could resolve this now.