Latest Arla on Latest NetBSD

[Henry B. Hotz]

At 12:10 AM +0200 9/25/01, Love wrote:
>"Henry B. Hotz" <hotz at jpl.nasa.gov> writes:
>
>>  >Do you have a options INSECURE kernel ? (or running with right 
>>securelevel).
>>
>>  Hmmm.  That's normally on because X requires it (or console messages
>>  that don't mess up an X display requires it).  I may have turned it
>>  off because I didn't expect to run X on this machine, but I can't
>>  recall.  Will check when I get home.
>
>If that isn't the case, can you turn on arla debugging in xfs/bsd/xfs_deb.c
>(change x to X) and see if you ever reach the xfs code.

I was confusing UCONSOLE with INSECURE.  I had turned them both off. 
When I rebuilt the kernel with INSECURE on the arla build I had 
sitting there worked just fine.  ;-)

>  > Is this equivalent to using the configure options for that purpose? I
>>  tried that and got some unresolved external reference.  I forget what,
>>  but it was some new variation on a routine that did exist.
>
>On a (as far as I know) clean NetBSD/alpha-1.5.1 I can build
>arla-0.35.6pre7 without any problems (again, with tests commented out in
>the top makefile).
>
>Love
>
>configure \
>         --with-roken=yes \
>         --with-roken-include=/usr/include/krb5 \
>         --with-roken-lib=/usr/lib

Yeah.  I did something like this, but I didn't comment out the tests. 
Does this only override libroken, or does it replace libsl, etc. as 
well?

Looking at the NetBSD package patches most of them are associated 
with guaranteeing which versions of 3 or 4 different libraries are 
loaded.  The package was for 1.4.x which had the MIT kerberos code 
instead of Heimdal, but I have to wonder if the concern isn't valid 
anyway.

If you separate the directory (in the -L option) from the library 
name (in the -l option) then how do you guarantee that the library 
comes from the directory you intended?  The ld versions I have looked 
at will search the last -L directory first, but I don't know if this 
is dependable, portable behavior.
-- 
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu