Talk:Library (computing)

This article is a mix of high-level gloss and a sampling of nitty-gritty details. It talks little about traditional libraries (I just added a couple of sentences at the top). Partially as a result, it has some inaccuracies and potential for people to misunderstand the things that are accurate. I think it needs a rework into a structure something like this:

• What libraries are and the purposes [modularity, code reuse, etc]
• The history
• Types of libraries today
• Any nitty-gritty details necessary.

I like your work so you have my encouragement to proceed. Daniel.Cardenas 13:39, 17 July 2006 (UTC)

Indeed - can't someone put this more into layman's terms? For most of the readers, this is gobbledygook.--173.69.135.105 (talk) 00:52, 26 October 2011 (UTC)

There is an example in this article, but no description of the example at all and this is confusing. — Preceding unsigned comment added by Gachen (talk • contribs) 13:44, 24 June 2012 (UTC)

I agree with the "clarification needed" marking on the first sentence. While it is highly general, I think it be rather opaque to most readers. I would suggest something not as general, but much more concrete:

    In computer science, a library is a set of routines that are made available for use in multiple programs.

(Though I'm much more doubtful that editors would want to include text such the following) this may also be helpful:

    The term arose by analogy to a traditional library that loans books to many patrons.  In a traditional library,
    when one patron has finished using a book, they return it, and it can be used by another patron.  (Of course, for
    a library of computer routines, there is generally no need for programs to wait their turn.  Any number of
    programs could have simultaneously pulled out a copy of the routine for their use, and they do not need to
    "check the routine back in" when they have finished with it.  Editing and altering a routine is a different
    matter.  For that activity, one would generally need to control access.)

    [1] refers to a "card library", which was
    actually used in the early days very much as a traditional library would be used.

MarkGoldfain (talk) 23:32, 12 July 2013 (UTC)

I moved this from the article, since it really belogs here:

• Application Programming Interface
• relationships among linkers, loaders, dynamically linked library, statically linked library, application binary interface
• Common styles of library organization (GUI toolkits, data structure/collection frameworks, I/O libraries, functional programming combinators, metaprogramming protocols, etc.)
• Perhaps a section on Prebinding?
• Need to mention template libraries or generic programming, where most (if not all) of the library code resides in header files. This is distinct from static libraries, as the library code is directly incorporated (and hence intertwined) with user code.

—Frecklefoot 18:36, 18 Sep 2003 (UTC)

Gtfjbl (talk) 02:00, 15 April 2009 (UTC)

I merged many library-related articles to here. The article looks too long but there is a lot of overlaps. The article can be compact. -- Taku 00:36, 22 Sep 2003 (UTC)

Hmm while checking "what links here" from metaprogramming I came across this talk. Would someone care to add information on what a metaprogramming protocol might be? -- Anon

Protocol in this context means method or workflow. One metaprogramming protocol is direct metaprogramming where the programmer writes a program-writing program. A second protocol might be genetic programming where the programmer writes some form of specification and the computer tries to create a program to fulfill it. A third protocol might be indirect metaprogramming via a metaprogramming tool such as Bison where the programmer writes a specification which the tool uses to generate a program. This third protocol is probably what is meant above. -- Derek Ross

Are static linking and dynamic linking supposed to be subtopics of library linking? If so the hierarchy is all skew. --BozMo|talk 15:17, 16 Aug 2004 (UTC)

I think that the topic .Net Assemblies could also be mentioned here. Maybe I'am wrong but arent these the replacement for ActiveX Dll collections? Please discuss this here. tobias

"Dynamic linking systems place the majority of the linker code in the underlying operating system, in which case it is known as a loader."

What does "it" refer to in the sentence above?

This should read something along the lines of the following.

In dynamic linking, the operating system and its libraries contain a run-time linker that resolves the dynamic links in exectuables and dynamic libraries when the application is loaded. Resolution of dynamic links may occure before the application begins execution, or during execution as each link is first executed. In dynamic linking, the term loader is often synonymous with the term linker.

Jsmethers 21:52, 6 December 2005 (UTC)

In the section about Dynamic Linking you say:

 Unix-based systems use a PATH variable of "places to look", which tends to be robust as the PATH rarely changes.

It sounds like you are reffering to the shell PATH variable. As far as I'm aware, none of the common UNIX variants uses the PATH environment variable to lookup shared objects (aka Dynamic Libraries). Instead there are: 1. Pre-defined, system-wide paths configured in files (e.g. /etc/ld.so.conf on Linux. See ldconfig(8) for more) 2. Possibly other environment variables to override/add to the directories in (1) (e.g. LD_LIBRARY_PATH, LD_PRELOAD and others on Linux).

The only resemblance to PATH in the above is that the environment variables, if defined, are usually in the format of the standard PATH variable used by the bourne-shell to lookup programs (i.e. directory names separated by commas).

I remember seeing somewere a list of the variations on this theme (of LD_LIBRARY_PATH equivalents on "exotiq" systems like HPUX and AIX) but can't find it right now, maybe a good place to begin digging is GNU libtool).

I'm adding this here because I'm not sure how to edit the article itself.

Thanks. Penedo 02:35, 28 Apr 2005 (UTC)

BTW, this has been changed in the article (it doesn't refer to PATH on Unix). Some part of this discussion would probably be interesting to include. Nils 17:38, 25 Oct 2005 (UTC).

(3) afaik hardcoded library paths in the binary are also possible ( --rpath parameter, or via libtool) 88.159.74.100 09:10, 9 July 2007 (UTC)

You mean "--rpath or its equivalent, or via libtool" - not every Un*x on the planet uses GNU ld; some use linkers where the flag is "-R", for example. Guy Harris 17:05, 9 July 2007 (UTC)

Dynamic library loading came fairly late to UNIX. Someone should track down the history of this. As I recall, the library path originally was just used during compilation ot specify static libraries. DonPMitchell (talk) 05:33, 13 January 2008 (UTC)

On Linux, the environment variable LD_LIBRARY_PATH, and not PATH, affects the search for dynamic libraries . On Mac OS X, the environment variables DYLD_LIBRARY_PATH and DYLD_FALLBACK_LIBRARY_PATH affect how the dynamic loader searches for libraries. Altering DYLD_LIBRARY_PATH can break the system, as it can allow libraries in the new search path to overshadow system libraries; altering DYLD_FALLBACK_LIBRARY_PATH, on the other hand, allows the dynamic loader to find libraries without negatively impacting the system . ← Michael Safyan (talk) 09:33, 13 January 2008 (UTC)

LD_LIBRARY_PATH originally came from SunOS 4.0's dynamic linking mechanism; that mechanism, complete with LD_LIBRARY_PATH, was passed on to System V Release 4 and thus to Solaris. Linux, FreeBSD and NetBSD also inherited it from those sources when they re-implemented the SunOS 4.0 and/or SVR4 shared library mechanisms, and it passed on to OpenBSD and DragonFly BSD from the BSDs from which they forked. Guy Harris (talk) 19:20, 13 January 2008 (UTC)

This article is nice. I want to put it in the Project's hierarchy up toward the top. We need more participants so I'm going to keep spamming discussion pages on articles like this one till we get some momentum going. Please JOIN Today!:

Computer_Science_Club | CS-WikiProject | CS-Clubhouse | Posted by Quinobi 17:05, 12 July 2005 (UTC)

This article should probably be trimed down to the history of libraries in computer science in general and an introduction to specific types of computer libraries. Information about specific types of computer libraries and implemenations of libaries on specific platforms should probably be seperated out into other pages. For example, information about static libraries, shared libraries, and dynamic libraries should be merged into their respective articles. Information about Microsoft's Dynamic Link Libraries should be merged into the respective article. Jsmethers 02:40, 6 December 2005 (UTC)

The Day oF The Future Library has Yet To Come And Will Be Phenomenal the world over will want to read The Book in there. The World will transcend into the navigational prose of the preceded cosmological particulariousness Of Scorpions who effectively lead the transition from the sublime into the eschatologically glorious, right, UTownBB Peninsularic Homonoidisticalised of The Tall Back? I like Libraries. [(7xgooglecompressormoroomon.ra) 4.59am 1.3.4450.2 13th cycle of the 1st transition in the 3wax over the second millenium installer v1.0000324 internetExecPilatefHL] — Preceding unsigned comment added by 94.173.143.47 (talk) 23:34, 5 November 2021 (UTC)

At the bottom of the "Dynamic Linking" section: "OpenStep used a more flexible system, collecting up a list of libraries from a number of kno or if an incompatible version of the DLL is copied to a place that is earlier in the search, the executable could malfunction or even fail to load. On Windows this is commonly known as DLL hell." It seems that the text after the letters "kno" has been removed. BTW -- excellent article Jsminch 07:04, 16 December 2005 (UTC)

Thanks for the fix. Jsminch 08:28, 20 January 2006 (UTC)

Below 'Object Libraries' there is a sentence.:

Quote:

Remote procedure calls already handled these tasks, but there was no standard RPC system.

Why wasn't that link from 'RPC systems' at the begin on 'Remote procedure calls'?

Thank's Steve

On another wiki page, there was once a "drawbacks" section. It has been removed instead of being moved, saying there was no evidence! IMHO this has been done by somebody who likes dynamic libs too much : there is no real need for evidence since it is "by-design", it only needs citations and sources. Anyway, here is a link : http://en.wikipedia.org/w/index.php?title=Linker&oldid=38884120#Criticism I'd like somebody with more knowledges than me to correctly add this to the Library page. I'll wait until next and do it myself if needed. Thanks. —The preceding unsigned comment was added by Camarade Tux (talk • contribs) 01:25, 6 July 2006 (UTC).

I'm not sure there's anything to add here.

Dynamic linking is often portrayed as universally good, but it has several drawbacks that aren't immediately apparent. Because dynamic linking inherently involves modification of the executable code, it is counter to the principles of virtual memory which is most efficient when each page of the executable image appears the same on disk as in memory, and is unmodified in use. This allows a virtual memory operating system to page parts of the image in and out of main memory at will. The common workarounds for this problem have issues of their own. If the image is copied to a new, modified image via "copy on write", then the modified image takes up new disk space. Also, since it is modified, it cannot be shared between different invocations of the same program in memory (part of the abilities of a multitasking operating system).

Almost all of this is utter rubbish because all modern systems use the approach described in the next sentence:

Microsoft Windows uses a method where each linkage is "double indirect" via a special "linkage page" in the lower part of an .exe image. This allows the main code pages to stay the same, and only this "linkage directory" is changed. However, this adds overhead to every call in the program to other modules or the operating system.

And you term it "utter rubbish", then end up admitting that the Windows scheme adds overhead. Humm, what utter rubbish was that again? I stick to what I said. The dll system needs modification, fixup or in memory tables to get around its issues. We can debate how easy it is or is not to get around those, but the real point is WHY, why was any of this necessary? Saving memory? Even if you think nowdays memory needs saving, virtual memory means that most of a large program is not even loaded into real memory at any given time. Saving disk memory? The vast majority of what an application takes up now is tables, data and pictures (witness the massive increase in program size when we went to graphical windowing programs). Ease in linking other libraries? Static linking worked long before DLL.

Say heres an idea: how about debating ideas intelligently instead of just calling other folks ideas "rubbish". Just an idea. —The preceding unsigned comment was added by 66.28.253.185 (talk • contribs) 14:20, 15 August 2007 (UTC).

The claim that "dynamic linking inherently involves modification of the executable code", at least, is definitely rubbish. It's not the case on most if not all Unix-like systems, where double-indirect linking and position-independent code are used. The page on position-independent code says that Windows doesn't use it for its dynamically-linked libraries.

And at least one reason why dynamic linking is used is to allow a dynamically-linked library to be replaced and have applications use the new library; this allows the implementation of routines to be changed without breaking binary compatibility. For example, on at least some Unix-like systems (Solaris and Mac OS X, for example), and Windows, the low-level traps into the kernel are not part of the application binary interface, and the particular system call traps made by a particular library routine may well change between versions of the OS (and, I think, have changed; I know that the implementations of the Win32 libraries differ substantially between "Windows OT" (Windows 95, Windows 98, Windows Me) and Windows NT. Guy Harris 23:06, 15 August 2007 (UTC)

The overhead involved is so minimal it is hardly worth considering. No, I don't have a source for that, but it's plain to see if you think about it. We're talking basically 1 extra memory access per function call, assuming that page isn't in cache already; in which case it's just 1 extra processor cycle.

Second, dynamic linking means that the final working image of the program will be made up of different modules that may be united together only in the users system. This occurs because each user may have slightly different versions of each dynamically linked module, leading to an exponential number of combinations. Thus, the actual program code run may exist in that exact form only on one user's system. This can lead to odd bugs, and increases testing problems for vendors. As a result, there has been a movement to "static link" modules to programs and eliminate dynamic link modules, even where that capability exists in the operating system.

This is just another description of "DLL Hell", which is already mentioned in this article. JulesH 22:46, 23 September 2006 (UTC)

Library (computer science) → Library (computing) – This is not an academic topic, so a more general name is appropriate. – Smyth\^talk 20:39, 25 September 2006 (UTC)

The current section on Relocation reads as follows (italics are mine):

One wrinkle that the loader must handle is that the location in memory of the actual library data cannot be known until after the executable and all dynamically linked libraries have been loaded into memory. This is because the memory locations used depend on which specific dynamic libraries have been loaded. It is not possible to store the absolute location of the data in the executable, nor even in the library, since conflicts between different libraries would result: if two of them specified the same or overlapping addresses, it would be impossible to use both in the same program. This might change with increased adoption of 64-bit architectures, which offer enough virtual memory addresses to give every library ever written its own unique address range.

That last statement seems absurd to me. There would be have to be some regulatory system established to ensure that "[every version of] every library ever written" used a unique memory address range, such that there was no overlap. And when you add in my comment ("every version of") it readily becomes apparent that exhaustion of the (constantly-shrinking available portion of the) 64-bit address space wouldn't take that long. Not to mention that the overhead of having the operating system perform a virtual <==> physical address mapping for every operation of every library call would probably nullify any benefit such a system would provide. I think the statement was just a whimsical addition, and unless it can be grounded by some reputable citations, I think it should be removed.—Kbolino 04:35, 20 March 2007 (UTC)

A "standard library" is no library, but a set of requirements a library must adhere to. IOW it's more analogous to POSIX being a set of OS requirements than POSIX being an OS. 88.159.74.100 09:08, 9 July 2007 (UTC)

The link: Shared Libraries - 'Linkers and Loaders' by John R. Levine (http://www.iecc.com/linker/linker09.html) does not seem to be working. It would be interesting to find a replacement. I'm not able to propose anything else because I don't know the exact content of the article, sorry. Seriousch 09:19, 19 August 2007 (UTC)

Works fine now. :) Indeterminate (talk) 10:31, 21 January 2008 (UTC)

Why are libraries called libraries? Who invented them? When did they first appear? When were they first standardised?

Alksentrs (talk) 01:04, 25 November 2007 (UTC)

I can't find out why they're called "libraries" (you try doing a google search for "history of libraries" :) ), but I dug up a little bit of information. Indeterminate (talk) 10:31, 21 January 2008 (UTC)

Enderz Game (talk) 20:48, 9 May 2011 (UTC)

I'm pretty sure the inventor of the computer program sub-routine library was a guy named John Wheeler. He was part of the team at the Cambridge Mathematical Laboratory that developed the EDVAC computer in the late 1940's. He co-wrote a book called, "Programs for an electronic digital computer" that was published in 1951 containing a detailed description of the process that they developed for "linking and loading" multiple sub-routines into a single executable program. The caption below one of the pictures at the beginning of the book reads, "The library of tapes on which subroutines are punched is contained in the steel cabinet shown on the left. The operator is punching a program tape on a keyboard perforator. She can copy mechanically tapes taken from the library on to the tape she is preparing by placing them in the tapereader shown in the center of the photograph." He's credited as the inventer of the sub-routine (a "Wheeler Jump" was slang for a sub-routine call) and the team at Cambridge seems to have focused on standardizing the process used to prepare programs for a shared library and defining the conventions as part of deliberated strategy for their re-use.

The above appears to be correct: Wheeler's team built the first documented subroutine library that saw practical use. A few people speculated about the idea before that at least as early as 1947. I've added this to the beginning of the history section. But, it does not jive with the statement "the earliest programming concepts analogous to libraries were intended to separate data definitions from the program implementation" that then goes on to talk about stuff from 1957. I'll be removing that soon unless someone can explain how it fits.Jno.skinner (talk) 03:46, 27 February 2021 (UTC)

Article sez:

OpenStep used a more flexible system, collecting a list of libraries from a number of known locations (similar to the PATH concept) when the system first starts. Moving libraries around causes no problems at all, although there is a time cost when first starting the system.

So this is "more flexible" than what? Presumably "everything else", I guess...:-)

"causes no problems at all" feels just a wee bit glib as well. It's been a long time since I touched Nextstep/OpenStep, so I can't remember exactly what problem this is solving, and why, if the list is only collected at boot time, this means moving libraries around would not cause a problem. Does the kernel detect library or parent directory mvs and automatically update its link path? Does it track libraries by inode or equivalent? How about installing new libraries? Or is what this really is doing is hashing library locations for faster runtime loading? Can individual programs override this if they choose? I'm not feeling the "flexible" here from the information provided.--NapoliRoma (talk) 21:54, 1 January 2008 (UTC)

{{Merge|library (computer science)|date=November 2009}}

69.140.152.55 (talk) 05:21, 11 June 2008 (UTC)

This edit undid a considerable amount of copyediting, along with making the article less future-proof by giving specific examples of Unix-like OSes instead of generalising the issue to all modern instances. It should be reverted. Chris Cunningham (not at work) - talk 18:09, 2 March 2009 (UTC)

I've put some of the changes in question back. It's not "all modern instances", though - not all use .so (e.g., OS X uses .dylib and I think HP-UX uses .sl for 32-bit libraries), and AIX, well, it's AIX, what else can I say. :-)) That section requires some more work. Guy Harris (talk) 00:03, 3 February 2011 (UTC)

Nowhere on this page, the concept of Incremental Linking is described. I would like to know what that concept is, but could not find it. —Preceding unsigned comment added by 209.139.213.73 (talk) 22:20, 1 April 2009 (UTC)

I seem to remember “incremental linking” being a special feature of the Quick C linker (computing) where it was meant to speed up the linking stage if only a small number of object files had changed or something. But this is probably more relevant on one of those two pages rather than here. Vadmium (talk) 03:19, 24 August 2011 (UTC).

"Some operating systems can only link in a library at loadtime, before the process starts executing; others can wait until after the process has started to execute and link in the library just when it is actually referenced (i.e., during runtime). The latter is often called "delay loading" or "deferred loading". In either case, such a library is called a dynamically linked library."

I guess what is meant in the last sentence is dynamic loading. As dynamically linked libraries can imho also be pure program-startup-time-type libraries (vs. program-runtime-type libraries), the given sentence may even be wrong. --Abdull (talk) 11:15, 3 March 2010 (UTC)

The Multics system, where dynamic linking was invented, was able to dynamically link to segments that were not in a library at all. While there was a Binder, its use was optional; it allowed you to bundle related segments for reasons of configuration management or efficiency. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:13, 12 July 2010 (UTC)

Prior to the advent of personal computers and Unix, there were two prominent systems that provided dynamic linking. Due to differences in hardware architecture, the systems differed in when recursive linking took place.

The hardware for Multics supported indirect addressing and there was a tag field as part of the indirect address; some values of the tag cuased a fault (interrupt). The linkage information for an unresolved segment reference included the name of the segment, so that when a call caused a trap the dynamic linker could locate the proper segment, assign it a segment number, load it and place its entry address in the indirect address word.

The hardware for the IBM 360/67 did not have an equivalent mechanism. As a result, the designers of TSS/360 had to use a different strategy. Whenever the operating system loaded a load module, it assigned virtual storage for all subroutines called by that module, and marked the pages as assigned but invalid. A call to one of those subroutines would cause a program check interrupt, and the operating system would load the page as described above, possibly assigning storage for additional subroutines in the process.

The article should reflect the distinction between these two strategies and indicate which system uses which strategy. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:33, 12 July 2010 (UTC)

Multics uses the first strategy, TSS/360 uses the second. :-)

