bug#58: two configure patches for 1.1.0
mooney at dogbert.cc.ndsu.nodak.edu
Mon Feb 28 14:04:51 CET 2000
In regard to: Re: bug#58: two configure patches for 1.1.0, Werner Koch said...:
>On Mon, 28 Feb 2000, Tim Mooney wrote:
>> The reason that SHM_LOCK isn't being detected is that the AC_TRY_COMPILE is
>> being called incorrectly -- its second argument should be a function *body*,
>> GNUPG_CHECK_IPC test in aclocal.m4. This test probably wasn't working on
>(aclocal.m4 is build by aclocal - the actual source is acinclude.m4)
Oh, shoot, sorry. I'm not much of an automake guru. I should have guessed.
>> academic, since mlock on Tru64 systems is documented as failing unless
>> you're the superuser (like HP-UX), but the additions I've made to the
>Does that mean that it even does not work for setuid(root) processes?
I'm not sure, but I think it works if either uid or euid is 0. Again, this
is just what the man page says. I don't yet know if that's the way it
actually works :-). I have had very good luck with Tru64 Unix's man pages,
though, so I tend to trust them.
>> checks should make it more robust in general. Oddly enough once my patch
>> is in place and mlock is found, the "mlock is broken" test outputs no,
>Which is okay. This test is just for some HP/UX versions which simply
>SEGV when you call mlock() without correct permissions.
>> even though the man page for mlock clearly states that superuser priviledges
>> are required to even call the functions (and I'm building as myself, not
>So the SEGV is not a bug but a feature - strange API.
Well, I have access to HP-UX 10.20 but I haven't played with gnupg at all
there -- my desktop system is an alpha-dec-osf4.0f so that's where I generally
experiment most. It could very well be that the problem you found with mlock
on HP-UX is *not* the expected behavior, even by HP engineers :-), but I don't
know. I was basing my comments on the comments in the configure test. :-)
>> The included patch is against 1.1.0.
>1.1.x is the very,very unstable development branch of GnuPG as
>clearly stated in the README file.
:-) Thanks, I did catch that, the only reason I did it against 1.1.0 was
that I assumed that would give it the best chance of applying cleanly to
whatever source you're currently working with. I'm going to try it against
>> this. You might want to add a "How to report bugs" section to the web
>> pages and to the BUGS file in the distribution itself.
>I'll try to apply your patch to 1.0
Tim Mooney mooney at dogbert.cc.ndsu.NoDak.edu
Information Technology Services (701) 231-1076 (Voice)
Room 242-J1, IACC Building (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
More information about the Gnupg-devel