bug#58: two configure patches for 1.1.0

[Tim Mooney]

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*,
>
>I see.
>
>> 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
1.0.1 too.

>> 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.
>
>Good idea.
>
>I'll try to apply your patch to 1.0

Thanks,

Tim
-- 
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