Talk:Library
I do not know what "Pre-talk" or "Post-talk" means. Anyway, the article is EXCELLENT, I used a lot of information from it, but the article leaves the feeling it does not know what it wants to say to the reader. --ThorstenStaerk 07:49, July 18, 2008 (UTC)
I changed this page a bit. What I disliked before is that it used 100 words where 10 would have been enough. It was laid out to manipulate the reader to disliking static linking and liking dynamic linking, and this manipulation was not done in a decent way, but rather blunt. It said that dynamic linking is modern. This is not true, always, experienced programmers have rather used dynamic linking and unexperienced programmers have rather used static linking (because it is easier). Instead, in most cases, dynamic linking is better than static linking, however there is no "trend" to dynamic linking, it is not "modern". The advantages and disadvantages of both were not shown, and (I am writing this on a system with 1TB disc space) the most minor argument for dynamic linking, the lesser disc space needed, was put which is just ridiculous if you look at the average lib having around 100 000 bytes. Even the memory space needed would have been a better argument. --ThorstenStaerk 10:29, July 18, 2008 (UTC)
This article takes the opposite direction of a newcomer learning linux, of getting things done. When a newcomer wants to get things done, he might ask "how can I tell what libraries an executable depends on", but he will not ask "what does ldd". The direction should always be "you have a problem - here is the solution", not the other way round. That is why I dislike the heading "ldd", I prefer "find out dependencies". --ThorstenStaerk 10:46, July 18, 2008 (UTC)
The name Library-related Commands and Files is quite bad, I want to have the command nm here, but I do not even find a place where it would fit, all this article is a wild mixture of commands (ldd for example) and an explanation how to compile libraries and an explanation what libraries are. --ThorstenStaerk 11:36, July 18, 2008 (UTC)
Pre-talk
I think a "libraries" section would be useful.
Whoops -- sorry, I forgot to add my username: JohnMG 01:02, Mar 10, 2004 (EST)
Anyhow, I mean that the Main_Page should have a "Libraries" link off of it.
Also, as you suggest, there should be a "Software development" link off of Main_Page with the subcategories that you mention. Either way, This stuff needs to be easily available from the main page, otherwise folks won't be able to find it. If I could edit the Main Page, I'd do it myself, but since I can't, I'm posting here. :)
Hmm... I think "programming tips & tricks" just needs to be renamed "Sofware development".
How's about Inner Workings for those of us who don't want to develop software... note: all pages can link to all other pages... so there can be one Shared Libraries section, that serves both the curious and the needy.
No idea who's saying what here, but generalizing and promoting 'Programming Tips & Tricks' to 'Software Development' sounds good to me. I don't see 'Libraries' being top-level, at least at this point in time, though. Top-level under 'Software Development'?
Digiot 03:00, Mar 10, 2004 (EST)
Digiot, the problem (as I see it) with "Libraries" being under "Software Development" is that there's the whole interesting story of how ld.so, ld.so.conf, ldd, etc. all work together so user's programs can get the system to find their libs so they can run. This is an important topic for folks to understand, but doesn't necessarily have anything to do with software development.
It seems to be more of an operating system issue that doesn't fit under any one topic in Main_Page. Can you think of where this useful ld.so info could fit into the LQwiki scheme of things? Hmm... maybe a new heading under the "Commands" page...
JohnMG 04:19, Mar 10, 2004 (EST)
Hm. That's an excellent point. ldd, et al, are (or should be) in Commands already but that doesn't really bring out the connections. As far as 'Applications', it belongs to both sections - no true difference between command and apps to me. Just kind of a vague 'mostly GUI-ish' and 'mostly CLI-ish' divider. :) I'm not sure how much material you'd have in mind - I think it'd make an excellent 'Common Questions and Misconceptions' piece. Tie up all the small bits of material with a lot of links and plenty of discussion.
As far as OS issues, one thing that might be kind of neat is a sort of 'How did I get here?' section on the main page - do a sequence of things 'from power up to bash prompt' and then trace out all the steps to looking at a web page in a GUI browser, with packets flying to and fro. And a section on Libraries could figure into that. Or an 'Under the Hood' section. It is definitely generally important now that you make me look at it right, but I'm still not sure it's large enough or central enough to most people's concerns to be on the main page. And it doesn't seem to fit neatly into anything we've got so far. Any of that sound good?
Digiot 05:05, Mar 10, 2004 (EST)
Nah, actually looking over it and thinking over it again, it probably would work out as a section of commands. Looking at the kernel commands with depmod and all - I can see a library section. And, as there's a system info section in apps, I could see a system info section, with the lspci's and whatnot, in commands, too. I'd personally like to see every command categorized by concept/function as well as alphabetically, so that'd need to be done to achieve that, anyway.
Digiot 05:18, Mar 10, 2004 (EST)
Digiot -- ok, I'm on it.
JohnMG 14:08, Mar 10, 2004 (EST)
-edit-
Done.
Digiot, have a look at Library-related_Commands_and_Files. You like? :)
JohnMG 23:14, Mar 10, 2004 (EST)
I've been looking. I like. :) There's just a couple of minor things and one kind of larger thing. One is that you might mention in your discussion of statically linked binaries that this is sometimes used to get around proprietary library issues - you can use a statically linked binary without needing to have the proprietary libraries (and licenses) on your system. Also, you discuss runtime and compile-time (or build-time) but might want to contrast them directly. The larger thing is that I see the shape of it now and it doesn't match the format - at that level, a page like 'Library Related' would usually just be a list of 'ldd' and 'ld.so' and so on, and the discussion would take place below that. But I'm not sure that that's a concern. I think content is probably more important, and that's some good content. :)
I'm going to leave this discussion here for now but, depending, I think I may move this to the Talk page of 'Library Related' soon.
Digiot 23:45, Mar 10, 2004 (EST)
Post-Talk
I should have done this awhile ago. I tried to restore the discussion, removing extraneous stuff that's materialized in Section Request as best I could without altering what was there - except to move it here. *sigh*
Digiot 03:11, Mar 15, 2004 (EST)
Is it theoretically possible to generate a C header file, given a shared library?
Just curious.
I am not a coder, but aren't shared libraries in binary? You ought to be able to link to them like a library and the linker will pick up on them, but making an actual header file out of them... Crazyeddie 11:57, Aug 24, 2004 (EDT)
Er, what? If it's a standard library, it should come with header files for you to make any sort of use out of the thing. If you want to know what sort of things are in the library, use some stuff in binutils. Dysprosia 20:57, Aug 24, 2004 (EDT)