UN*Xes and Windows, however, use neither.

On UN*Xes, an dynamically-linked executable image file contains the pathname of an "interpreter file", which is normally the system run-time linker. The image activator (usually code in the OS kernel) sees that the image has an interpreter file path, and executes *that* program, instead (I think that if *that* program has an interpreter file path, the kernel gives up and the call to run the program fails). The run-time linker is handed a handle for the executable image (at least when it was first done in System V Release 4, it was a file descriptor, to avoid a case where somebody or something replaces the program being executed with another program); it acts as an image activator, mapping the program into the address space. It then looks at the list of libraries with which the program was dynamically-linked, and maps them into the address space, and continues blah blah blah transitive closure blah blah blah. It updates the table of pointers through which an executable or shared object refers to data from other objects (usually called the "Global Offset Table" or GOT), and sets up the table of code through which procedure calls to code in other objects are made (usually called the "Procedure Linkage Table" or PLT) so that a call to a procedure in another object goes to the run-time linker to resolve.

The run-time linker, if called through the PLT, will look up the procedure being called; if found, it changes the PLT entry to directly jump to the procedure and transfers there, otherwise it reports an error (generally by printing a message indicating that the routine isn't present in the shared library in which it was supposed to exist).

(See this article, discussing both ELF, used by most UN*Xes, and Mach-O, used by macOS/iOS/iPadOS/tvOS/watchOS, with the example code being x86-64 code, and the articles in the References section of the Global Offset Table page (which needs to be fixed, as it completely ignores the Procedure Linkage Table).)

Windows is similar, but not the same. See "How are DLL functions exported in 32-bit Windows?", "Calling an imported function, the naive way", "How a less naive compiler calls an imported function", and other articles in that series.

So neither of them use traps, and neither of them map the library into the address space at the time a call is made to a subroutine in the library.

So there aren't just two strategies, there are at least three. Guy Harris (talk) 07:51, 26 February 2021 (UTC)

@Peter Flass: I wouldn't consider a system call that starts another process to be dynamic linking. What is the mechanism in *ix for a program to dynamically call a subroutine *in the same process*? Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:58, 26 February 2021 (UTC)

@Chatul: I think the only way is with dynamic linking. As far as I know there’s no equivalent of OS/360 LINK, but I’d be happy to be proven wrong. (off the top of my head, could a program be linked to dynamically link to x and then change the appropriate control blocks during execution to change x to whatever? Sounds like a security nightmare.)Peter Flass (talk) 18:02, 26 February 2021 (UTC)

In OS/360, LINK does not elevate privileges. A program can do an XCTL to replace itself with another program at the same level in the stack, but again that does not elevate privileges. Shmuel (Seymour J.) Metz Username:Chatul (talk) 02:17, 2 March 2021 (UTC)

@Chatul: I wouldn't consider a system call that starts another process to be dynamic linking. Who indicated that it was? I didn't. I mentioned the image activation process as the way the run-time linker gets started; what's relevant in my description is the run-time linker, which is what handles dynamically-linked libraries.

Then what is the relevance of image activation to dynamic linking? You described recursively loading libraries at the time the main program was loaded, rather than loading them dynamically as they were needed. Shmuel (Seymour J.) Metz Username:Chatul (talk) 02:17, 2 March 2021 (UTC)

If for "dynamically linking" you require that a program using dynamically-linked libraries not have the names of the libraries in the executable image file, and that the libraries not be loaded until the first procedure call to the library is made, neither UN*Xes nor Windows have dynamic linking. The executable image must be built by "linking" it against whatever dynamic libraries it needs, and, while the code from those libraries isn't incorporated into the executable image, the names of the libraries are incorporated into the image, and they're loaded into the address space at program startup time, not at procedure call time.

What's "dynamic" in those environments is that 1) the libraries are found at startup time rather than at the time the executable image is built (the build process does have to find a version of the library when building, but it doesn't have to be the exact same library image as the one with which the program will run) and 2) at least in UN*X (and, I think, in Windows as well) the link isn't "snapped" (in what I remember being the Multics terminology) until the first procedure call is made to it - i.e., the first procedure call goes to the run-time linker, which replaces the transfer to the run-time linker with a transfer to the code in the library.

