Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch > #115698 > unrolled thread
| Started by | Michael S <already5chosen@yahoo.com> |
|---|---|
| First post | 2026-04-04 21:34 +0300 |
| Last post | 2026-04-08 18:41 -0700 |
| Articles | 20 on this page of 95 — 19 participants |
Back to article view | Back to comp.arch
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
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-04-09 00:07 +0300 |
| Subject | Re: Windows, was Arm to run within IBM z |
| Message-ID | <20260409000745.00006f67@yahoo.com> |
| In reply to | #115812 |
On Wed, 8 Apr 2026 20:54:43 -0000 (UTC) cross@spitfire.i.gajendra.net (Dan Cross) wrote: > In article <10r6a2l$57g$1@gal.iecc.com>, John Levine > <johnl@taugh.com> wrote: > >According to Dan Cross <cross@spitfire.i.gajendra.net>: > >>>Maybe he's thinking of what's known as DLL Hell, which resulted > >>>from Microsoft's neglecting to put a version number in DLL > >>>filenames. ... > >> > >>Quite possibly! It's interesting to note that Linux has also > >>suffered from similar issues, exacerbated by libraries that > >>don't handle versioning well. Containers were the solution. > > > >That's kind of sad. > > > >ELF library names include multi-part version numbers, with the plan > >being that if the API changes you bump the major number, while if > >it's a bug fix or otherwise compatible you just bump the minor > >number. Then you symlink the name with the minor version number > >back to the name with just the major number so the lists of imported > >library names just have the major number. This seems to work OK on > >FreeBSD. What happens on linux? > > That works fine, as long as it's actually done. It's when the > plethora of dependencies a given program uses don't play by the > rules that one runs into problems. > > I suppose the issue is that on Windows it cannot be avoided due > to a technical limitation, while on Linux, it can be, but often > is not. > > - Dan C. > In Windows you always have an option of copying desired DLL into the same directory with exe. This directory is always first in DLL search order. So, the only technical limitation here is the size of storage. The rest is about culture.
[toc] | [prev] | [next] | [standalone]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2026-04-09 17:51 -0400 |
| Subject | Re: Windows, was Arm to run within IBM z |
| Message-ID | <2d2gtkpm5ihtc9jkvfm6gq1dojco8fgtaf@4ax.com> |
| In reply to | #115812 |
On Wed, 8 Apr 2026 20:54:43 -0000 (UTC), cross@spitfire.i.gajendra.net (Dan Cross) wrote: >In article <10r6a2l$57g$1@gal.iecc.com>, John Levine <johnl@taugh.com> wrote: >>According to Dan Cross <cross@spitfire.i.gajendra.net>: >>>>Maybe he's thinking of what's known as DLL Hell, which resulted >>>>from Microsoft's neglecting to put a version number in DLL filenames. ... >>> >>>Quite possibly! It's interesting to note that Linux has also >>>suffered from similar issues, exacerbated by libraries that >>>don't handle versioning well. Containers were the solution. >> >>That's kind of sad. >> >>ELF library names include multi-part version numbers, with the plan being that >>if the API changes you bump the major number, while if it's a bug fix or >>otherwise compatible you just bump the minor number. Then you symlink the name >>with the minor version number back to the name with just the major number so the >>lists of imported library names just have the major number. This seems to work >>OK on FreeBSD. What happens on linux? > >That works fine, as long as it's actually done. It's when the >plethora of dependencies a given program uses don't play by the >rules that one runs into problems. > >I suppose the issue is that on Windows it cannot be avoided due >to a technical limitation, while on Linux, it can be, but often >is not. > > - Dan C. NTFS had the capability to hard link files since the beginning: the links were used to support dual (long and 8.3) file names. Other than renaming files, there was no support for it. NTFS 3.0 (Windows 2000) added symlinks. Initially there was utility support (linkd.exe,junction.exe) only for directory symlinks. A utility for manipulating file links (mklink.exe) finally appeared in Vista. Windows executables (programs and libraries) have always had embedded version information, but the LoadLibrary_ functions did not permit specifying what versions were acceptible. [And the developer had to remember to update the build version. Microsoft's tool chain, by default, did not do this automatically.] It was fine to have multiple versions of a DLL in the same directory (modulo unique filenames), but if a program cared about what version it used, it had to check manually and load the DLL explicitly (rather than letting the system loader do it). dotNET tried to fix this - at least for shared (system) DLLs - by maintaining a list of them in the registry. The dotNET loader would look for the right version and load it if possible. However, installers still could break it by overwriting existing files without checking versions. Or by not updating the registry.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-04-10 11:47 +0000 |
| Subject | Re: Windows, was Arm to run within IBM z |
| Message-ID | <10rao08$jv9$1@reader1.panix.com> |
| In reply to | #115824 |
In article <2d2gtkpm5ihtc9jkvfm6gq1dojco8fgtaf@4ax.com>, George Neuner <gneuner2@comcast.net> wrote: >On Wed, 8 Apr 2026 20:54:43 -0000 (UTC), cross@spitfire.i.gajendra.net >(Dan Cross) wrote: > >>In article <10r6a2l$57g$1@gal.iecc.com>, John Levine <johnl@taugh.com> wrote: >>>According to Dan Cross <cross@spitfire.i.gajendra.net>: >>>>>Maybe he's thinking of what's known as DLL Hell, which resulted >>>>>from Microsoft's neglecting to put a version number in DLL filenames. ... >>>> >>>>Quite possibly! It's interesting to note that Linux has also >>>>suffered from similar issues, exacerbated by libraries that >>>>don't handle versioning well. Containers were the solution. >>> >>>That's kind of sad. >>> >>>ELF library names include multi-part version numbers, with the plan being that >>>if the API changes you bump the major number, while if it's a bug fix or >>>otherwise compatible you just bump the minor number. Then you symlink the name >>>with the minor version number back to the name with just the major number so the >>>lists of imported library names just have the major number. This seems to work >>>OK on FreeBSD. What happens on linux? >> >>That works fine, as long as it's actually done. It's when the >>plethora of dependencies a given program uses don't play by the >>rules that one runs into problems. >> >>I suppose the issue is that on Windows it cannot be avoided due >>to a technical limitation, while on Linux, it can be, but often >>is not. > >NTFS had the capability to hard link files since the beginning: the >links were used to support dual (long and 8.3) file names. Other than >renaming files, there was no support for it. > >NTFS 3.0 (Windows 2000) added symlinks. Initially there was utility >support (linkd.exe,junction.exe) only for directory symlinks. A >utility for manipulating file links (mklink.exe) finally appeared in >Vista. > >Windows executables (programs and libraries) have always had embedded >version information, but the LoadLibrary_ functions did not permit >specifying what versions were acceptible. >[And the developer had to remember to update the build version. >Microsoft's tool chain, by default, did not do this automatically.] > >It was fine to have multiple versions of a DLL in the same directory >(modulo unique filenames), but if a program cared about what version >it used, it had to check manually and load the DLL explicitly (rather >than letting the system loader do it). > >dotNET tried to fix this - at least for shared (system) DLLs - by >maintaining a list of them in the registry. The dotNET loader would >look for the right version and load it if possible. > >However, installers still could break it by overwriting existing files >without checking versions. Or by not updating the registry. It occurs to me that another problem with the Linux way of doing things (and really, this is true of any Unix-style system, and probably Windows as well; perhaps any system generally) is that dependencies can be compiled in different ways, and expose different functionality as a result, with no change in version. 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. The number of programs that may depend on a library is obviously unbounded (up to the physical limits of the universe, before someone jumps in with some overly pedantic interpretation of that statement). Computing the required functionality set is thus non-trivial, and if programs make mutually exlusive demands of it, then undecideable generally. Hence, something like containers or localized copies to isolate the transitive closure of dependencies. Wouldn't it be nice if software wasn't such a mess? - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2026-04-11 15:09 +0000 |
| Subject | Re: Windows, was Arm to run within IBM z |
| Message-ID | <10rdo84$e4s$1@gal.iecc.com> |
| In reply to | #115827 |
According to Dan Cross <cross@spitfire.i.gajendra.net>: >It occurs to me that another problem with the Linux way of doing >things (and really, this is true of any Unix-style system, and >probably Windows as well; perhaps any system generally) is that >dependencies can be compiled in different ways, and expose >different functionality as a result, with no change in version. This sounds like "don't do that" territory. If you're going to provide a library, it needs to have a stable API. If the API changes, change the version and document the change. If it can be compiled in different ways that change the API (as opposed to, say, using different optimizations) those need to have different names. I realize that too many people do not understand why this matters. >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, .... Sorry but what's "them" here? The library, some group of libraries, every program that uses the library? -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-04-11 17:53 +0000 |
| Subject | Re: Windows, was Arm to run within IBM z |
| Message-ID | <1775929984-5857@newsgrouper.org> |
| In reply to | #115833 |
John Levine <johnl@taugh.com> posted: > According to Dan Cross <cross@spitfire.i.gajendra.net>: > >It occurs to me that another problem with the Linux way of doing > >things (and really, this is true of any Unix-style system, and > >probably Windows as well; perhaps any system generally) is that > >dependencies can be compiled in different ways, and expose > >different functionality as a result, with no change in version. > > This sounds like "don't do that" territory. If you're going to > provide a library, it needs to have a stable API. Why are APIs changing all the time--it seems to me that the API is not set until one has a stable interface. It also seems to me that when additions are made to an API, the additions go in a different dynamic library than the original. What am I missing ?? > If the > API changes, change the version and document the change. If > it can be compiled in different ways that change the API (as > opposed to, say, using different optimizations) those need to > have different names. I realize that too many people do not > understand why this matters. > > >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, .... > > Sorry but what's "them" here? The library, some group of > libraries, every program that uses the library? >
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2026-04-11 19:20 +0000 |
| Subject | Re: Windows, was Arm to run within IBM z |
| Message-ID | <10re6u3$2glq$1@gal.iecc.com> |
| In reply to | #115836 |
According to MitchAlsup <user5857@newsgrouper.org.invalid>: > >John Levine <johnl@taugh.com> posted: > >> According to Dan Cross <cross@spitfire.i.gajendra.net>: >> >It occurs to me that another problem with the Linux way of doing >> >things (and really, this is true of any Unix-style system, and >> >probably Windows as well; perhaps any system generally) is that >> >dependencies can be compiled in different ways, and expose >> >different functionality as a result, with no change in version. >> >> This sounds like "don't do that" territory. If you're going to >> provide a library, it needs to have a stable API. > >Why are APIs changing all the time--it seems to me that the API >is not set until one has a stable interface. > >It also seems to me that when additions are made to an API, the >additions go in a different dynamic library than the original. > >What am I missing ?? Nothing. I just upgraded MySQL from version 8.0 to 8.4, and the shared library name changed from libmysqlclient.so.21 to libmysqlclient.so.24. There's new stuff in the .24 library that wasn't in the .21. -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-04-11 21:37 +0000 |
| Subject | Re: Windows, was Arm to run within IBM z |
| Message-ID | <10reeuv$247bs$1@dont-email.me> |
| In reply to | #115836 |
On Sat, 11 Apr 2026 17:53:04 GMT, MitchAlsup wrote: > Why are APIs changing all the time--it seems to me that the API is > not set until one has a stable interface. So long as it changes in bacward-compatible fashion, there should be zero impact on existing code. > It also seems to me that when additions are made to an API, the > additions go in a different dynamic library than the original. Shared library versioning is for dealing with backward-incompatible changes to the ABI, not (necessarily) the API. For example, some struct that is passed to a library call might have some more fields added to it. The setup call sets those fields to sensible defaults, so existing client code can be recompiled against the new interface, linked against the new library version, and continue to work unchanged.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-04-11 14:49 -0700 |
| Subject | Re: Windows, was Arm to run within IBM z |
| Message-ID | <10refl2$24g3h$1@dont-email.me> |
| In reply to | #115839 |
On 4/11/2026 2:37 PM, Lawrence D’Oliveiro wrote: > On Sat, 11 Apr 2026 17:53:04 GMT, MitchAlsup wrote: > >> Why are APIs changing all the time--it seems to me that the API is >> not set until one has a stable interface. > > So long as it changes in bacward-compatible fashion, there should be > zero impact on existing code. > >> It also seems to me that when additions are made to an API, the >> additions go in a different dynamic library than the original. > > Shared library versioning is for dealing with backward-incompatible > changes to the ABI, not (necessarily) the API. > > For example, some struct that is passed to a library call might have > some more fields added to it. The setup call sets those fields to > sensible defaults, so existing client code can be recompiled against > the new interface, linked against the new library version, and > continue to work unchanged. Windows on Alpha, windows on MIPS, ect...
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-04-11 23:37 +0000 |
| Subject | Re: Windows, was Arm to run within IBM z |
| Message-ID | <10relv9$264ml$1@dont-email.me> |
| In reply to | #115840 |
On Sat, 11 Apr 2026 14:49:21 -0700, Chris M. Thomasson wrote: > On 4/11/2026 2:37 PM, Lawrence D’Oliveiro wrote: >> >> Shared library versioning is for dealing with backward-incompatible >> changes to the ABI, not (necessarily) the API. >> >> For example, some struct that is passed to a library call might >> have some more fields added to it. The setup call sets those fields >> to sensible defaults, so existing client code can be recompiled >> against the new interface, linked against the new library version, >> and continue to work unchanged. > > Windows on Alpha, windows on MIPS, ect... Windows doesn’t do shared library versioning though, does it?
[toc] | [prev] | [next] | [standalone]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2026-04-12 23:03 -0400 |
| Subject | Re: Windows, was Arm to run within IBM z |
| Message-ID | <53lotk1gn3juic6ej9491vhijkjdlakrt0@4ax.com> |
| In reply to | #115843 |
On Sat, 11 Apr 2026 23:37:13 -0000 (UTC), Lawrence D´Oliveiro <ldo@nz.invalid> wrote: >On Sat, 11 Apr 2026 14:49:21 -0700, Chris M. Thomasson wrote: > >> On 4/11/2026 2:37 PM, Lawrence D’Oliveiro wrote: >>> >>> Shared library versioning is for dealing with backward-incompatible >>> changes to the ABI, not (necessarily) the API. >>> >>> For example, some struct that is passed to a library call might >>> have some more fields added to it. The setup call sets those fields >>> to sensible defaults, so existing client code can be recompiled >>> against the new interface, linked against the new library version, >>> and continue to work unchanged. >> >> Windows on Alpha, windows on MIPS, ect... > >Windows doesn’t do shared library versioning though, does it? Yes and no. For the most part, on Windows you /presume/ that libraries are backward compatible unless the release notes say differently. FWIW, Microsoft does /try/ not to break things: they add new functions instead of changing old ones, etc., and - other than fixing acknowledged bugs - rarely break the behavior of an old function with a new implementation. They haven't always been successful, but in 30 years I can think of only a couple of instances. The binaries absolutely do have version stamps [which you can see by examining the file properties], but Microsoft's tools did not automatically version - the programmer had to do that manually (or script it), and installers generally just replaced an old file with a new file of the same name. The Windows system loader works solely by pathnames and does not have any way to specify what file versions are acceptible. So if some load file is not compatible, typically you don't find out about it until your program misbehaves/crashes trying to use it. Given identical filenames, the only alternative is /not/ to use the toolchain to link your programs and /not/ to use the system loader. Rather you load and use libraries dynamically via LoadLibrary/GetProcAddress [the Windows analogues of dlopen/dlsym]. That way the program can query a DLL's property data and check its version before loading it, and maybe fail gracefully rather than crashing. dotNET tried to fix the problem by using different filenames and recording version information in the Windows registry. The dotNET loader then would look up the library's base name in the registry, see if there was a mapping for a compatible version, and then load that file. This worked (mostly) as long as program installers played by the rules.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-04-15 12:55 -0700 |
| Subject | Re: Windows, was Arm to run within IBM z |
| Message-ID | <10roqg0$16qi3$2@dont-email.me> |
| In reply to | #115843 |
On 4/11/2026 4:37 PM, Lawrence D’Oliveiro wrote: > On Sat, 11 Apr 2026 14:49:21 -0700, Chris M. Thomasson wrote: > >> On 4/11/2026 2:37 PM, Lawrence D’Oliveiro wrote: >>> >>> Shared library versioning is for dealing with backward-incompatible >>> changes to the ABI, not (necessarily) the API. >>> >>> For example, some struct that is passed to a library call might >>> have some more fields added to it. The setup call sets those fields >>> to sensible defaults, so existing client code can be recompiled >>> against the new interface, linked against the new library version, >>> and continue to work unchanged. >> >> Windows on Alpha, windows on MIPS, ect... > > Windows doesn’t do shared library versioning though, does it? DLL HELL? A fun one.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-04-12 20:22 +0000 |
| Subject | Re: Windows, was Arm to run within IBM z |
| Message-ID | <10rguuh$lao$2@reader1.panix.com> |
| In reply to | #115836 |
In article <1775929984-5857@newsgrouper.org>, MitchAlsup <user5857@newsgrouper.org.invalid> wrote: > >John Levine <johnl@taugh.com> posted: > >> According to Dan Cross <cross@spitfire.i.gajendra.net>: >> >It occurs to me that another problem with the Linux way of doing >> >things (and really, this is true of any Unix-style system, and >> >probably Windows as well; perhaps any system generally) is that >> >dependencies can be compiled in different ways, and expose >> >different functionality as a result, with no change in version. >> >> This sounds like "don't do that" territory. If you're going to >> provide a library, it needs to have a stable API. > >Why are APIs changing all the time--it seems to me that the API >is not set until one has a stable interface. > >It also seems to me that when additions are made to an API, the >additions go in a different dynamic library than the original. > >What am I missing ?? It's not that the API is changing. It's that the behavior of the library changes depending on how it's compiled; this may, of course, present as a different interface (indeed, hopefully it does), but that need not be the case. For a example, a number of Unix-y packages over the years have wanted to link against a key/value store library, like DBM, NDBM, GDBM, or Berkeley DB. Which is chosen when and how might be a matter of site policy, but this introduces obvious differences in terms of what files are produced by those packages, what tools are needed to inspect those files, and so on. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-04-12 20:17 +0000 |
| Subject | Re: Windows, was Arm to run within IBM z |
| Message-ID | <10rgul4$lao$1@reader1.panix.com> |
| In reply to | #115833 |
In article <10rdo84$e4s$1@gal.iecc.com>, John Levine <johnl@taugh.com> wrote: >According to Dan Cross <cross@spitfire.i.gajendra.net>: >>It occurs to me that another problem with the Linux way of doing >>things (and really, this is true of any Unix-style system, and >>probably Windows as well; perhaps any system generally) is that >>dependencies can be compiled in different ways, and expose >>different functionality as a result, with no change in version. > >This sounds like "don't do that" territory. If you're going to >provide a library, it needs to have a stable API. If the >API changes, change the version and document the change. If >it can be compiled in different ways that change the API (as >opposed to, say, using different optimizations) those need to >have different names. I realize that too many people do not >understand why this matters. It may not even affect the external API. Consider a library that can, optionally, be compiled to take advantage of multiple threads of execution internally. Software that expects to use that may have to take additional care to avoid conflicts between threads (e.g., perhaps the library takes a reference to a callback function that can be invoked by one of these threads; now, the callback has to be carefully written to accommodate the possibility of concurrent callback invocation, whereas in the single-threaded version, it does not). In this case, I would argue that the API is the same, though I could see an argument that it is not. >>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, .... > >Sorry but what's "them" here? The library, some group of >libraries, every program that uses the library? The set of libraries on the system, any one of which has only one verison installed. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2026-04-13 03:36 +0000 |
| Subject | Re: library confusion, Windows, was Arm to run within IBM z |
| Message-ID | <10rhobd$19hs$1@gal.iecc.com> |
| In reply to | #115859 |
According to Dan Cross <cross@spitfire.i.gajendra.net>: >It may not even affect the external API. Consider a library >that can, optionally, be compiled to take advantage of multiple >threads of execution internally. Software that expects to use >that may have to take additional care to avoid conflicts between >threads (e.g., perhaps the library takes a reference to a >callback function that can be invoked by one of these threads; >now, the callback has to be carefully written to accommodate >the possibility of concurrent callback invocation, whereas in >the single-threaded version, it does not). In this case, I >would argue that the API is the same, though I could see an >argument that it is not. That still sounds like "don't do that." If the library might be multithreaded, the calling program needs to deal with that. A broken program that sometimes works due to luck is still broken. This all seems pretty hypothetical, though. Yes, there are plenty of packages that can be compiled with different flavors of dbm but I don't ever recall seeing one that then exported a library to be used by other applications. I mostly work on FreeBSD so I could believe that linux packages are sloppier. -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-04-13 11:27 +0000 |
| Subject | Re: library confusion, Windows, was Arm to run within IBM z |
| Message-ID | <10rijvo$57h$1@reader1.panix.com> |
| In reply to | #115863 |
In article <10rhobd$19hs$1@gal.iecc.com>, John Levine <johnl@taugh.com> wrote: >According to Dan Cross <cross@spitfire.i.gajendra.net>: >>It may not even affect the external API. Consider a library >>that can, optionally, be compiled to take advantage of multiple >>threads of execution internally. Software that expects to use >>that may have to take additional care to avoid conflicts between >>threads (e.g., perhaps the library takes a reference to a >>callback function that can be invoked by one of these threads; >>now, the callback has to be carefully written to accommodate >>the possibility of concurrent callback invocation, whereas in >>the single-threaded version, it does not). In this case, I >>would argue that the API is the same, though I could see an >>argument that it is not. > >That still sounds like "don't do that." It does. And yet, in the real world, that sort of thing has been a factor in production outages. One can but shake one's head in disbelief at the folly of one's fellows. >If the library might >be multithreaded, the calling program needs to deal with that. >A broken program that sometimes works due to luck is still broken. There was a messy period of time when threading was not quiet ubiqutious yet, but not particularly stable, either. A lot of programs that had been written assuming a single-threaded environment went through a painful period of adjustment as the ecosystem overall went to multithreading. Or, putting it another way, those programs were written when they could assume that their dependencies weren't playing fast and loose with threads under the scenes (or at least not in a way that they could observe), and at some point during the lifecycles of those programs, that all changed. >This all seems pretty hypothetical, though. Yes, there are plenty >of packages that can be compiled with different flavors of dbm but >I don't ever recall seeing one that then exported a library to >be used by other applications. I mostly work on FreeBSD so I >could believe that linux packages are sloppier. It is admittedly hypothetical, though I have actually had the DB thing be an issue; probably due to some assumption in a shell script a sysadmin had written or something. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | jgd@cix.co.uk (John Dallman) |
|---|---|
| Date | 2026-04-15 12:22 +0100 |
| Subject | Re: Windows, was Arm to run within IBM z |
| Message-ID | <memo.20260415122259.25212A@jgd.cix.co.uk> |
| In reply to | #115827 |
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: 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. 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. 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. 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. John
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-04-15 13:51 +0000 |
| Subject | Re: Windows, was Arm to run within IBM z |
| Message-ID | <10ro55d$1f4$1@reader1.panix.com> |
| In reply to | #115920 |
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.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-04-15 14:43 +0000 |
| Subject | Re: Windows, was Arm to run within IBM z |
| Message-ID | <nuNDR.276691$4wI6.266127@fx24.iad> |
| In reply to | #115924 |
cross@spitfire.i.gajendra.net (Dan Cross) writes: >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. This describes a major use of shared objects. The SoC simulator that I work on models a number of discrete SoCs and dynamically loads various shared objects based on the model of SoC being simulated. <snip> > >>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. Indeed, and Unix-like systems have LD_LIBRARY_PATH which supports a mechanism "telling the loader were to look for shared object" and it also supports binding the path into the ELF executable at link time. > >>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. Indeed. Thinks like libxml and libxsl, for example. Or openssl.
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2026-04-16 01:24 +0000 |
| Subject | Re: libraries, Windows, was Arm to run within IBM z |
| Message-ID | <10rpdoa$thu$1@gal.iecc.com> |
| In reply to | #115928 |
According to Scott Lurndal <slp53@pacbell.net>: >>>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. > >Indeed. Thinks like libxml and libxsl, for example. Or openssl. Or for that matter, libc.so which is linked into every linux or BSD program. In my experience that is by far the major use of shared libraries. An important but distant second is loadable code modules like the ones many python libraries use. -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-04-16 00:49 +0000 |
| Subject | Re: Windows, was Arm to run within IBM z |
| Message-ID | <10rpbng$1bne4$3@dont-email.me> |
| In reply to | #115920 |
On Wed, 15 Apr 2026 12:22 +0100 (BST), John Dallman wrote: > There are at least three related, but different, use cases for > shared libraries on Unix-like systems: The first two of which you mention have to do with “libraries”, not necessarily “shared libraries”. > 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. I don’t know why you think these are “rare”. Look at this collection <http://ftp.nz.debian.org/debian/pool/main/> of the standard packages for Debian, just for example: notice how half of the names of the subdirectory groupings begin with “lib”? Those are all shared libraries.
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | comp.arch
csiph-web