From: hal@pollux.cs.uga.edu (Hal N. Brooks) Subject: Re: TERM & XWINDOWS REMOTELY Date: 20 Apr 1993 00:10:21 GMT
In article <1qt59g$46o@uniwa.uwa.edu.au> oreillym@tartarus.uwa.edu.au (Michael O'Reilly) writes:
>R Ross Holder Jr (roholdr@ccu.umanitoba.ca) wrote:
>
>: The solution I was persuing was the suggestion of Gene Choi
>: (genie@netcom2.netcom.com). Part of this procedure was to use the program
>: known as "term" to link the remote machine and the linux machine at home
>: together by running term on both. It works very nicely on the remote
>: unix machine - though I get a warning message when I run it:
>
>: ld.so: warning: /ur/lib/libc.so.1.7 has older revision than expected 8
>
>Hmm. Must be a wierd sunos message.
>*flame bait mode on. If this causes you to froth at the mouth use EMAIL!!! *.
>As a result of my experiences developing term, I have
>come to the conclusion that sun's suck. bad. No other machine has
>caused as many problems as %^&*%# suns.
>*flame bait off*.
I'm not taking the bait, but you can check the Sun ld and ld.so man page
to help you understand the runtime warning. What's happening is this:
when you link term, ld looks for libc first in /lib, then /usr/lib, and
then in /usr/local/lib. It's evidently finding libc.so.1.8 before finding
any others. When you run the program, it looks for libc in the order
given in your LD_LIBRARY_PATH environment variable. Since the Makefile.sun
file distributed with term doesn't have any -L options for ld, my guess
is that you've got multiple copies of libc laying around and your
LD_LIBRARY_PATH is not in the order /lib:/usr/lib:/usr/local/lib.
I imagine that Michael's greatest headaches were caused by Sun's select()
system call. I can't blame him for flaming Sun over that.
I will say that when I compiled term on the Sun, I got a lot of
"so and so redefined" warnings, but it works, so I didn't mind!
>
>: But it works. In linux, on my PC at home - when I run term, it just seems
>: to 'hang'. I can run it, but anything typed is just output to the shell
>: once I break out (usually by typing CTRL-Z and killing the job). It could
>: be that there was some kind of error during compilation - compilation was
>: a royal pain on the linux machine. In this case what I need is a binary
>: for sun4 unix and a linux binary that are the _same_ version of term
>: (which is what I think I've got now - version 1.07 or something).
>
>Now this is VERY odd. I developed term on my linux machine, and it
>compiles cleanly. If it is erroring then I can only assume that you
>have an old version of the compiler, or that something is
>mis-installed.
Yes. Term compiled very cleanly under Linux for me. Basically, under a
vanilla installation of the most recent release of SLS (0.99pl6-26).
(In case HJ's reading, I've updated to libc4.3.3 already.)
>
>Also, beware that if you installed useing SLS, there is an antique
>version of term on it already (0.99). Make sure you either remove it,
>or put 107 on your path ahead of /usr/{local/}bin
True. This seems to be the major 'gotcha' for people. I've pointed
that out to some people locally, nationally, and internationally.
>
>: Of course, in order to link with the "term" program running on the sun4
>: unix machine I have to run a terminal program (like minicom) in linux on
>: my PC. The terminal program must be running when I execute term or my
>: modem hangs up.
>
>Try either shelling out of the modem program to run term, or
>suspending it (control-Z or some such). The comms program can be
>alive, but NOT running.
If you're using X, I can't recommend Seyon highly enough. With the
Seyon 2.12 quickKeys, it's as if Seyon and Term were made for each other.
Here's the way my Seyon 2.12 quickkeys are set up for term:
Seyon*quickKey1.visible: True
Seyon*quickKey1.action: \
Transmit("term^M"); ShellCommand("$term 2>/tmp/noise.log");
Seyon*quickKey1.label: TERM
Seyon*quickKey2.visible: True
Seyon*quickKey2.action: Transmit("00000^M");
Seyon*quickKey2.label: EndTerm
The noise.log is optional. I should probably get rid of that now.
>
>: If anyone's got any suggestions/solution to the problem, they would be
>: greatly appreciated.
>
>Michael
I'm very pleased with term. Thanks a ton Michael.
p.s. I'm only following-up to comp.os.linux, because that's the only
one of those half dozen groups I get. Is that what we have to
look forward to if comp.os.linux gets split, shotgun posting?
=============================================================================
Hal N. Brooks Voice: (706) 546-7792 Internet: hal@pollux.cs.uga.edu
=============================================================================