That's not so "dynamic" that you could, for example, write a file "main.c" that calls a function named "foo", run it and, when no such function is found, write "foo.c" that defines that function, compile it into a library image, and then "return" from the "no such function" error, so that the call to "foo" is re-attempted and, this time, succeeds - as you can, as far as I know, do in Multics. Of course, that also depends on Multics running commands as subroutine calls rather than in a separate process, and on the system exception caused by the failure to find "foo" turning into ON condition. and the system default ON unit calling the command processor (so that the stack trace has command processor -> your command -> ON unit -> command processor), so that when you exit the second command processor, it returns to the ON unit, which returns to the attempted call, which is reattempted and succeeds (as long as the "foo" executable segment is in the search path). Guy Harris (talk) 06:09, 2 March 2021 (UTC)

In Multics you can run a program that calls a subroutine that does not exist and compile that subroutine, as long as the object code is stored into the search path before the program hits the call to it. If the program has already hit the call before the compilation completes, then the program fails. Trapping the failure and calling a compiler would not require^[a] that commands run as subroutines rather than as processes, only that the target directory be in the search path. Shmuel (Seymour J.) Metz Username:Chatul (talk) 23:10, 2 March 2021 (UTC)

Yes, what I was describing could be done on UN*X or Windows, if there were a way for the program to catch a "function not found" condition, and if it then, for example, started an interactive shell process, and if returning from the handler caused the call to be retried - and if the libraries are loaded at procedure call time rather than program startup time. On Multics, no special provision has to be made, because 1) that condition is thrown as an exceptionON condition, 2) if there's no exception handlerON unit for a condition, there's a system default handler that calls the command interpreter, 3) if the command interpreter returns, so does the default handler, 4) returning from the default handler retries the call, and 5) libraries are loaded at procedure call time. Guy Harris (talk) 23:49, 2 March 2021 (UTC)

