Talk:Library (computing)

From Wikipedia, the free encyclopedia

 This article is within the scope of Computing WikiProject, an attempt to build a comprehensive and detailed guide to computers and computing. If you would like to participate, you can edit the article attached to this page, or visit the project page, where you can join the project and/or contribute to the discussion.
B This article has been rated as B-Class on the quality scale
High This article has been rated as high-importance on the importance scale
Library (computing) is currently a good article nominee. Anyone who has not contributed significantly to this article may review it according to the good article criteria to decide whether or not to list it as a good article, as outlined on the nominations page.

Reviewers: To start the review process, follow this link to create a dedicated subpage for the review. (If you have already done this, and the template has not changed, try purging this talk page.)

Date: 20:50, 28 May 2008 (UTC)

Contents

[edit] 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)

[edit] Partial list of topics to fill in

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

—Frecklefoot 18:36, 18 Sep 2003 (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

[edit] 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)

[edit] 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)

[edit] Computer science project

This article is part of WikiProject Computer_science, a project to improve Wikipedia's articles related to Computer_science. For guidelines see the project page and Wikipedia:Contributing FAQ.

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)


[edit] 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)


[edit] 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)

[edit] 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

[edit] 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)

[edit] 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)

[edit] 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)

[edit] Discussion

Add any additional comments

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

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] merge talk pages

 It has been suggested that talk:library (computer science) be merged into this page or section. (Discuss)
69.140.152.55 (talk) 05:21, 11 June 2008 (UTC)