Unixware 7.1.1 & SSH
Maui
looking, the sco site had a link to a .fi ftp site, but it looks like they
don't accept guests anymore..
Maui
Larry Rosenman
you'll need
as well
>
>Maui
>
>
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: l...@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Roberto Zini
I've successfully compiled it under UnixWare 7.1.0; if you're
interested, drop me an email.
Best,
Roberto
--
---------------------------------------------------------------------
Roberto Zini email : fr...@strhold.it
Technical Support Manager -- Strhold Sistemi EDP Reggio Emilia(ITALY)
---------------------------------------------------------------------
"Has anybody around here seen an aircraft carrier?"
(Pete "Maverick" Mitchell - Top Gun)
Maui
it..<G>
"Roberto Zini" <fr...@strhold.it> wrote in message
news:3A6D3CBF...@strhold.it...
Matt Schalit
> Thanks for the infor folks. I'll post any "dumps" that I have compiling
> it..<G>
>
> "Roberto Zini" <fr...@strhold.it> wrote in message
> news:3A6D3CBF...@strhold.it...
> > Maui wrote:
> > >
> > > Can anyone direct to a good opensource site for SSH for Unixware 7.1.1
> Been
> > > looking, the sco site had a link to a .fi ftp site, but it looks like
> they
> > > don't accept guests anymore..
> > >
> > > Maui
> >
> > I've successfully compiled it under UnixWare 7.1.0; if you're
> > interested, drop me an email.
> >
> > Best,
> > Roberto
> > --
I have a copy of ssh-1.2.30.tar.gz on my ftp server, which you
can download and compile for yourself at:
ftp://63.194.213.179:710/pub/Random/
It compiles on 7.1.1. Here's what I did to get it to run
on my setup, which is undoubtedly different from yours:
1) gzcat ssh-1.2.30.tar.gz | tar xvopf -
2) cd ssh-1.2.30
3) CC="/bin/cc -Kalloca -Kno_host" LDFLAGS="-I/usr/lib -I/lib \
-I/usr/local/lib -I/usr/ccs/lib -I/usr/ucblib" CPPFLAGS="-L/usr/include \
-L/usr/ccs/include -L/usr/local/include" LIBS=-lgen ./configure \
--host=i586-sco.sysvuw7.1.1 --disable-asm --x-includes=/usr/X/include \
--x-libraries=/usr/X/lib
4) /usr/local/bin/make <--- that's gnu make.
5) /usr/local/bin/make install.
You can add > con.log to the end of #3) if you want
to output all the configure printouts to a file instead of watching
them all scroll by without being able to see them all.
I had /usr/X/bin in my path.
FYI, I think you can just compile ssh-2 instead and it will
work transparently as ssh1 or ssh2, but don't quote me on that.
I tried this build with ssh 10.1.1.3, and it worked, gave me
a login and succeeded logging in. There are no make test or
make check tests in a testsuite.
Why not email Roberto and see what he did? He's a bright guy too.
Cheers,
Matt
Robert Lipe
>I have a copy of ssh-1.2.30.tar.gz on my ftp server, which you
>can download and compile for yourself at:
> ftp://63.194.213.179:710/pub/Random/
>It compiles on 7.1.1. Here's what I did to get it to run
>on my setup, which is undoubtedly different from yours:
> 1) gzcat ssh-1.2.30.tar.gz | tar xvopf -
> 2) cd ssh-1.2.30
> 3) CC="/bin/cc -Kalloca -Kno_host" LDFLAGS="-I/usr/lib -I/lib \
> -I/usr/local/lib -I/usr/ccs/lib -I/usr/ucblib" CPPFLAGS="-L/usr/include \
> -L/usr/ccs/include -L/usr/local/include" LIBS=-lgen ./configure \
> --host=i586-sco.sysvuw7.1.1 --disable-asm --x-includes=/usr/X/include \
> --x-libraries=/usr/X/lib
"-I" doesn't mean to the linker what you seem to want it to mean. Also,
why are you telling cc (incorrectly) to look for things in places that
it knows to look anyway? Of the additional paths you cite, I think
only "/usr/local/..." isn't in the defaults. (And libucb is evil and
should be avoided. OTOH, yu're not linking with -lucb, so I don't know
what that gains you. Why you're trying to -I(include) libraries and
-L(ibrary) includes is also a bit mysterious to me.
Without any testing, I'm wondering if:
CC="/bin/cc -Kalloca -Kno_host" LIBS=-lgen ./configure \
--host=i586-sco.sysvuw7.1.1 --disable-asm --x-includes=/usr/X/include \
--x-libraries=/usr/X/lib
wouldn't actually be as effective.
Matt Schalit
> msch...@pacbell.net (Matt Schalit) writes:
>
> > 3) CC="/bin/cc -Kalloca -Kno_host" LDFLAGS="-I/usr/lib -I/lib \
> > -I/usr/local/lib -I/usr/ccs/lib -I/usr/ucblib" CPPFLAGS="-L/usr/include \
> > -L/usr/ccs/include -L/usr/local/include" LIBS=-lgen ./configure \
> > --host=i586-sco.sysvuw7.1.1 --disable-asm --x-includes=/usr/X/include \
> > --x-libraries=/usr/X/lib
>
> "-I" doesn't mean to the linker what you seem to want it to mean. Also,
> why are you telling cc (incorrectly) to look for things in places that
> it knows to look anyway?
First of all, before you take my answer wrong, as if I am angry
or being a jerk, that's not my intention. I think this says
it all,
> > Date: Thu, 25 Jan 2001 04:08:30 -0800
I was either thinking that listing them in a certain order gets
them searched in that order, or I was thinking that the configure
program would be able to figure out some issues that were returning
a "no." I obvious do not know what directories are searched and
in what order. I've been compiling about 25 different archives
for Uw7.1.1 this last month without the UDK, using either cc or
gcc 2.95.2.1, and there's no end to the problems I face having to
shoehorn in this path of that path to get the configure/compile to
run successfully. Off the top of my head I recall tcl8.3.2,
and db-3.1.17 giving me these issues.
> Of the additional paths you cite, I think only "/usr/local/..."
> isn't in the defaults.
I may be getting confused with gcc, and I whipped this
out in too much haste, way after midnight.
> (And libucb is evil and should be avoided. OTOH, you're not linking
> with -lucb, so I don't know what that gains you.
The configure script was looking for -lucb, so I put it in
this time. I don't know why it was, and I don't want to have to
read and understand the whole confiugre script and the Makefile
in order to determine why it does what it does. If it
doesn't want to use it, then I didn't see the harm in
/usr/ucblib, until you mentioned, without qualification,
nor explanation that it was "evil."
So now I want to know why it's "evil." Searching the
TA's, I see
Search for libucb AND ( UnixWare 7* ) retrieved 0 documents
from 9376 documents.
Ok. How about this ng. I see two posts about libucb,
neither of which are any help and talk about other "stuff"
in libucb. So now I have "evil" "stuff."
Ok. How about comp.unix.sco.programmer. Nothing.
Ok. How about comp.unix.sco.misc. One post. Yours.
So now I have "evil" "evil" "stuff." That's certainly
well documented. Do you have any idea now why I put
it in there? Because there is zero documentation or
help anywhere that I usually look, supporting your assertion
that it's "evil" "evil" "stuff."
Also it's in there because I don't know what I'm doing.
> Why you're trying to -I(include) libraries and
> -L(ibrary) includes is also a bit mysterious to me.
I wasn't aware of another way to get includes or libraries
seen by configure, cc, and ld. I don't know what the flags
really mean, but I can see from the config.log or a make.log
that the includes and libraries statements exist in the cc and
ld statements approximately where I was hoping they would.
> Without any testing, I'm wondering if:
>
> CC="/bin/cc -Kalloca -Kno_host" LIBS=-lgen ./configure \
> --host=i586-sco.sysvuw7.1.1 --disable-asm --x-includes=/usr/X/include \
> --x-libraries=/usr/X/lib
>
> wouldn't actually be as effective.
Yes your example works fine, as long as someone corrects my typo:
i586-sco.sysvuw7.1.1 <---- arrrgggg!
i586-sco-sysv5uw7.1.1 <---- correct as per current config.guess
at gnu.org.
and that person has /usr/X/bin in their path, so config can find xauth.
Thank you very much for helping me to learn how to use cc.
Matt
Robert Lipe
>In article <t71c6ln...@corp.supernews.com>, rober...@usa.net says...
>> msch...@pacbell.net (Matt Schalit) writes:
>> "-I" doesn't mean to the linker what you seem to want it to mean. Also,
>> why are you telling cc (incorrectly) to look for things in places that
>> it knows to look anyway?
>First of all, before you take my answer wrong, as if I am angry
>or being a jerk, that's not my intention. I think this says
>it all,
I'm not trying to be a jerk, either. I'm sorry if the reality was
otherwise. (If I am being one, perhaps you'll allow me to blame it on
being ill and typing with a pounding head and squinting eyes.)
>I was either thinking that listing them in a certain order gets
>them searched in that order, or I was thinking that the configure
>program would be able to figure out some issues that were returning
>a "no."
That's sometimes a good strategy. The average configure script these
days takes somewhat of a sperm approach to finding library interfaces.
It tries a billion different ones in the hopes that one of them will
stick. So don't be too alarmed about seeing an occaisional "no" fly by.
But the tidbit that turned much of your configure line into a placebo
was passing flags for one tool to a different tool.
LDFLAGS="-I/usr/lib -I....
The common use of -I in a cc invocation isn't a linker (ld) flag at all
but rather a c preprocessor flag to change the include search path.
(There actually is a -I that's valid to ld, but you almost certainly
didn't intend to use that here.) But the directories you listed don't
contain includes; they contain libraries. So passing the linker a set
of -I directories is a NOP.
CPPFLAGS="-L/usr/includ...
Similarly, the common use of -L _is_ to the linker (and not the
stand-alone C preprocessor which is what CPPFLAGS controls) and it's to
add a directory of libraries to the search patch for the link. Only the
directories you listed don't contain libraries; they contain includes.
So again, this becomes a NOP.
>in what order. I've been compiling about 25 different archives
>for Uw7.1.1 this last month without the UDK, using either cc or
>gcc 2.95.2.1, and there's no end to the problems I face having to
>shoehorn in this path of that path to get the configure/compile to
>run successfully. Off the top of my head I recall tcl8.3.2,
I haven't built either one of those lately. In general, though, if you
have to manually override anything like this in a configure script, it's
a defect and you should work with the authors to get it fixed. The
whole point of configure is, in fact, to isolate you from this sort of
stuff.
>> (And libucb is evil and should be avoided. OTOH, you're not linking
>> with -lucb, so I don't know what that gains you.
>The configure script was looking for -lucb, so I put it in
>this time. I don't know why it was, and I don't want to have to
My personal recommendation is to never install libucb. Then, when
configure tries to find things in it (that are often less functional
than their standards-blessed counterparts) it will cleanly not find them
and use the (better tested) ANSI/XPG functionality instead.
>So now I want to know why it's "evil." Searching the
It's evil becuase I declared it to be. :-)
I can't find a system with libucb installed on it to cite specific
examples, but libucb is a compatbility crutch for crufty old code
written for BSD systems that hasn't been updated for that newfangled
specs like ANSI/ISO C89. The interfaces tended to be prone to
corruption and the implementations were poor. I found it much more
satisfying to just remove these and let programs fail to find these
crutches and learn to walk on their standards-blessed legs.
>> Why you're trying to -I(include) libraries and
>> -L(ibrary) includes is also a bit mysterious to me.
>I wasn't aware of another way to get includes or libraries
>seen by configure, cc, and ld.
The point was that you reversed the logic. You want to use -I for
include paths and -L for library paths. So
cc -I/usr/local/include -L/usr/local/lib
is a sensible thing to do if you have includes and libraries in /usr/local. but
cc -L/usr/local/include -I/usr/local/lib
is almost certainly not what you want.
>> Without any testing, I'm wondering if:
>>
>> CC="/bin/cc -Kalloca -Kno_host" LIBS=-lgen ./configure \
>> --host=i586-sco.sysvuw7.1.1 --disable-asm --x-includes=/usr/X/include \
>> --x-libraries=/usr/X/lib
>>
>> wouldn't actually be as effective.
>Yes your example works fine, as long as someone corrects my typo:
Good. That supports my theory that those were placebos. :-)
>Thank you very much for helping me to learn how to use cc.
You're welcome. I can't think of any one (small) place all the
pertinent rules are written down. Digesting the compiler, linker, c
preprocessor, libtool, configure documentation is a large intellectual
investment. I just get nervous when I see compiler superstition spread
in the groups. :-)
RJL
Roberto Zini
>
> In article <94lvve$bua$1...@news1.kornet.net>, maui...@soback.kornet.net says...
> > Thanks for the infor folks. I'll post any "dumps" that I have compiling
> > it..<G>
> >
> > "Roberto Zini" <fr...@strhold.it> wrote in message
> > news:3A6D3CBF...@strhold.it...
> > > Maui wrote:
> > > >
> > > > Can anyone direct to a good opensource site for SSH for Unixware 7.1.1
> > Been
> > > > looking, the sco site had a link to a .fi ftp site, but it looks like
> > they
> > > > don't accept guests anymore..
> > > >
> > > > Maui
> > >
> > > I've successfully compiled it under UnixWare 7.1.0; if you're
> > > interested, drop me an email.
> > >
> > > Best,
> > > Roberto
> > > --
[munch]
Hi !
You can find SCO OpenServer 5.0.4, 5.0.5+ and UW7.1+ versions
of the OpenSSH 2.2.0p1 package at the following URL:
ftp://drake.strhold.it/sco_security
They're compressed TARballs of the destination directory which
is set to /usr/local/ssh; so, first create that dir and then
uncompress + extract the tarball file into it.
Please read the README.ssh file before actually downloading
and using the packages.
Hope this helps !
Matt Schalit
rober...@usa.net says...
> ...
Thanks for the followup. It made me laugh a bunch of
times and was nice to read first thing in the morning.
Be well,
Matt