Do you have a reference for the Multics default handler calling the command interpreter and retrying the call? The only code that I was aware of was looking up the segment in the search path, adjusting the linkage segment if the search succeeded, and calling the newly loaded segment; nothing about processing if the search failed. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:15, 3 March 2021 (UTC)

Section 7.3.2 "SYSTEM DEFAULT CONDITION HANDLING" in "The Multics Runtime Environment" talks about the default handler (called, imaginatively, default_error_handler_) calling the command interpreter (see subsection 7.3.2.1).

Section 5.4.8 "ERROR HANDLING" says what happens when an error - such as the target not being found - occurs when trying to snap a link; the linkage_error condition is signaled.

Once you've compiled the source file containing the subroutine source, and now have a file containing the routine's machine code, you can return from the instance of the command interpreter from which you created that source and compiled it with the command start; see page 3-675 of Multics Programmer's Manual, Commands And Active Functions. Guy Harris (talk) 21:48, 3 March 2021 (UTC)

@Chatul: What is the mechanism in *ix for a program to dynamically call a subroutine *in the same process*? Call it, given a character-string value, in your programming language, containing the name for the subroutine? For that, it would be dynamic loading; the same is the case on Windows. Or call it in the regular fashion in your programming language, but from a dynamically-linked library? For that, it would be the mechanism I described. Guy Harris (talk) 21:40, 26 February 2021 (UTC)

