On 4/10/2012 2:27 PM, Dave McGuire wrote:
On 04/10/2012 02:25 PM, Brian Hechinger wrote:
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.
The 'crle' system is best used to completely break your system until you
figure out how to use it properly. :-D
And that it does, quite effectively!
Thankfully I did that on the test/dev E6500 and not either of the production ones. :-D
-brian
On 04/10/2012 02:26 PM, H Vlems wrote:
yes I know you did but the terms static and dynamic library just didn't
register.
Ahh ok. Do you understand the difference now? If not I can type up
an explanation of how it all works.
Are .so and .a libraries interchangeable for the linker, i.e. would this
have worked too:
NETWORK_OPT = -DUSE_NETWORK -isystem /usr/local/include
/usr/lib/libpcap.so
This is compiler-dependent, but it generally should work. The
"proper" way to link against a library, though, is to use "-l<libname>"
on the link command.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 04/10/2012 02:25 PM, Brian Hechinger wrote:
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.
The 'crle' system is best used to completely break your system until you
figure out how to use it properly. :-D
And that it does, quite effectively!
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 04/10/2012 02:24 PM, H Vlems wrote:
Thanks to Oleg's suggestion area 44 will be on-line more often...
Johnny please be so kind to add AR44 (44.1023) to your database as a simh
VAX3900 running VAX/VMS 6.1?
Woohoo!
If I survive the next two days (really bad deadline at work) I'll get
back to hacking on tunnels with Brian, and hopefully Area 61 will be
online shortly thereafter. I plan to run at least one Alpha DS10L
full-time, and likely a VAX or two as well, and then lots of other
machines sporadically. (PDP-11/70, DECsystem-2020, possibly others as I
get them running)
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Dave,
yes I know you did but the terms static and dynamic library just didn't
register.
Are .so and .a libraries interchangeable for the linker, i.e. would this
have worked too:
NETWORK_OPT = -DUSE_NETWORK -isystem /usr/local/include
/usr/lib/libpcap.so
Hans
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Dave McGuire
Verzonden: dinsdag, april 2012 20:18
Aan: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] building simh
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
On 4/10/2012 2:23 PM, Dave McGuire wrote:
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.
The 'crle' system is best used to completely break your system until you figure out how to use it properly. :-D
-brian
Thanks to Oleg's suggestion area 44 will be on-line more often...
Johnny please be so kind to add AR44 (44.1023) to your database as a simh
VAX3900 running VAX/VMS 6.1?
Hans
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
