Re: [Tapioca-devel] autoconf guru needed

[Richard F. <rj...@fi...>]

Grrr....

Does anybody have any clue why the glibc folks define functions in the
headers that are guaranteed to fail?  I don't....

Anyway, this should work:

AC_CACHE_CHECK(for working setlogin, tc_cv_have_setlogin, [
  AC_TRY_RUN([
#include <unistd.h>
int main() { return setlogin("fooey"); }
], tc_cv_have_setlogin="yes", tc_cv_have_setlogin="no", tc_cv_have_setlogin="yes")
])

if test ${tc_cv_have_setlogin} = "yes"; then
  AC_DEFINE(HAVE_SETLOGIN)
fi

You might want to change the tc_cv names to our standard (I chose tc_ for
"Tapioca Config").  Note that the default for cross-compiling is "yes", so
a cross-compile to a linux target will get things wrong.  So you probably
still want to do the setenv, and then add the setlogin call if
HAVE_SETLOGIN is defined.



On Fri, 27 Jul 2001, Eric Lee Green wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Okay, here's the deal. On *BSD, setlogin(pwd->pwname) sets the login name
> on my forked process (right before I exec, sigh). On Linux,
> setenv("LOGNAME",pwd->pw_name,1) sets the login name. Easy enough to
> detect, just put a check for whether setlogin exists in the standard
> libraries, right? Nope, WRONG!  setlogin *does* exist in glibc, it just
> always fails!
>
> Okay, anybody, how do I write an autoconf test for something that
> exists, but always fails?
>
> At the moment I just call both of the above, but I'm tired of the
> compiler bitching at me!
>
> Regarding the plumbing, I have reworked somewhat how this is going to work
> in order to use more of other people's code. In particular, I swiped
> inetd.c from OpenBSD and am using it to create some services using the
> standard inetd mechanism, rather than creating my own server. This means I
> will use more ports, but the individual services will be easier to write
> because they will not have to actually handle accepting connections, and
> will be easier to debug because I can debug them from the command line
> rather than having to go over the network to debug them (I remember what a
> pain in the $#%@ that is!). In addition, thanks to tcpwrappers, I can
> make it obey the hosts.allow and hosts.deny files, which many people will
> like, all without me writing any code (though I #ifdef'ed all the RPC
> code out).
>
> tapinetd comes in at a sleek 20k right now, so this isn't exactly pork,
> even if it is overkill for what we need. I use tapinetd rather than the
> system-provided inetd because a) some systems don't have inetd (e.g., Red
> Hat has moved to vinetd), b) I want to keep things in
> /etc/tapioca/tapinetd.conf rather than /etc/inetd.conf, and c) it makes it
> easier to make a boot/root disk than having to copy inetd and inetd.conf
> off the system (not to mention that the system inetd will not be as sleek,
> because it has stuff in it that I've #ifdef'ed out in tapinetd!).
>
> Right now I'm using two ports -- a keymanager port, and an exec port. Call
> the exec port without a proper session key obtained from the key manager,
> and you get bitched at. Or will get bitched at, once I get the key manager
> going :-).
>
> Eric Lee Green          GnuPG public key at http://badtux.org/eric/eric.gpg
> mailto:er...@ba...  Web: http://www.badtux.org
>
>   "Emacs is a nice OS, but a weird editor." -- M.J. Blom
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
>
> iD8DBQE7Yjg83DrrK1kMA04RAuWmAKCJW9VpbBxZjxU9aNcE5f3LlKoWRQCeIgDV
> /b8o0rYfzL7tog3k1fuaOS0=
> =/iC4
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Tapioca-devel mailing list
> Tap...@li...
> http://lists.sourceforge.net/lists/listinfo/tapioca-devel
>

-- 
Richard Fish, Unix/Linux Software Engineer, rj...@fi...