Call it how? A normal call doesn't involve passing the name of the subroutine. Shmuel (Seymour J.) Metz Username:Chatul (talk) 02:17, 2 March 2021 (UTC)

A normal call doesn't involve passing the name of the subroutine. I.e., by "dynamically call a subroutine in the same process", you mean "call it in the regular fashion in your programming language, but from a dynamically-linked library", in which case, as I said, I've already described how that happens.

The version that involves the name of the subroutine is also done in Multics - that's how commands worked; the name for the command was treated as the name of a procedure to call, and the command interpreter looked it up (I think that if the command was named "foo", the command interpreter would look for an executable segment named "foo" and, if it found it, would call the procedure name "foo" in that segment). Guy Harris (talk) 06:09, 2 March 2021 (UTC)

@Peter Flass: off the top of my head, could a program be linked to dynamically link to x and then change the appropriate control blocks during execution to change x to whatever? Are you talking about "in OS/360 and its successors" (given the term "control blocks"), or are you talking about "in UN*Xes and Windows"? For the latter, who's doing the change? If you mean the program itself, at least in UN*Xes, the program's main() function isn't called until after the shared libraries are mapped in, so it can't change that; if it could find the function names pointed to by the PLT entries, it could conceivably change the names of the functions to be called before they're called. Guy Harris (talk) 21:40, 26 February 2021 (UTC)

In OS/360 there is no facility to change the name of a load module in storage, although the IDENTIFY macro can add an additional entry point name. Shmuel (Seymour J.) Metz Username:Chatul (talk) 23:10, 2 March 2021 (UTC)

Imagine there is a shared library with a static variable. This static variable is used by one or more subroutines within this shared library. Now imagine, two or more programs use this shared library. How will these programs handle the static variable? Will these programs share it and mess with each other program's state? Or will every program make its own local copy of the variable? Thanks, --Abdull (talk) 22:47, 12 August 2010 (UTC)

I'm pretty sure that in a Windows DLL each program will create its own static variable. But, this is not the right forum for such a technical question ;) Stevebroshar (talk) 10:54, 5 April 2024 (UTC)

Historically, libraries have been used to store a wide variety of objects, e.g., documentation, source code, test data. This is still common on, e.g., IBM mainframes. Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:31, 16 August 2010 (UTC)

• Perhaps you are talking about something like archive files; how ar (Unix) can work on any kind of file but is usually only used for object files. Perhaps the Window 7 libraries also come under this category? Also I guess things like a component library and footprint library, used in electronic design automation, would also be examples of this usage. I’d say generally, they are repositories of related objects where some of the objects are picked out in each application.

I'm talking about an operational entity rather than one used for backup or transport, e.g., a partitioned data set (PDS) in OS/360 and successors. Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:13, 28 June 2012 (UTC)

I'm not sure what you're referring to when you say "one used for backup or transport", but ar is an operational entity, not one used for backup or transport. You might be thinking of tar, which is used for backup and transport; ar is used to construct "static" libraries on UN*Xes (and, I think, dynamic libraries on AIX), so it might be what you're describing as an "operational entity". Guy Harris (talk) 15:31, 28 June 2012 (UTC)

Anyhow, I’d support moving this article to something like Library (software) (apparently renamed away from that in 2003) or Program library, unless the topic is extended to cover these more general libraries. Vadmium (talk) 03:19, 24 August 2011 (UTC).

• I support extending the current definition to include 'a wide variety of objects, e.g., documentation, source code, test data' without moving the article. --Gryllida 00:22, 18 May 2012 (UTC)

I've updated the introduction to reflect that and removed the {{disputed}} tag. Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:13, 28 June 2012 (UTC)

Sorry, but I think that an unsourced statement about how this term was used in IBM OS/360 should not trump modern and more widespread usage for the opening paragraph. The OED defines a library as "an organized collection of routines." Computer pioneers Goldstine & von Neumann (1947) and Wilkes & Wheeler (1951) also use it to mean a collection of routines. A collection of routines, functions or methods is still the modern usage. I don't see much support for the idea that libraries include documentation or data. Jno.skinner (talk) 04:23, 26 February 2021 (UTC)

