> From: "Michael G. Schabert" <mikeride@prez.buf.servtech.com>
>
> Hi all,
> In SPAMming my hard drive with any packages that looked interesting...I've
> noticed that there's a whole lot that do the "cast to pointer from
> integer-", and "cast from integer to pointer of different size", which you
> obviously know about. Most still compile, they just spam my console with
> the warnings. There are some, though, that either don't compile, or don't
> work when they compile. For example, Top gives me:
>
> prez# top
> top: sysctl vm.uvmexp failed: Operation not supported

Regarding those warnings, they are sometimes serious and it means that
there was never a time that an LP64-aware programmer tried the package on
alpha. They can sometimes be trivially fixed by simply including <*std*.h>.

Most of the packages have never been tried on alpha. However, Tim R seems
to be going through them, so that situation should change soon. I will
probably also make a pass over the packages one of these days.

> Now, Im running the ipnatfix kernel, which according to the readme was
> compiled withOUT the uvm, so is that why Top failed? Will that be all
> better once I upgrade to the next snapshot?

All will be UVM on the next snapshot. If you have current source code, your
usr/share/mk/bsd.own.mk will tell programs to compile with UVM. I'm not
sure how top decides, but a few userland programs and obviously the kernel
have compile-time selections for UVM. If they don't agree, a few programs
like ps(1) and top(1) will get confused.

> As an example of one which wouldn't compile, here's where suck left me (on
> the make install part)
>
> ------
> strip suck rpost testhost lmove
> strip: suck: section `.note': error in private data: Memory exhausted
> strip: rpost: section `.note': error in private data: Memory exhausted
> strip: testhost: section `.note': error in private data: Memory exhausted
> strip: lmove: section `.note': error in private data: Memory exhausted

I believe this is a "known problem" with all of the release and snapshot
toolchains: they strip(1) once just fine, but then choke if asked to strip
an already stripped binary.

This will be fixed on the next snapshot.

--Ross