Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Newsgroups | comp.arch |
| Subject | Re: Windows, was Arm to run within IBM z |
| Date | 2026-04-15 13:51 +0000 |
| Organization | PANIX Public Access Internet and UNIX, NYC |
| Message-ID | <10ro55d$1f4$1@reader1.panix.com> (permalink) |
| References | <10rao08$jv9$1@reader1.panix.com> <memo.20260415122259.25212A@jgd.cix.co.uk> |
In article <memo.20260415122259.25212A@jgd.cix.co.uk>,
John Dallman <jgd@cix.co.uk> wrote:
>In article <10rao08$jv9$1@reader1.panix.com>,
>cross@spitfire.i.gajendra.net (Dan Cross) wrote:
>
>> Systems that desire to have one copy of a library installed in
>> one place suffer from the obvious problem of needing to expose
>> the union of functionality expected of all programs that depend
>> on them, either directly or indirectly.
>
>There are at least three related, but different, use cases for shared
>libraries on Unix-like systems:
I don't know what this has to do with what I wrote that you
quoted, but I'm afraid it's mostly incorrect.
The usual use cases for shared objects are a) sharing of text
and r/o data between processes linked against the same image,
b) providing fixes to libraries without having to relink
programs, and c) providing extensibility via the ability to
dynamically load shared objects into the address space of a
running process, find e.g. callable functions in those objects
by looking up entries in their symbol tables, and accessing
functionality provided by those objects by calling them (using
a well-defined ABI).
The last bit is a particularly powerful thing, and is how a
language interpreter can so easily take advantage of advanced
functionality that is not built-in or written in that language.
C.f. Python and its use in the data processing ecosystem, which
relies heavily on FFI calls to numerical analysis libraries
written in FORTRAN and C.
>1) Breaking up the operating system functionality into manageable-size
>chunks of sensibly related material. This is the case that shared library
>system designers are usually dealing with.
This doesn't make much sense to me. It is not at all clear what
you mean by, "operating system functionality." What do you mean
by "manageable-size chunks of sensibly related material"?
These statements are so vague I can only speculate what they may
mean. You write that this is, "the case that shared library
system designers are usually dealing with", and I confess that I
have no idea what that might possibly mean.
Do you mean something like `libc`? If so, bear in mind that
Unix-style systems have provided libraries for the use of user
space code since approximately the beginning; they did so with
static libraries (".a" files) for at least a decade before Unix
grew support for shared libraries in anything resembling the
modern sense.
>In some cases, notably macOS,
>there are unspoken assumptions that this is _always_ the case, and shared
>libraries have strings embedded in them that are copied into programs
>built against them. The purpose of these strings is to tell the loader
>where to find them. This works fine for libraries that have a canonical
>location in the filesystem, but see below for ones that don't.
Pretty much every dynamic executable has a list of libraries
that must be loaded by the runtime linker; macOS isn't
particularly noteable in this regard, though they chose to stick
with Mach-O and .dylib's as the file format, and not something
like ELF; that makes then a bit of an outlier, but comparing
`otool -L` on my Mac workstation to `ldd` on Linux doesn't show
much that is conceptually different:
```
mac% otool -L /bin/ls
/bin/ls:
/usr/lib/libutil.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1356.0.0)
mac%
```
(Aside: I presume the dependency on `ncurses` is so that `ls`
can figure out how wide the terminal window is for columnated
output; possibly for handling colors or something as well. I
dunno; I try to turn as much of that off as I can.)
```
linux% ldd /bin/ls
linux-vdso.so.1 (0x00007fc9cc29c000)
libcap.so.2 => /usr/lib/libcap.so.2 (0x00007fc9cc23f000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007fc9cc04e000)
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fc9cc29e000)
linux%
```
Of course, there are _some_ variations: Linux has the vDSO,
and macOS has libSystem (it's probably worth nothing that the
system call interface on macOS is opaque, versus linux where the
KBI is rigidly defined; perhaps this is what you meant when you
wrote, "unspoken assumptions that this is _always_ the case"
above).
>2) Breaking up applications into related chunks of functionality. This
>can be helpful for organisation of code, for producing commercial
>applications with subsets of "full" functionality, and so on. The
>important point here is that the shared libraries are used by a single
>application, or a suite of related applications. On macOS, this is
>tackled by some special values in the embedded strings that tell the
>loader to look in a filesystem location relative to the application. That
>avoids the need for an application to have a fixed installation directory,
>which implies that you can't have two different versions installed.
Huh. That's an interesting idea, but really it's something that
is facilitated by having shared objects, not something that was
(or is) a primary motivating factor for shared libraries in the
first place.
>3) The fairly rare case of shared libraries intended as "software
>components," to be used in many different applications, but which are
>_not_ extensions to the operating system. Different applications may (and
>likely do) have different versions of such libraries. On macOS, this
>requires the application developer to modify the embedded strings in the
>shared library before linking against it. Apple provide a tool for doing
>this, but it's fairly obscure. The stuff I work on is in this category.
Actually, I'd posit that this is very common.
Everything that I installed from homebrew that cares about, say,
the PNG library is picking up a single shared object:
/opt/homebrew/opt/libpng/lib/libpng16.16.dylib.
Again, the motivation was primarily sharing; any program using
the same shared objects running concurrently shares the text,
read-only data, and metadata of those objects with every other
such program, as opposed to each statically linked binary
getting its own copy. It does so at the expense of some
additional bookkeeping in the operating system, but the overhead
is not that bad.
- Dan C.
Back to comp.arch | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Arm to run within IBM z Michael S <already5chosen@yahoo.com> - 2026-04-04 21:34 +0300
Re: Arm to run within IBM z quadi <quadibloc@ca.invalid> - 2026-04-04 20:39 +0000
Re: Arm to run within IBM z Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-04 22:08 +0000
Re: Arm to run within IBM z quadi <quadibloc@ca.invalid> - 2026-04-04 23:32 +0000
Re: Arm to run within IBM z David Schultz <david.schultz@earthlink.net> - 2026-04-04 20:12 -0500
Re: Arm to run within IBM z George Neuner <gneuner2@comcast.net> - 2026-04-05 00:14 -0400
Re: Arm to run within IBM z David Schultz <david.schultz@earthlink.net> - 2026-04-05 06:12 -0500
Re: Arm to run within IBM z George Neuner <gneuner2@comcast.net> - 2026-04-06 13:09 -0400
Re: Arm to run within IBM z anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-05 09:56 +0000
Re: Arm to run within IBM z David Schultz <david.schultz@earthlink.net> - 2026-04-05 06:17 -0500
Re: Arm to run within IBM z antispam@fricas.org (Waldek Hebisch) - 2026-04-05 16:09 +0000
Re: Arm to run within IBM z antispam@fricas.org (Waldek Hebisch) - 2026-04-05 02:35 +0000
Re: Arm to run within IBM z Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-05 02:56 +0000
Re: Arm to run within IBM z Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-04-04 21:11 -0700
Re: Arm to run within IBM z Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-05 04:34 +0000
Re: Arm to run within IBM z Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-04-04 22:04 -0700
Re: Arm to run within IBM z Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-06 00:30 +0000
Re: Arm to run within IBM z Michael S <already5chosen@yahoo.com> - 2026-04-05 12:51 +0300
Re: Arm to run within IBM z scott@slp53.sl.home (Scott Lurndal) - 2026-04-05 15:04 +0000
Re: Arm to run within IBM z antispam@fricas.org (Waldek Hebisch) - 2026-04-05 16:16 +0000
Re: Arm to run within IBM z Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-06 00:31 +0000
Re: Arm to run within IBM z quadi <quadibloc@ca.invalid> - 2026-04-06 03:57 +0000
Re: Arm to run within IBM z Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-06 07:04 +0000
Re: Arm to run within IBM z MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-04-06 16:35 +0000
Re: Arm to run within IBM z scott@slp53.sl.home (Scott Lurndal) - 2026-04-06 16:48 +0000
Re: Arm to run within IBM z MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-04-06 22:32 +0000
Re: Arm to run within IBM z cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-06 18:41 +0000
Re: Arm to run within IBM z MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-04-06 22:33 +0000
Re: Arm to run within IBM z Michael S <already5chosen@yahoo.com> - 2026-04-07 02:31 +0300
Re: Arm to run within IBM z cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-07 14:41 +0000
Re: Arm to run within IBM z quadi <quadibloc@ca.invalid> - 2026-04-07 02:16 +0000
Re: Arm to run within IBM z Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-07 04:55 +0000
Re: Arm to run within IBM z Thomas Koenig <tkoenig@netcologne.de> - 2026-04-07 05:44 +0000
Re: Arm to run within IBM z Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-07 07:53 +0000
Re: Arm to run within IBM z cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-07 14:44 +0000
Re: Windows, was Arm to run within IBM z John Levine <johnl@taugh.com> - 2026-04-07 19:39 +0000
Re: Windows, was Arm to run within IBM z cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-08 11:39 +0000
Re: Windows, was Arm to run within IBM z John Levine <johnl@taugh.com> - 2026-04-08 19:25 +0000
Re: Windows, was Arm to run within IBM z David Schultz <david.schultz@earthlink.net> - 2026-04-08 15:48 -0500
Re: Windows, was Arm to run within IBM z cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-08 20:54 +0000
Re: Windows, was Arm to run within IBM z Michael S <already5chosen@yahoo.com> - 2026-04-09 00:07 +0300
Re: Windows, was Arm to run within IBM z George Neuner <gneuner2@comcast.net> - 2026-04-09 17:51 -0400
Re: Windows, was Arm to run within IBM z cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-10 11:47 +0000
Re: Windows, was Arm to run within IBM z John Levine <johnl@taugh.com> - 2026-04-11 15:09 +0000
Re: Windows, was Arm to run within IBM z MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-04-11 17:53 +0000
Re: Windows, was Arm to run within IBM z John Levine <johnl@taugh.com> - 2026-04-11 19:20 +0000
Re: Windows, was Arm to run within IBM z Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-11 21:37 +0000
Re: Windows, was Arm to run within IBM z "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-11 14:49 -0700
Re: Windows, was Arm to run within IBM z Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-11 23:37 +0000
Re: Windows, was Arm to run within IBM z George Neuner <gneuner2@comcast.net> - 2026-04-12 23:03 -0400
Re: Windows, was Arm to run within IBM z "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-15 12:55 -0700
Re: Windows, was Arm to run within IBM z cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-12 20:22 +0000
Re: Windows, was Arm to run within IBM z cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-12 20:17 +0000
Re: library confusion, Windows, was Arm to run within IBM z John Levine <johnl@taugh.com> - 2026-04-13 03:36 +0000
Re: library confusion, Windows, was Arm to run within IBM z cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-13 11:27 +0000
Re: Windows, was Arm to run within IBM z jgd@cix.co.uk (John Dallman) - 2026-04-15 12:22 +0100
Re: Windows, was Arm to run within IBM z cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-15 13:51 +0000
Re: Windows, was Arm to run within IBM z scott@slp53.sl.home (Scott Lurndal) - 2026-04-15 14:43 +0000
Re: libraries, Windows, was Arm to run within IBM z John Levine <johnl@taugh.com> - 2026-04-16 01:24 +0000
Re: Windows, was Arm to run within IBM z Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-16 00:49 +0000
Re: Windows, was Arm to run within IBM z Paul Clayton <paaronclayton@gmail.com> - 2026-04-18 22:35 -0400
Re: Windows, was Arm to run within IBM z Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-19 03:04 +0000
Re: Windows, was Arm to run within IBM z George Neuner <gneuner2@comcast.net> - 2026-04-19 00:34 -0400
Re: Windows, was Arm to run within IBM z cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-19 06:03 +0000
Re: Windows, was Arm to run within IBM z Andy Valencia <vandys@vsta.org> - 2026-04-13 09:21 -0700
Re: Windows, was Arm to run within IBM z Thomas Koenig <tkoenig@netcologne.de> - 2026-04-13 17:21 +0000
Re: Windows, was Arm to run within IBM z legalize+jeeves@mail.xmission.com (Richard) - 2026-04-13 18:55 +0000
Re: Windows, was Arm to run within IBM z cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-13 20:15 +0000
Re: Windows, was Arm to run within IBM z Thomas Koenig <tkoenig@netcologne.de> - 2026-04-13 20:20 +0000
Re: Windows, was Arm to run within IBM z legalize+jeeves@mail.xmission.com (Richard) - 2026-04-14 04:51 +0000
Re: Windows, was Arm to run within IBM z Thomas Koenig <tkoenig@netcologne.de> - 2026-04-14 05:54 +0000
Re: Windows, was Arm to run within IBM z legalize+jeeves@mail.xmission.com (Richard) - 2026-04-14 16:23 +0000
Re: Windows, was Arm to run within IBM z Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-13 19:56 +0000
Re: Windows, was Arm to run within IBM z jgd@cix.co.uk (John Dallman) - 2026-04-15 12:22 +0100
Re: Windows, was Arm to run within IBM z cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-15 13:53 +0000
Re: Windows, was Arm to run within IBM z Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-15 22:28 +0000
Re: Windows, was Arm to run within IBM z Thomas Koenig <tkoenig@netcologne.de> - 2026-04-08 19:48 +0000
Re: Windows, was Arm to run within IBM z Stefan Monnier <monnier@iro.umontreal.ca> - 2026-04-09 09:49 -0400
Re: Arm to run within IBM z John Levine <johnl@taugh.com> - 2026-04-07 19:35 +0000
Re: Arm to run within IBM z Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-04-04 20:56 -0700
Re: Arm to run within IBM z Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-05 04:36 +0000
Re: Arm to run within IBM z Michael S <already5chosen@yahoo.com> - 2026-04-05 13:41 +0300
Re: Arm to run within IBM z antispam@fricas.org (Waldek Hebisch) - 2026-04-05 17:04 +0000
Re: Arm to run within IBM z quadi <quadibloc@ca.invalid> - 2026-04-06 04:04 +0000
Re: Arm to run within IBM z Michael S <already5chosen@yahoo.com> - 2026-04-06 12:29 +0300
Re: Arm to run within IBM z quadi <quadibloc@ca.invalid> - 2026-04-05 05:24 +0000
Re: Arm to run within IBM z John Levine <johnl@taugh.com> - 2026-04-05 19:14 +0000
Re: Arm to run within IBM z jgd@cix.co.uk (John Dallman) - 2026-04-05 12:43 +0100
Re: Arm to run within IBM z scott@slp53.sl.home (Scott Lurndal) - 2026-04-05 15:12 +0000
Re: Arm to run within IBM z cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-06 12:21 +0000
Re: Arm to run within IBM z scott@slp53.sl.home (Scott Lurndal) - 2026-04-06 16:46 +0000
Re: Arm to run within IBM z "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-09 02:27 -0700
Re: Arm to run within IBM z scott@slp53.sl.home (Scott Lurndal) - 2026-04-09 14:49 +0000
Re: Arm to run within IBM z Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-06 00:35 +0000
Re: Arm to run within IBM z "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-08 18:41 -0700
csiph-web