“A fundamental flaw of Microsoft Windows is that it can only link in a library at loadtime, before the process starts executing; others can wait until after the process has started to execute and link in the library just when it is actually referenced (i.e., at runtime).”

Microsoft added delayed loading of statically linked libraries in VC++ 6.0 ; (which is more than 10 years ago) note that this was an addition to VC++ and not to the windows kernel, which indicates that this "fundamental flaw" probably has never existed, and is speculation at best.

If Microsoft Windows did in fact not support linking a library at runtime, I'd like to see a reference or citation. 84.48.103.151 (talk) 17:45, 20 December 2010 (UTC)

The LoadLibrary call was possibly introduced with Win 3.0 beta, so more than 20 years ago. Therefore, the quoted statement is false. I would remove that sentence from the main article. —Preceding unsigned comment added by 99.91.182.150 (talk) 21:15, 2 February 2011 (UTC)

There's automatic loading of a library when the first reference to a routine in that library is made, rather than loading it at startup time, and there's programmatic loading of a dynamically-loadable module by an explicit call. I think the statement about the "fundamental flaw" is referring to the former; LoadLibrary(), dlopen(), and company are the latter. The cited reference in 84.48.103.151's comment appears to be referring to the former (although it speaks of "static linking" in a way that can be confusing to those coming from UNIX, where "static linking" means linking with a non-dynamic version of a library - for those coming from Windows, think linking with a .lib rather than a .dll). In any case, the first reference seems to indicate to me that the quoted statement has been false dating back at least as far as VC++ 6.0). (As for "VC++ vs. the Windows kernel", that's another thing confusing to those coming from UNIX - in most UNIX systems, the C library and C startup code are part of the OS, not the compiler - the compiler is often a bundled part of the OS, but even when it's not, the libraries are - but it might be that the C startup/C library code does the dynamic loading of libraries in Windows, or can handle at least the loading of libraries after startup time, so that might've been done by changing the C startup and library code.) In any case, I'll remove the statement. Guy Harris (talk) 22:47, 2 February 2011 (UTC)

The static library article discusses libraries that, when linked with a program, have modules from the library copied into the executable image of the program. The "static libraries" section mostly discusses that process.

There were, in System V Release 3, a form of shared library that, as I remember, was not as dynamic as the SunOS 4.0 shared library mechanism from which the System V Release 4 shared library mechanism, as used by SVR4 derivatives such as Solaris as well as Linux distributions and BSD systems that adopted the ELF executable image format. I think Linux had a shared-library mechanism before the adoption of the SVR4 shared library mechanism; I don't know how dynamic it was.

My memories of this, from when I was at Sun and Sun and AT&T were engaged in the discussions that led to SVR4, are a bit faded; I can try digging up information about the SVR3 shared library mechanism, but if anybody's memories are better than mine, if they could contribute, that might be nice. Guy Harris (talk) 21:00, 23 August 2011 (UTC)

Recently, the "shared libraries" section was changed to say "Static libraries are usually only shared at compile time" rather than "Static libraries, by definition, cannot be shared". I'm assuming "compile time" here means, on most platforms, "link time", i.e. the time at which one or more object modules built as part of a program, and object modules from a static library, are combined into an executable image.

The "shared libraries" section speaks of two different types of sharing:

• "the sharing of code located on disk by unrelated programs";
• "the sharing of code in memory, when programs execute the same physical page of RAM, mapped into different address spaces".

The sharing in "Static libraries are usually only shared at compile time" is presumably referring to the first of those types of sharing; it's unlikely that the OS will be able to arrange that separate copies of a given routine in multiple executable images be stored in the same physical page of RAM. That code could be described as "shared", in the first sense, in that multiple programs built with the same library don't need to build their own copies of that code, so that the build processes for those programs read the routines from a single copy on disk in the library file, but the executable image files for those programs have their own separate copies of the routines on disk, rather than referring to a shared copy in the static library. Guy Harris (talk) 21:11, 23 August 2011 (UTC)

Yep link time is probably even more accurate, as long as the distinction from the dynamic linker's action is made. I didn’t realise compile time is not always taken to include the static linking stage; I used it to mean something more general like “build time”. Maybe something like “they’re only shared at link time before load time”?

I think this section needs more cleaning up and clarification anyway:

• What are the fundamental differences (if any) between a dynamic linking library, a Windows dynamic-link library, a shared object and a dynamic shared object?
• Libraries are shared in the even broader sense of code reuse: disk and memory space may not be shared or conserved but multiple programs may still use private copies of a particular library. So I find the term shared library ambiguous and confusing; I’d say most libraries, by general definition, are intended to be shared in some sense.
• The long “Shared libraries” section, currently a subsection of “Dynamic linking libraries”, seems to mix up multiple meanings of the term sharing (as well as being generally confused). Perhaps the section should be called “Library sharing” or “How libraries are shared”. Perhaps some of the text should be directly under the “Dynamic” heading, other text not under it at all, or under a shared memory heading.
• What is the Unix sense of shared libraries, and how are Windows DLLs not this sense?

Vadmium (talk) 03:19, 24 August 2011 (UTC).

I did a bit of reading. Some ideas that I picked up; some I missed from this article:

• Linking, binding, linker: allocates memory segments and binds references to library and other object dependencies
  • Static linking, early binding: memory allocation and address resolution done before run time, and does not change when the program is run. Any library used would probably be a static library.
• Loading, loader (computing) (run time): loads program image or other object at run time, may also load external dependencies
  • Relocation (computer science): adjustment by loader to compensate for addresses of memory segments differing from addresses allocated by linker (if at all)
  • Position-independent code: does not require relocation, therefore not modified by loader
• Static build: program file is statically linked, self contained, includes dependencies from libraries with all references resolved, and each memory segment allocated. Only possible extra action by loader needed is final relocation (if no virtual memory, or address randomisation wanted, etc).
• Shared library or object: single copy in file on disk, may be used by multiple programs, linking does not copy objects into program file. Libraries and objects may be replaced provided they are compatible with any assumptions of program and linker. Loading done to each library and object dependency file as well as main program file. A statically-linked library would be shared in this sense, even after compile and link time, up until at least load time.
  • Shared objects will usually need to be relocated to accommodate different programs’ memory segment allocations. Rebasing tries to avoid this.
  • Shared memory, memory mapping: sharing may be done between programs (processes) at run time, if shared objects are not modified (by relocation). Unix apparently achieves this in general with position-independent code, and perhaps this is what is meant by “shared libraries in the Unix sense”. Windows also does this when processes load a shared object at a shared virtual location.
