Re: oh yea, that keyboard question

[turnbull@example.com (Stephen J. Turnbull)]

>>>>> "Jim" == Jim Schweizer <schweiz@example.com> writes:

    Jim> I'm still trying to untangle the P's as it were. I think I
    Jim> have the networking stuff setup ok:

    Jim>  # ping localhost reports all packets transmitted and
    Jim> received with no loss;
[snip]
    Jim> dip: can't find library 'libc.so.4'

    Jim> Did I forget to install or write something? I can't find any
    Jim> reference to it in the net-2/net-3 howto or Olaf's
    Jim> Administrator's Guide.

I dunno what happened here, but this is a pretty common problem with
*all* kinds of software, not just networking (it has nothing to do
with networking per se).  There are four kinds of subroutine calls in
Linux:

(1) direct entry into the kernel (eg, sbrk, which manipulates your
    memory allocation)
(2) standard C functions (eg, fopen)
(3) standardized API library functions (eg, from Xlib)
(4) stuff you wrote yourself :-)

Because *everything* uses the standard C library, it makes a lot of
sense to have that library pretty much permanently resident in memory.
Then the programs need to dynamically link into this resident set of
routines.  Thus we say the library is "dynamically linked" (thus, DLL
in Windowze) or "shared."  Making this (a) foolproof, (b) efficient,
and (c) upgradeable is not merely "nontrivial," it's damn near
impossible.  And MenDouKusai.  Thus it only happens for a few very
common libraries - like the ANSI C standard functions.

A normal library (category (4) and most category (3) above) is named
according to the following pattern: libXXX.a.  The shared libraries
(category (2) and some category (3))come in two parts: the library
entry tables that get linked into the user's program, libXXX.sa, and
the actual library object code, libXXX.so.  Aha! you say....

Now, the entry tables (libXXX.sa) will change from version to version
(I'm not sure why this happens, it apparently only happens on major
versions like libc.so.4.5.27 -> libc.so.5.0.9, not on minor revisions
like libc.so.4.5.26 -> libc.4.5.27).  Thus, changes in the shared
libraries will be *neither* upward *nor* downward compatible.

So probably the program in question, dip, was distributed as a binary
linked against libc.so.4, and your modern Slackware normally uses
libc.so.5.  Probably you have a copy of libc.so.4.5.26 or
libc.so.4.7.2 (I think those are the most recent versions, one is
COFF, one is ELF) in /lib, and all you need to do is

# (cd /lib; ln -s libc.so.4.5.26 libc.so.4)
# dip

and life will be wonderful.  If not, you'll have to (a) find a dip
linked against the library you have, or (b) find the appropriate
library and install it.  (b) is not necessarily difficult, but be
*very* careful while you're cd'd to /lib!!

    >> Re: that Japanese keyboard question a while back
    Jim> snip----snip----snip-----
    >> The authors for Run Run Linux are Hane Hideya, Yamada Akira,
    >> and Abe Hironobu.

    Jim> Is there an ISBN # for that, and it it in English or
    Jim> Japanese?

I just dipped into it today in the computer store, but I didn't note
the ISBN :-(.  It's in Japanese.

-- 
                            Stephen J. Turnbull
Institute of Socio-Economic Planning                         Yaseppochi-Gumi
University of Tsukuba                      http://turnbull.sk.tsukuba.ac.jp/
Tennodai 1-1-1, Tsukuba, 305 JAPAN                 turnbull@example.com