Talk:Glibc

dicdef?

isn't this really kind of more of a dicdef than an encyclopedic entry? Avriette 00:56, 25 Mar 2005 (UTC)

Covered by GPL?

Is this library licensed under the GPL? Is it, then, possible at all to compile and release proprietary programs under Linux using these standard C libraries, which I'm pretty sure are the only modern ones available under Linux? --I am not good at running 05:30, 12 May 2005 (UTC)

LGPL. Entire properitary operating systems (BeOS, for instance) have used glibc as their main C library. Kiand 09:38, 12 May 2005 (UTC)

Later today I plan to move this article

From the package's homepage [1] it seems that the proper name is "GNU C Library". Can anyone give a good reason for me not to move this article to that name?

Nothing will be lost - not the Talk, not the history. Nothing will be broken, no links will have to be changed, Glibc will become a redirect to GNU C Library. Gronky 11:16, 13 November 2005 (UTC)

At that point why would you move the article? Why not just make your additional article name the redirect and save the troublesome redirect for the talk page? Janizary 07:24, 21 November 2005 (UTC)

I'm not familiar with "the troublesome redirect for the talk page". My reason for moving the article was that the new title is correct and the old one is not. If titles didn't matter, each page would be refered to by number and would then have redirect aliases. One effect of the title is that it gets written in big letters across the top of the page. Gronky 15:51, 21 November 2005 (UTC)

Alpha?

I've unlinked an ambigious "alpha" from the main page, but am not sure enough that it means DEC Alpha to link it. - brenneman^(t)(c) 23:44, 21 December 2005 (UTC)

libc6 usage uncommon?

The official Debian (and Ubuntu) package for glibc version 2 is 'libc6', which seems like a fairly major use... --Delirium 06:25, 16 March 2006 (UTC)

Nah. The package may be named that, but glibc is pretty universally called glibc, not libc6, except to contrast it with the older libcs. A Debian package name may be major, but it's not common (if you get my drift). Maintaining this name is just clumsy, because glibc is not exclusive to Linux (and on other platforms there may not even be a "libc5") and it has its own version number. I think the Debian name remains for historical reasons. We wouldn't expect a "libc7" any time soon, after all, just newer versions of glibc. 81.58.51.131 08:32, 29 March 2006 (UTC)

The story is told here: http://linuxmafia.com/faq/Licensing_and_Law/forking.html (about half way down, point #6) Gronky 10:30, 29 March 2006 (UTC)

libc.so.6 is the standard soname of the gnu C library on linux. Debian names the binary package libc6 due to thier standard naming conventions for library packages (the source package is called glibc btw). I'm not sure what distros outside the debian family do. If and when there is ever a glibc 3.0 with backwards compatibility broken i supsect it will have a soname of libc.so.7 and a debian package name of libc7 but i don't see that happening in the near future. Plugwash

Also note that the name of the debian binary package (along with the soname of the library) varies by architecture. It's libc0.1 on kfreebsd, libc0.3 on hurd and libc6.1 on alpha and ia64 Plugwash (talk) 13:32, 24 November 2011 (UTC)

pronounce

Glibc -- how do you pronounce this??

I've always heard it pronounced as: "gee lib see" (soft 'g') Gronky 13:15, 15 June 2007 (UTC)

what exactly was the linux libc5?

anyone know any more about it? who wrote it? what license was it under? why did people preffer glibc? Plugwash 22:35, 7 June 2006 (UTC)

libc5 was a fork of GNU libc by the Linux developers. They eventually gave up and went back to GNU libc. This is way GNU libc, even though it is still on version 2.4 is often called "libc6", as it superseded libc5. The story is in section 6 of Fear of forking. I'll add that link to the article. Gronky 22:52, 7 June 2006 (UTC)

Todo

• Add refs to the claims that it supports X, Y, and Z standards. Refs can almost certainly be found from the page liked to from here:[2]
• History: there is probably a lot of glibc info in the old GNUs bulletins: [3]

glibc initialism

I do hope f/ a disambiguation-list, of various related initialisms, f/ ignorami, such as myself.

Thank You,

[[ hopiakuta Please do sign your signature on your message. ~~ Thank You. -]] 23:00, 2 March 2008 (UTC)

Familiar a GNU/Linux distribution?

I would argue rather strongly against that description. OpenEmbedded (on which OM and Fam are based) does not require (and commonly) GNU tools at all. If you use the Qtopia/OPIE version then there is no glibc required either. We can't call a distribution GNU/Linux if its not based on GNU at all - no matter the argument. --Kim D. Petersen (talk) 17:12, 3 June 2008 (UTC)