• Dynamically linking, dynamic linker, linking loader, late binding: Combined linking and loading. Presumably a dynamic shared object is the same as a dynamically linked object or library; I imagine they would generally always be shared objects or libraries, but not necessarily the converse.
  • Dynamic-link library: Windows’s implementation
  • Prebinding, prelink: optimisations
• Dynamic loading: loading additional objects after program is loaded and begun execution.

Vadmium (talk) 15:53, 24 August 2011 (UTC).

"a library is a collection of implementations of behavior, written in terms of a language, that has a well-defined interface by which the behavior is invoked"

What the hell kind of opening sentence is that? It doesn't tell me at all what a computer library is. — Preceding unsigned comment added by 169.139.19.173 (talk) 22:08, 14 August 2013 (UTC)

Your comment is off-putting. Please be more civil. IOW no swearing please. Thanks. Stevebroshar (talk) 10:50, 5 April 2024 (UTC)

Hello fellow Wikipedians,

I have just modified 2 external links on Library (computing). Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20050313025901/http://www.csa.iisc.ernet.in/resources/documentation/hypertext/bfd/bfd_toc.html to http://www.csa.iisc.ernet.in/resources/documentation/hypertext/bfd/bfd_toc.html
• Added archive https://web.archive.org/web/20060618065018/http://lcsd.cs.tamu.edu/2006/ to http://lcsd.cs.tamu.edu/2006/

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 08:55, 15 May 2017 (UTC)

I find this page somewhat forbidding (IBM OS/360? in the lead???) and a bit of a hairball.

For my personal wiki, I created a subpage "Linkable code library" for the portions of this page which relates to program linkage concerns (presently with subtopics static library and dynamic-link library).

That probably doesn't work here, but it sure makes my own wiki nicer than this one. :-) — MaxEnt 18:47, 13 September 2017 (UTC)

Use of hairball is confusing. Must mean something to you, but not me. Please be less colorful and more clear. Thanks. ... I too think the IBM 360 sentence does not belong in the lead. Question: Why didn't you move it yourself? IMO you are complaining about something you have control to change. Another question: are there other things you find forbidding? Or just that one? ... I do not understand the point you are trying to make about your personal wiki. Please explain. Stevebroshar (talk) 10:48, 5 April 2024 (UTC)

Currently the first line reads:

>In computer science, a library is a collection of non-volatile resources used by computer programs,

This sucks, I do not know who wrote it, and I doubt there's a citation to back it up.

In the past it was:

>In computer science, a library is a collection of subroutines or classes used to develop software.

Which is sensible, albeit not perfect.

And:

> In computer science, a library is a collection of implementations of behavior, written in terms of a language[disambiguation needed], that has a well-defined interface[disambiguation needed] by which the behavior is invoked.

Which is great, but it's very technical and needs to be backed up by a citation.

I have my own definition of software library, of course, but I will resist the temptation to add to the confusion by adding it. Instead, I'll be on the lookout for a citable definition. As soon as I find one, I'll cite it and add it here. If anybody reads this. Be on the lookout as well, and if you find one, remember this comment and add the definition to the article. But please, don't start googling "Definition of software library", just let yourself naturally find it, the end result will be much stronger. --TZubiri (talk) 04:34, 16 May 2020 (UTC)

A bogus claim of objectivity only weakens your argument. Any objective discussion of the definition most start with what issues it needs to address and how well Well it addresses them. Objectively, one of the issues that it faces is that the nomenclature in the industry has a lot of variation. Any definition that fails to take that into into account will and ought to be challenged as lacking WP:NPOV. Sensible but wrong is not better than accurate but stilted.

That said, there is material in the lede that should be in the main section, and the history section should be expanded with citations of the nomenclature on various systems. Shmuel (Seymour J.) Metz Username:Chatul (talk) 00:54, 17 May 2020 (UTC)

You lost me at "sucks". I too sometimes use colloquial language, but I try not to. It pushes buttons and turns off the reader (me). ... as for those two definitions: a library is a collection of non-volatile resources. It is not _just_ subroutines and classes. I don't think either wording is great or easily understood by the layperson. ... as for your resistance to share your definition: why not put it here at least? Seems oddly mysterious. You come off as combative and not a team player. Let's work together. Stevebroshar (talk) 10:42, 5 April 2024 (UTC)

The article doesn't make that clear. Azbookmobile (talk) 21:16, 27 December 2022 (UTC)

"Library" is a term that, in computing, is used for various purposes. The two purposes mentioned in the library are

In computer science, a library is a collection of non-volatile resources used by computer programs, often for software development. These may include configuration data, documentation, help data, message templates, pre-written code and subroutines, classes, values or type specifications. In IBM's OS/360 and its successors they are referred to as partitioned data sets.

and

A library is also a collection of implementations of behavior, written in terms of a language, that has a well-defined interface by which the behavior is invoked. For instance, people who want to write a higher-level program can use a library to make system calls instead of implementing those system calls over and over again. In addition, the behavior is provided for reuse by multiple independent programs. A program invokes the library-provided behavior via a mechanism of the language. For example, in a simple imperative language such as C, the behavior in a library is invoked by using C's normal function-call. What distinguishes the call as being to a library function, versus being to another function in the same program, is the way that the code is organized in the system.

Yes, these are not written in terms accessible to a lay reader, but not all Wikipedia articles can easily be made accessible to such a reader. It may not be impossible, but it may be a challenging task.

The second definition is arguably a specialized version of the first, as the "implementations of behavior ..." can be thought of as "non-volatile resources used by computer programs" - they're subroutines or classes.

If you're looking for an analogy to a "library" in the usual sense of that term, a "library" in computing is, as noted, a collection of materials for use either by programmers or by programs. Some materials, such as documentation and help data, and "pre-written code" if that means "source code that you can include in your program", are for use by programers. Others, such as pre-written subroutines and classes, are directly used by programs, and indirectly used by programmers who, by having their programs use a subroutine or a class, don't have to write their own code to do what the subroutine or the class does. (In some programming languages, those two forms of "pre-written code" might be the same.)

