> so, a few immediate apparencies. first: no telnet.

what do you mean?  Every distribution i've shipped has included
'telnet,' as far as I know.

or do you mean that it doesn't work in some way?

> second: skey is broke.

This isn't a big surprise, to be honest...

> the
> second of these two I can tackle ( and will :), but the first seems to be
> a symptom of a deeper-rooted problem. I hope everyone can forgive what might 
> be obvious, but I've tried.

what _have_ you tried?


>  here goes.
> 
> gcc keeps complaining about, well a few things. like...
> 
> /usr/include/string.h:55: warning: conflicting types for built-in function `memc
> mp'
> /usr/include/string.h:56: warning: conflicting types for built-in function `memc
> py'
> 
> basically, it thinks that the defs in the headers conflict with the builtins.

I don't know how you got this message; as John Birrell correctly
pointed out, you should only be a message like this if you should be
including <string.h> but _aren't_...

That is, unless something else is ... seriously wrong, as I'm
beginning to supect because of:

> the other, and more important problem gcc keeps barfing on is this:
> 
> commands.c: In function `tn':
> commands.c:2221: warning: address of register variable `__x' requested
> commands.c:2221: invalid `asm': invalid %%xn code
> 
> this shows up, from the looks of it, whereever any of the (htonl, htons, ntohl,
> ntohs) family are used. any clues?

This makes no sense, because the Alpha includes don't do any inline
assembly for ntoh* and hton* at all.


What this _really_ looks like is that you copied your /usr/include
from an i386 system, and are trying to compile.  This would cause both
this problem and your <string.h> problem.  You can't do that, and,
frankly, i have no idea why you would have thought that you could...



chris