Talk:Library (computing)

Problems with this article

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.

Partial list of topics to fill in

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

A question

"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)

UNIX PATH envariable is not used to lookup dynamic libraries

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 [1]. 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 [2]. ← 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)

Computer science project

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)

Article's Direction

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)

Bad Edit?

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)

Annotation

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

shared libraries drawbacks

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)

Requested move

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)

Survey

Add "* Support" or "* Oppose" followed by an optional one-sentence explanation, then sign your opinion with ~~~~

• Support – Smyth\^talk 20:40, 25 September 2006 (UTC)
• Support - makes sense to me, looks like this was named back in late 2002 when disambiguation wasn't such an exact science. -- nae'blis 15:41, 26 September 2006 (UTC)
• Support - Guy Harris 16:19, 26 September 2006 (UTC)

Discussion

Add any additional comments

This article has been renamed as the result of a move request. Vegaswikian 19:29, 2 October 2006 (UTC)

Relocation in 64-bit systems

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)

Standard Library

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)

Broken link

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)

History?

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.

OpenStep?

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 talk pages

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

Recent revert

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)

Missing stuff on Incremental Linking

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).

Dubious

"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)

Decouple dynamic linking from DLL's

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)

Time of recursive dynamic linking

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)

Shared libraries and static variable

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)

The definition is for a narrow subset

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.

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)

Dynamic Linking

“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 [3]; (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)

Requested move 2

The following discussion is an archived discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

The result of the move request was: not moved, per lack of consensus —Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); March 17, 2011; 17:06 (UTC) 17:06, 17 March 2011 (UTC)

---

Library (computing) → Software library — Avoid parenthetical disambiguation with a natural and recognizable term. --Pnm (talk) 01:27, 13 February 2011 (UTC)

• Oppose it is not a software library. Though neither is "Library (computing)" accurate. This is not a library of software, nor is it a library specialized for computing. Subroutine library binary or Software routine library seems better choices. 184.144.164.14 (talk) 08:02, 13 February 2011 (UTC)
  • "A library of software" is accurate. Software routines are software. --Pnm (talk) 10:18, 13 February 2011 (UTC)
• Support. It is indeed both natural and recognizable, even moreso than the current title. Speaking as a professional, I would have had to guess at the meaning of the first title, but I know immediately what the second title denotes. Powers ^T 14:58, 13 February 2011 (UTC)
• Oppose new title but support move. The article describes a specialized type of software library. Unless it is expanded to include, e.g., documentation, message libraries, the new name should be more explicit, e.g., Software code library. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:37, 16 February 2011 (UTC)
  • I'm a bit confused. How does software library include software documentation? What's a message library? --Pnm (talk) 03:32, 19 February 2011 (UTC)
    • IBM documentation for, e.g., z/OS is commonly packaged into libraries. Sometimes only formatted help data and manuals are provided, and sometimes the marked up text from which those libraries are built.
    • Some IBM software has code to build messages from templates in a library, typically provided in different versions for different languages. Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:15, 23 February 2011 (UTC)
• Mild support because it is just as precise but avoids using a disambiguator, although I think we could come up with something better. Maybe Programming library? –CWenger (talk) 19:03, 5 March 2011 (UTC)
• Oppose. The ideal title for this topic is simply Library - because that is what it is most commonly called - but of course that is ambiguous and has a primary use. That means the title needs to be disambiguated. The problem with disambiguating without using parenthesis is that that results in a title that wrongly implies the entire disambiguated title, e.g., Software library, is the most common name for this topic. That's why I oppose Software library and Programming library. I agree, however, that "computing" is not an ideal disambiguator and suggest instead software for the parenthesized disambiguator. Thus, we have a...

Counter proposal: Library (computing) → Library (software).

--Born2cycle (talk) 22:20, 15 March 2011 (UTC)

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.

"Static libraries" vs. "statically-linked shared libraries"

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)

What does it mean to say a library is "shared"?

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).