Perhaps the introduction can be improved to make it a bit clearer to the novice, but somebody who wants to understand the notion of subroutine calls or class method calls will probably need some understanding of how a computer program works, even if it's at a very general and conceptual level (they don't need to know how machine code, or code in some particular programming language, works).

As somebody who commented on your talk page hinted, explaining technical information in a fashion accessible to lay readers is not easy. The skills required to be a good science and technology writer for a lay audience may include writing skills in the language in which the articles are written and an understanding of the science or technology about which the article is written, but those aren't sufficient - the writer also needs the ability to explain the ideas to people without their level of understanding. Guy Harris (talk) 02:32, 28 December 2022 (UTC)

I've been involved in projects where a tech writer, in the process of making the documentation clearer, caused it to no longer describe the software we were writing. That gave me an appreciation for those with the skill to make text easier to read without destroying the meaning. A good tech writer is a joy forever.

Unfortunately, not only are most wiki editors neither subject matter experts no tech writers, but were wikipedia to restrict editors to those two categories, the pool of editor would be drastically curtailed. Only fora with paid editors can afford to be so picky. Like many here, I try to be clear and accurate, but hope that others can clarify anything that is too difficult for a lay reader.

Perhaps as a matter of policy wiki could reach out to the tech writer community and solicit volunteers? --Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:40, 28 December 2022 (UTC)

Library (computing) § Creation and Execution of Shared Library in Linux/Unix is a detailed example of how to build a shared library on some operating systems, oriented towards ELF-based systems and, in particular, Linux systems. It doesn't apply to non-ELF-based UNIXes (macOS and AIX), it assumes use of gcc, and it assumes a requirement for running ldconfig to update the shared library cache, which I think may not have been necessary in some if not all versions of Solaris.

On top of that, it appears to read like "a "how-to" style" item, to use the description of what doesn't belong in Wikipedia from WP:NOTHOWTO.

So, while it might be a useful tutorial, I don't see it as being worthy of inclusion on Wikipedia (which is not intended to be a collection of all useful information of all types (as per the existence of Wikipedia:What Wikipedia is not). Guy Harris (talk) 21:12, 22 July 2023 (UTC)

Thanks. I am removing the changes I added. Wikieditor 2027 (talk) 21:25, 22 July 2023 (UTC)

When I see the diffs someone has removed quite a large amount of content from this article. Is this intentional? Wikieditor 2027 (talk) 07:08, 29 July 2023 (UTC)

If you remove the "re" from "removed", the remaining word tells you what happened to that content. Note that the first edit of the sequence of edits you saw has the edit summary "Material WP:SPLIT to Shared library". Having read that, you might want to look at Shared library. Guy Harris (talk) 07:48, 29 July 2023 (UTC)

Some recent changes to this history section about verb tense got me to read the section carefully. It did have a mix of verb tense. But even with the latest changes it still does. I see the challenge with historical info. Does Simula have classes or did it have classes? IDK, but I do think that consistent is better; easier to read.

but ... the paragraph about Simula seems off topic for the most part. Seems to be a primer on Simula. What does "its classes are nearly identical to the modern concept as used in Java, C++, and C#" have to do with libraries? I think this paragraph needs a total re-write. I think the interesting and on-topic idea is that classes could be included in a library as soon as the concept of class was realized in a language. Stevebroshar (talk) 12:50, 7 April 2024 (UTC)

The first fact a new reader on this page gathers is that they are read-only. But is this actually a defining aspect? From my (admittedly limited) understanding that should not be a necessary precondition for a resource to be considered a library. I have also not found the read-only aspect mentioned in other definitions. Could somebody explain to me why read-only needs to be part of the definition of libraries or provide an authoritative source explaining it? Andre908436 (talk) 16:59, 1 November 2024 (UTC)

It's an error introduced in permalink/1217194093. In fact, in a development environment libraries are highly volatile. Thanks for catching the error. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:08, 1 November 2024 (UTC)

Read-mostly, maybe, but definitely not read-only. Guy Harris (talk) 19:37, 1 November 2024 (UTC)

Yes, a library is read only. IDK if I'd call it a defining aspect. I would call it fundamental. It's not why libraries exist, but it's part of what makes them useful. A library file is not modified by its consumer. It remains a static, known quantity. There can be versions of a library, so in that respect a library can change, but that's different from read-only. So, although it's correct to say a library is read only I agree that it gives the wrong impression about the importance of that aspect. An oh so common occurrence of: not wrong; but not good. Stevebroshar (talk) 10:28, 1 February 2025 (UTC)

Yes, a library is read only. Funny, I seem to be able to write them, and do so on a number of occasions, so that's definitely not true for me.

Then again, I'm a developer, so the comment above that "In fact, in a development environment libraries are highly volatile." applies. Guy Harris (talk) 19:18, 1 February 2025 (UTC)

No, a library is not read only. In fact, the ability to update them is what makes them generally useful. That's been true since the 1960s and remains true today.

What is confusing is that system libraries tend to be less volatile than libraries belonging to individual users or teams of users, but even they get updated. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:22, 3 February 2025 (UTC)

Even if no address space layout randomization occurs, the virtual load address may not be constant and even if it is constant it may not be known by the linker. E.g., in OS/360 and successors, the linkage editor creates relocatable load modules; everything other than the nucleus, transient error recovery routines^[a] and transient SVC routines^[a] is loaded into dynamic storage. For OS/360 that's dynamic real storage but for OS/VS1 and OS/VS2 (SVS) through z/OS it is dynamic real storage.

At least in the SunOS 4.x, ELF, and Darwin (macOS, iOS, etc.) shared library mechanisms, the virtual load address is not guaranteed to be constant and is not known to the linker, only to the run-time linker/loader. Guy Harris (talk) 23:29, 4 February 2025 (UTC)

Or were you referring to

A static build may not need any further relocation if virtual memory is used and no address space layout randomization is desired.^[1]

from Library (computing) § Static, which is talking, ih the UN*X/Windows context, about executable images rather than dynamic libraries? (I guess those would be types of load modules (not Lord Modules) in the OS/360 and successors sense.) Guy Harris (talk) 23:54, 4 February 2025 (UTC)

Yes, the sentence you quoted from § Static. Yes, in MULTICS and Unix-like systems directories serve the purpose of libraries in, e.g., OS/360. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:58, 5 February 2025 (UTC)