C standard library
The C standard library or libc is the standard library for the C programming language, as specified in the ANSI C standard.[1] It was developed at the same time as the C library POSIX specification, which is a superset of it.[2][3] Since ANSI C was adopted by the International Organization for Standardization,[4] the C standard library is also called the ISO C library.
The C standard library provides macros, type definitions and functions for tasks such as string handling, mathematical computations, input/output processing, memory management, and several other operating system services.
ANSI
ANSI C, ISO C and Standard C refer to the successive standards for the C programming language published by the American National Standards Institute (ANSI) and the International Organization for Standardization (ISO). Historically, the names referred specifically to the original and best-supported version of the standard (known as C89 or C90). Software developers writing in C are encouraged to conform to the standards, as doing so helps portability between compilers.
GNU C Library
“glibc” redirects here. It is not to be confused with GLib or Gnulib.
The GNU C Library, commonly known as glibc, is the GNU Project’s implementation of the C standard library. Despite its name, it now also directly supports C++ (and, indirectly, other programming languages). It was started in the early 1990s by the Free Software Foundation (FSF) for their GNU operating system.
Released under the GNU Lesser General Public License[3], glibc is free software.
GNU
GNU /ɡnuː/ (About this sound listen)[3][4] is an operating system[5][6][7] and an extensive collection of computer software. GNU is composed wholly of free software,[8][9][10] most of which is licensed under the GNU Project’s own GPL.
GNU is a recursive acronym for “GNU’s Not Unix!”,[8][11] chosen because GNU’s design is Unix-like, but differs from Unix by being free software and containing no Unix code.[8][12][13] The GNU project includes an operating system kernel, GNU HURD, which was the original focus of the Free Software Foundation (FSF).[8][14][15][16] However, non-GNU kernels, most famously Linux, can also be used with GNU software; as the Hurd kernel is not yet production-ready,[17] this is how the GNU system is usually used.[18][19] The combination of GNU software and the Linux kernel is commonly known as Linux (or less frequently GNU/Linux; see GNU/Linux naming controversy).
Richard Stallman, the founder of the project, views GNU as a “technical means to a social end”.[20] Relatedly Lawrence Lessig states in his introduction to the second edition of Stallman’s book Free Software, Free Society that in it Stallman has written about “the social aspects of software and how Free Software can create community and social justice.”[21]GNU Project
he GNU Project /ɡnuː/ (About this sound listen)[3] is a free-software, mass-collaboration project, first announced on September 27, 1983 by Richard Stallman at MIT. Its aim is to give computer users freedom and control in their use of their computers and computing devices, by collaboratively developing and providing software that is based on the following freedom rights: users are free to run the software, share it (copy, distribute), study it and modify it. GNU software guarantees these freedom-rights legally (via its license), and is therefore free software; the use of the word “free” always being taken to refer to freedom.
In order to ensure that the entire software of a computer grants its users all freedom rights (use, share, study, modify), even the most fundamental and important part, the operating system (including all its numerous utility programs), needed to be free software. According to its manifesto, the founding goal of the project was to build a free operating system and, if possible, “everything useful that normally comes with a Unix system so that one could get along without any software that is not free.” Stallman decided to call this operating system GNU (a recursive acronym meaning “GNU’s not Unix”), basing its design on that of Unix, a proprietary operating system.[4] Development was initiated in January 1984. In 1991, the kernel Linux appeared, developed outside the GNU project by Linus Torvalds,[5] and in December 1992 it was made available under version 2 of the GNU General Public License.[6] Combined with the operating system utilities already developed by the GNU project, it allowed for the first operating system that was free software, known as Linux or GNU/Linux.[7][8]
The project’s current work includes software development, awareness building, political campaigning and sharing of the new material.
链接戳我
What is glibc?
The GNU C Library project provides the core libraries for the GNU system and GNU/Linux systems, as well as many other systems that use Linux as the kernel. These libraries provide critical APIs including ISO C11, POSIX.1-2008, BSD, OS-specific APIs and more. These APIs include such foundational facilities as open, read, write, malloc, printf, getaddrinfo, dlopen, pthread_create, crypt, login, exit and more.
The GNU C Library is designed to be a backwards compatible, portable, and high performance ISO C library. It aims to follow all relevant standards including ISO C11, POSIX.1-2008, and IEEE 754-2008.
The project was started circa 1988 and is almost 30 years old. You can see the complete project release history on the wiki.
Despite the project’s age there is still a lot to do so please Get Started and Get Involved!
Current Status
The GNU C Library releases every 6 months. See the NEWS file in the glibc sources for more information.
The current stable version of glibc is 2.26, released on August 2, 2017.
The current development version of glibc 2.27, releasing on or around February 1, 2018.
原链接
libc is the C library; basically, it contains all of the system functions that most (if not all) programs need to run on Linux. It’s similar to a combination of dos.library and exec.library on Amigas, but it also contains a lot of things that are in the C runtime library (like, for example, ixemul.library or the .lib files included with SAS/C and other compilers for AmigaOS).
libc6 and glibc are the same version of libc; officially, it’s version 2 of the GNU C Library (but it’s the sixth major version of the Linux C library). You can read more about glibc at the GNU C Library pages.
The major versions of libc for Linux/m68k are:
libc4: Version 4 of the C library is based on the a.out binary format; it was the first version to support dynamic linking (shared libraries). However, a.out dynamic linking had a lot of problems (for example, you had to build the library twice, so you could add a jump table to the library on the second pass, and the library was non-relocatable, so every library had to be allocated a block of space to load into), so it was abandoned (at least on m68k; Intel users may still need it for some esoteric applications). You should not be using libc4 for anything any more. If you do use it, we will hunt you down and execute you as an example to others. (Not really, but you get the point…)
libc5: Version 5 of the C library was a fairly big improvement over version 4. However, it still had some problems (adding new functions or changing structure sizes introduced subtle bugs) so it is no longer being actively developed. It was the first version of the Linux C Library based on ELF, a different file format that made programs loadable in more flexible ways (it uses hunks, similar to the AmigaOS executable file format). libc5 is officially deprecated on m68k; use libc6 for new compilations.
libc6: Version 6 of the Linux C Library is version 2 of the GNU C Library; the confusion is because Linux has had multiple C library versions. This is the newest technology available, and includes features (like “weak symbols”) that theoretically allow new functions and modified structures in the library without breaking existing code that uses version 6, and avoid kernel version dependency problems. You should be coding and compiling all code against this version.
原链接
libc implements both standard C functions like strcpy() and POSIX functions (which may be system calls) like getpid(). Note that not all standard C functions are in libc - most math functions are in libm.
You cannot directly make system calls in the same way that you call normal functions because calls to the kernel aren’t normal function calls, so they can’t be resolved by the linker. Instead, architecture-specific assembly language thunks are used to call into the kernel - you can of course write these directly in your own program too, but you don’t need to because libc provides them for you.
Note that in Linux it is the combination of the kernel and libc that provides the POSIX API. libc adds a decent amount of value - not every POSIX function is necessarily a system call, and for the ones that are, the kernel behaviour isn’t always POSIX conforming.
libc is a single library file (both .so and .a versions are available) and in most cases resides in /usr/lib. However, the glibc (GNU libc) project provides more than just libc - it also provides the libm mentioned earlier, and other core libraries like libpthread. So libc is just one of the libraries provided by glibc - and there are other alternate implementations of libc other than glibc.
the GNU Compiler Collection
GNU编译器套装(英语:GNU Compiler Collection,缩写为GCC),指一套编程语言编译器,以GPL及LGPL许可证所发行的自由软件,也是GNU项目的关键部分,也是GNU工具链的主要组成部分之一。GCC(特别是其中的C语言编译器)也常被认为是跨平台编译器的事实标准。1985年由理查德·马修·斯托曼开始发展,现在由自由软件基金会负责维护工作。
原名为GNU C语言编译器(GNU C Compiler),因为它原本只能处理C语言。GCC在发布后很快地得到扩展,变得可处理C++。之后也变得可处理Fortran、Pascal、Objective-C、Java、Ada,Go与其他语言。
许多操作系统,包括许多类Unix系统,如Linux及BSD家族都采用GCC作为标准编译器。苹果电脑预装的Mac OS X操作系统也采用这个编译器。
GCC原本用C开发,后来因为LLVM、Clang的崛起,它更快地将开发语言转换为C++。许多C的爱好者在对C++一知半解的情况下主观认定C++的性能一定会输给C,但是Taylor给出了不同的意见,并表明C++不但性能不输给C,而且能设计出更好,更容易维护的程序(GCC’s move to C++)
链接戳我
The GNU Compiler Collection includes front ends for C, C++, Objective-C, Fortran, Ada, and Go, as well as libraries for these languages (libstdc++,…). GCC was originally written as the compiler for the GNU operating system. The GNU system was developed to be 100% free software, free in the sense that it respects the user’s freedom.
We strive to provide regular, high quality releases, which we want to work well on a variety of native and cross targets (including GNU/Linux), and encourage everyone to contribute changes or help testing GCC. Our sources are readily and freely available via SVN and weekly snapshots.
Major decisions about GCC are made by the steering committee, guided by the mission statement.
gcc and g++ are compiler-drivers of the ‘Gnu Compiler Collection’ (which was once upon a time just the ‘Gnu C Compiler’).
Even though they automatically determine which backends (cc1 cc1plus …) to call depending on the file-type, unless overridden with -x language, they have some differences.
The probably most important difference in their defaults is which libraries they link against automatically.
According to 1 and 2, g++ is equivalent to gcc -xc++ -lstdc++ -shared-libgcc (the 1st is a compiler option, the 2nd two are linker options). This can be checked by running both with the -v option (it displays the backend toolchain commands being run).
gcc 最开始的时候是 GNU C Compiler, 如你所知,就是一个c编译器。但是后来因为这个项目里边集成了更多其他不同语言的编译器,GCC就代表 the GNU Compiler Collection,所以表示一堆编译器的合集。 g++则是GCC的c++编译器。现在你在编译代码时调用的gcc,已经不是当初那个c语言编译器了,更确切的说他是一个驱动程序,根据代码的后缀名来判断调用c编译器还是c++编译器 (g++)。比如你的代码后缀是*.c,他会调用c编译器还有linker去链接c的library。如果你的代码后缀是cpp, 他会调用g++编译器,当然library call也是c++版本的。当然我说了这么多你可能感到有些混乱,没关系,你就把gcc当成c语言编译器,g++当成c++语言编译器用就是了。
作者:李锋
链接:https://www.zhihu.com/question/20940822/answer/16667772
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
一:gcc与g++比较
编译c/c++代码的时候,有人用gcc,有人用g++,于是各种说法都来了,譬如c代码用gcc,而 c++代码用g++,或者说编译用gcc,链接用g++,一时也不知哪个说法正确,如果再遇上个extern “C”,分歧就更多了,这里我想作个了结,毕竟知识的目的是令人更清醒,而不是更糊涂。
误区一:gcc只能编译c代码,g++只能编译c++代码两者都可以,但是请注意:
1.后缀为.c的,gcc把它当作是C程序,而g++当作是c++程序;后缀为.cpp的,两者都会认为是c++程序,注意,虽然c++是c的超集,但是两者对语法的要求是有区别的,例如
#include
int main(int argc, char* argv[]) {
if(argv == 0) return;
printString(argv);
return 0;
}
int printString(char* string) {
sprintf(string, "This is a test.\n")
}
如果按照C的语法规则,OK,没问题,但是,一旦把后缀改为cpp,立刻报三个错:
“printString未定义”;
“cannot convert char**' to
char*”;
”return-statement with no value“;
分别对应前面红色标注的部分。可见C++的语法规则更加严谨一些。
2.编译阶段,g++会调用gcc,对于c++代码,两者是等价的,但是因为gcc命令不能自动和C++程序使用的库联接,所以通常用g++来完成链接,为了统一起见,干脆编译/链接统统用g++了,这就给人一种错觉,好像cpp程序只能用g++似的。
误区二:gcc不会定义__cplusplus宏,而g++会
实际上,这个宏只是标志着编译器将会把代码按C还是C++语法来解释,如上所述,如果后缀为.c,并且采用gcc编译器,则该宏就是未定义的,否则,就是已定义。
误区三:编译只能用gcc,链接只能用g++
严格来说,这句话不算错误,但是它混淆了概念,应该这样说:编译可以用gcc/g++,而链接可以用g++或者gcc -lstdc++。因为gcc命令不能自动和C++程序使用的库联接,所以通常使用g++来完成联接。但在编译阶段,g++会自动调用gcc,二者等价。
误区四:extern “C”与gcc/g++有关系
实际上并无关系,无论是gcc还是g++,用extern “c”时,都是以C的命名方式来为symbol命名,否则,都以c++方式命名。
二:gcc和g++的包含头文件库文件方法
-l参数就是用来指定程序要链接的库,-l参数紧接着就是库名,那么库名跟真正的库文件名有什么关系呢?就拿数学库来说,他的库名是m,他的库文件名是libm.so,很容易看出,把库文件名的头lib和尾.so去掉就是库名了。
好了现在我们知道怎么得到库名,当我们自已要用到一个第三方提供的库名字libtest.so,那么我们只要把 libtest.so拷贝到/usr/lib里,编译时加上-ltest参数,我们就能用上libtest.so库了(当然要用libtest.so库里 的函数,我们还需要与libtest.so配套的头文件)
放在/lib和/usr/lib和/usr/local/lib里的库直接用-l参数就能链接了,但如果库文件没放 在这三个目录里,而是放在其他目录里,这时我们只用-l参数的话,链接还是会出错,出错信息大概是:“/usr/bin/ld: cannot find -lxxx”,也就是链接程序ld在那3个目录里找不到libxxx.so,这时另外一个参数-L就派上用场了,比如常用的X11的库,它在/usr /X11R6/lib目录下,我们编译时就要用-L/usr/X11R6/lib -lX11参数,-L参数跟着的是库文件所在的目录名。再比如我们把libtest.so放在/aaa/bbb/ccc目录下,
那链接参数就是-L /aaa/bbb/ccc -ltest另外,大部分libxxxx.so只是一个链接,以RH9为例,比如libm.so它链接到/lib/libm.so.x,/lib/libm.so.6又链接到/lib/libm-2.3.2.so,如果没有这样的链接,还是会出错,因为ld只会找libxxxx.so,所以如果你要用到xxxx库,而只有libxxxx.so.x或者libxxxx-x.x.x.so,做一个链接就可以了ln -s libxxxx-x.x.x.so libxxxx.so
手工来写链接参数总是很麻烦的,还好很多库开发包提供了生成链接参数的程序,名字一般叫xxxx-config,一般放在/usr/bin目录下,比如gtk1.2的链接参数生成程序是gtk-config,执行gtk-config –libs就能得到以下输出”-L/usr/lib -L/usr/X11R6/lib -lgtk -lgdk -rdynamic-lgmodule -lglib -ldl -lXi -lXext -lX11 -lm”,这就是编译一个gtk1.2程序所需的gtk链接参数,xxx-config除了–libs参数外还有一个参数是–cflags用来生成头 文件包含目录的,也就是-I参数,在下面我们将会讲到。
你可以试试执行gtk-config –libs –cflags,看看输出结果现在的问题就是怎样用这些输出结果了,最笨的方法就是复制粘贴或者照抄,聪明的办法是在编译命令行里加入这个 xxxx-config --libs --cflags
,比如编译一个gtk程序:gcc gtktest.c gtk-config --libs --cflags
这样就差不多了。注意`不是单引号,而是1键左边那个键。
5、-include和-I参数
-include用来包含头文件,但一般情况下包含头文件都在源码里用#include xxxxxx实现,-include参数很少用。-I参数是用来指定头文件目录,/usr/include目录一般是不用指定的,gcc知道去那里找,但 是如果头文件不在/usr/include里我们就要用-I参数指定了,比如头文件放在/myinclude目录里,那编译命令行就要加上-I /myinclude参数了,如果不加你会得到一个”xxxx.h: No such file or directory”的错误。-I参数可以用相对路径,比如头文件在当前目录,可以用-I.来指定。
结论例子: g++ curltest.cpp -o curltest -L/mnt/hgfs/windows/curl-7.19.5/lib/.libs -lcurl -I/mnt/hgfs/windows/curl-7.19.5/include
libc 等这些库十分重要,那么了解自己机器上的库版本是十分重要的。
stackoverflow回答
To find which library is being used you could run
(1) 方式一
$ /sbin/ldconfig -p | grep stdc++
libstdc++.so.6 (libc6) => /usr/lib/libstdc++.so.6
(2) 方式二
$ locate libstdc++.so
/usr/lib/gcc/x86_64-redhat-linux/3.4.6/libstdc++.so
/usr/lib/gcc/x86_64-redhat-linux/3.4.6/32/libstdc++.so
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/libstdc++.so
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/libstdc++.so
/usr/lib64/libstdc++.so.5
/usr/lib64/libstdc++.so.5.0.7
/usr/lib64/libstdc++.so.6
/usr/lib64/libstdc++.so.6.0.13
其中,如果用 ll 仔细看,有些是软链接,指向一个具体的版本,如 /usr/libstdc++.so.6 ( libstdc++.so.6 -> libstdc++.so.6.0.13 ),这个软链接搜索过程是:链接程序ld-linux.so 先后搜索elf文件的 DT_RPATH段—环境变量LD_LIBRARY_PATH—/etc/ld.so.cache文件列表—/lib/, /usr/lib, /usr/lib64 …。
$ strings /usr/lib/libstdc++.so.6 | grep LIBCXX
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
…
很多时候,我们在自己机器上编译完成了 C/C++ 程序,但是放在其他机器上会出现类似 /usr/lib/libstdc++.so.6: version GLIBCXX_3.4.9' not found 这个错误。
readelf -a
[stackoverflow回答](https://stackoverflow.com/questions/4133674/glibcxx-versions)
就是说,GLIBCXX_3.4.* 这一系列版本都是想下兼容,高的版本可能做了 一些改动。那么 c 程序 link 的时候,会用到新版本的东西,就出现了这个错误。
用and
objdump -x` 可以查看 c 程序里哪里用到了哪个版本的库函数。
注: objdump命令的使用objdump命令是Linux下的反汇编目标文件或者可执行文件的命令。