default library search path is configured by `ldconfig' utility or /etc/ld.so.sonf, /etc/ld.so.conf.d/* under Linux
oh, that's not quite true :)
ldconfig (or ld.so.conf) configures patch for dynamic loader :)
On 04/10/2012 02:20 PM, Sampsa Laine wrote:
(Oleg, others correct me if I'm wrong)
I think -lpcap tells it to dynamically link to the libpcap.so lib, so
the code is not included in the output executable.
Not quite...-lpcap tells the linker to look for *either* a static or a
dynamic library, whichever it's able to find.
Then at runtime the system searches the library search path for the
.so (set by an env var, can't recall precise name) and loads the code
from there.
This is OS-dependent, but it's usually LD_LIBRARY_PATH. Some OSs have
a system-wide configuration for that (Solaris has the "crle" system for
example) which can then be overridden by the environment variable.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Is it possible to explain what the magic does?
More precisely: what is the difference between an .a and an .so library?
-l<libname> links executable with library `lib<libname>' (.so is used by defalt, unless -static is specified in which case .a is used)
-L<dir> adds <dir> to library search path
default library search path is configured by `ldconfig' utility or /etc/ld.so.sonf, /etc/ld.so.conf.d/* under Linux
.a is a static library
.so is a dynamic library
Hans,
(Oleg, others correct me if I'm wrong)
I think -lpcap tells it to dynamically link to the libpcap.so lib, so the code is not included in the output executable.
Then at runtime the system searches the library search path for the .so (set by an env var, can't recall precise name) and loads the code from there.
This is called dynamic linking.
Linking with an .a file links the code into the output executable and produces a so called statically linked binary.
That's what I recall, anyhow - I mostly mess around with Python nowadays :)
Sampsa
On 10 Apr 2012, at 21:12, H Vlems wrote:
Oleg,
thank you very much indeed: simh now correctly builds the vax, vax780 and
pdp11 executables. Others too, but these matter most for me.
Is it possible to explain what the magic does?
More precisely: what is the difference between an .a and an .so library?
How on earth does -lpcap point to /usr/lib?
If the answers are too lengthy or are too complex for an old Algol
programmer then say so ;-)
Hans
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Oleg Safiullin
Verzonden: maandag, april 2012 8:04
Aan: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] building simh
On 04/09/2012 12:33 PM, hvlems at zonnet.nl wrote:
Dave,
I figured that out too. My system doesn't have a libpcap.a file! If I know
how to build one then all would be fine.
To build SimH manually wothout libpcap.a (but with libpcap.so.*) you should
edit `makefile' and replace line
NETWORK_OPT = -DUSE_NETWORK -isystem /usr/local/include
/usr/local/lib/libpcap.a
with
NETWORK_OPT = -DUSE_NETWORK -isystem /usr/local/include -lpcap
and then do
mkdir BIN
make USE_NETWORK=yes
On 04/10/2012 02:12 PM, H Vlems wrote:
Is it possible to explain what the magic does?
More precisely: what is the difference between an .a and an .so library?
I detailed this a few posts ago. .a is a static library, .so is a
shared library.
How on earth does -lpcap point to /usr/lib?
-lpcap tells the linker to look in every directory in the library
search path to find either libpcap.a or libpcap.so.
This library lives in /usr/lib on most systems, but the simh makefile
hard-coding that path (and hard-coding it to only find the static
library) is a big mistake.
-Dave
If the answers are too lengthy or are too complex for an old Algol
programmer then say so ;-)
Hans
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Oleg Safiullin
Verzonden: maandag, april 2012 8:04
Aan: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] building simh
On 04/09/2012 12:33 PM, hvlems at zonnet.nl wrote:
Dave,
I figured that out too. My system doesn't have a libpcap.a file! If I know
how to build one then all would be fine.
To build SimH manually wothout libpcap.a (but with libpcap.so.*) you should
edit `makefile' and replace line
NETWORK_OPT = -DUSE_NETWORK -isystem /usr/local/include
/usr/local/lib/libpcap.a
with
NETWORK_OPT = -DUSE_NETWORK -isystem /usr/local/include -lpcap
and then do
mkdir BIN
make USE_NETWORK=yes
--
Dave McGuire, AK4HZ
New Kensington, PA
Oleg,
thank you very much indeed: simh now correctly builds the vax, vax780 and
pdp11 executables. Others too, but these matter most for me.
Is it possible to explain what the magic does?
More precisely: what is the difference between an .a and an .so library?
How on earth does -lpcap point to /usr/lib?
If the answers are too lengthy or are too complex for an old Algol
programmer then say so ;-)
Hans
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Oleg Safiullin
Verzonden: maandag, april 2012 8:04
Aan: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] building simh
On 04/09/2012 12:33 PM, hvlems at zonnet.nl wrote:
Dave,
I figured that out too. My system doesn't have a libpcap.a file! If I know
how to build one then all would be fine.
To build SimH manually wothout libpcap.a (but with libpcap.so.*) you should
edit `makefile' and replace line
NETWORK_OPT = -DUSE_NETWORK -isystem /usr/local/include
/usr/local/lib/libpcap.a
with
NETWORK_OPT = -DUSE_NETWORK -isystem /usr/local/include -lpcap
and then do
mkdir BIN
make USE_NETWORK=yes
Indeed...
WOPR$$ ncp tell joshua show exec char
Node Volatile Characteristics as of 9-APR-2012 19:35:23
Executor node = 20.4 (JOSHUA)
Identification = DECnet-20 Version 4.0
Management version = V4.0.0
Service circuit = NI-0-0
CPU type = PDP-11
Loop count = 1
Loop length = 127
Loop Data type = mixed
Incoming timer = 30
Outgoing timer = 60
NSP version = V4.0.0
Maximum links = 65535
Delay factor = 48
Delay weight = 10
Inactivity timer = 120
Retransmit factor = 10
Routing version = V2.0.0
Type = nonrouting IV
Routing timer = 600
Broadcast routing timer = 40
Maximum address = 1023
Maximum circuits = 20
Maximum cost = 100
Maximum hops = 16
Maximum visits = 20
Max broadcast nonrouters = 64
Max broadcast routers = 32
Maximum buffers = 80
Buffer size = 576
Segment buffer size = 576
On Mon, Apr 9, 2012 at 4:08 PM, Johnny Billquist <bqt at softjar.se> wrote:
On 2012-04-09 22:05, Saku Set l wrote:
I did run TOPS-20 on emulator long ago when it was first released to
public. If somebody makes instructions how to get it running on the
HecNet, surely I'll give it a try. On the real machines, I hacked around
TOPS-20's in mid-80's, and got caught, but that's another long story..
Jeez. This have been up before... :-)
.ncp tell sol sho exec cha
Node characteristics as of 9-APR-12 22:06:53
Executor node = 59.10 (SOL)
Identification = Systems Concepts SF CA USA - SC30M - DN-20 4.0, Management version = 4.0.0
Loop count = 1, Loop length = 127
Loop with = Mixed, Incoming timer = 30
Outgoing timer = 60, NSP version = 4.0.0
Maximum links = 65535, Delay factor = 48
Delay weight = 10
Inactivity timer = 120, Retransmit factor = 10
Routing version = 2.0.0, Type = Routing IV
Routing timer = 600
Broadcast routing timer = 40, Maximum address = 1023
Maximum circuits = 20
Maximum cost = 100
Maximum hops = 16, Maximum visits = 20
Maximum broadcast endnodes = 64
Maximum broadcast routers = 32
Maximum buffers = 80, Buffer size = 576
Segment buffer size = 576
.
Just to mention one machine... There are (probably) more...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Looking at this distribution of files from DEC for TOPS-20 V6.1 DECnet --
http://pdp-10.trailing-edge.com/TOPS-20_V6.1_DECnetDistr_7-23-85/index.html -- I saw SETNOD.EXE.
It seems this command is comparable to the NODNAM that you mentioned. I just did a quick test with SETNOD, set up some nodes, saved them to its database, and then used the INSERT command to load them into the monitor. Then I checked in NCP and saw that they were there.
So, I should get everything loaded in via SETNOD.EXE at system startup, I guess.
Thanks for suggesting I look at another utility.
--Marc
On Mon, 09 Apr 2012 23:45:48 +0300, you wrote:
The museum guys posted this user's guide:
http://www.bitsavers.org/pdf/dec/pdp10/TOPS20/V7/USERS.MEM.txt
The full "collection" is at the following address:
http://pdp-10.trailing-edge.com/BB-PBQUC-BM_1990/index.html
These are the latest available manuals (and among them there is the one you
have linked too). I've already read the User's Guide and the System
Manager's Guide, but I find some things not so clear. I'll have to do some
more experiments. :)
Unfortunately the full TOPS-20 Notebook set seems to be unavailable: I've
hunted for it high and low, but to no avail... :-\
G.
The museum guys posted this user's guide:
http://www.bitsavers.org/pdf/dec/pdp10/TOPS20/V7/USERS.MEM.txt
Sampsa
On 9 Apr 2012, at 22:50, gerry77 at mail.com wrote:
On Mon, 09 Apr 2012 22:04:17 +0300, you wrote:
Is anyone on HECnet running TOPS-20?
Just got an account at the machine at the Living Computer Museum, it seems
like a cool OS.
Just in the last few days I've started playing with TOPS-20: my final goal
is to put it online on our DECnet and on the Internet. It's indeed a quite
cool OS, and very significant in the Internet/Unix history timeline.
I'm actually trying to better understand how some security settings work
(e.g. permissions for files-only directories). Maybe I'll ask something on
alt.sys.pdp10 hoping that someone like Mark Crispin will answer. :)
I'd like to share experiences with anyone doing similar experiments. :)
HTH,
G.