I think the confusion here comes from the GDE option (which is GNU based). Its an option for a PDA like interface - but its not the only one. The other is Qtopia/OPIE (which is not GNU based). You can't (afaik) build GDE on a non-glibc basis (ie with uClibc or others), but you can (and do) with OPIE. --Kim D. Petersen (talk) 17:19, 3 June 2008 (UTC)

Improve history section with when major versions where released

History section could be improved by adding major version numbers and the date they were released and perhaps a note about the major features in the new version. Daniel.Cardenas (talk) 17:32, 13 October 2008 (UTC)

standalone applications

I know that applications that run on Linux typically use glibc. But what about the Linux kernel itself? Does it use glibc? I've been told that glibc doesn't work for "standalone applications" such as the Linux kernel. I hear that "standalone applications" require a library that supports standalone applications[4], a library such as newlib. Is this true? Or a misconception common enough that this article needs to directly confront? --68.0.124.33 (talk) 13:58, 7 April 2009 (UTC)

Here's a primer. Chris Cunningham (not at work) - talk 15:02, 7 April 2009 (UTC)

Thank you for the reference. It agrees that the Linux kernel does not directly call any function in the glibc library, although the Linux kernel does have the "Supporting OS subroutines required" for user applications that call functions in the glibc library.

One more question: I see that the Linux kernel calls at least some C standard library functions and constants such as memcpy(), tolower(), and INT_MAX -- search for "memcpy" in the Linux kernel, search for "tolower" in the Linux kernel, and search for "INT_MAX" in the Linux kernel.

So what library implements those functions? --68.0.124.33 (talk) 07:20, 21 April 2009 (UTC)

In kernelspace these functions are declared by specific kernel headers and implemented in specific kernel files; for memcpy at least Linux appears to implement them using machine-specific assembly files (if you look on the search page you linked, there's a section where there are a bunch of files include/asm/asm-$arch/string.h that declares the function, so presumably there's a string.s file with the assembly code.

This is not at all unusual for production-grade operating systems. —Preceding unsigned comment added by 74.96.138.199 (talk) 00:07, 18 February 2010 (UTC)

Sun RPC code

Someone with more knowledge about this than me could maybe add this information/link to the article. Basically, glibc is really free software since August 18, 2010. --82.171.70.54 (talk) 23:01, 27 August 2010 (UTC)

When the support for Intel 386 was dropped?

I think this shall be mentioned in the version history comments. --RokerHRO (talk) 20:01, 5 November 2014 (UTC)

License requires to be able to relink derived software?

The GNU C Library is LGPL licensed. Part of the LGPL is this section:

If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it.

Just as with the Qt library (see https://www.qt.io/faq section 3.7), this means that every application that uses the GNU C Library, including proprietary products, needs to provide complete object files to end users. But this cannot be true, because the GNU C Library is statically linked into any commercial product that has been compiled with the GNU compiler suite. What am I missing here?

As a side node, it makes no difference if you link statically or dynamically - you always are in need to provide everything so the end user can re-link the final product.

--pluckerwank (talk) 11:58, 26 September 2019 (UTC)

please reinstate the "adoption" column

please reinstate the "adoption" column in the table of versions, it was extremely useful 5.90.164.175 (talk) 19:18, 12 June 2023 (UTC)

This column is the reason that this page is the only wikipedia page in my bookmarks list.

> improve the table to avoid unnecessary line-breaks where possible

Not really an improvement, in fact the table column widths are now badly distributed as well as losing information.

Perhaps Evelyn_Marie made a mistake here? 203.217.18.114 (talk) 07:45, 4 August 2023 (UTC)

i'm not reinstating that. it was a useless column that was never updated and people don't care when distributions adopt a new glibc version. - Evelyn Marie (leave a message · contributions) 08:19, 4 August 2023 (UTC)

People are telling you otherwise here. That column is one of the most useful things on this page, it tells you what distro and version to use if you want to set up a build platform targetting a specific glibc; it also helps debug glibc discrepancies. We've used this as a reference for years now in the Node.js build team to plan and set up build toolchains to target the widest possible set of distributions. If you do variations of google searches for this table you'll see that we're far from the only ones: https://www.google.com/search?q=https%3A%2F%2Fen.wiki.x.io%2Fwiki%2F+%22GNU_C_Library%22+%22version+history%22

- Rvagg Rvagg (talk) 07:09, 5 August 2023 (UTC)