免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
查看: 3102 | 回复: 0
打印 上一主题 下一主题

gcc编译选项 [复制链接]

论坛徽章:
1
2015年辞旧岁徽章
日期:2015-03-03 16:54:15
跳转到指定楼层
1 [收藏(0)] [报告]
发表于 2010-02-02 22:02 |只看该作者 |倒序浏览

               
1.GCC支持的编程语言
GCC(GNU Compiler Collection)的意思是“GNU编译器套装”,它是一些主要编程语言的编译器的集合。这些语言包括[color="#990033"]C, C++, Objective-C, Objective-C++, Java, Fortran和Ada.
2.GCC支持的语言标准
每一种遵从GCC(有一个标准)的语言,GCC尝试遵循这个标准的一个或更多版本,这样可能会产生一些异常,或者一些扩展。
GCC支持三个版本的C标准,尽管对其中某些最新版本的支持还不完善。
最初的ANSI C (X3.159-1989)标准于1989年被批准,1990年发表。这个标准随后在1990年被作为iso(ISO/IEC 9899:1990)标准的一部分。这两个公开发表的技术没有什么不同,尽管这个ANSI标准的部分被重新编号同时成为iso标准的条款。这个标准从被批准之日起通常被称为C89,偶尔称为C90。ANSI标准,而不是ISO标准,同时还有一份说明文档。在GCC中,我们可以通过-ansi、-std=c89或者-std=iso9899:1990等选项来获得这个标准所必需的图形。你同样需要指明-pedantic(或者-pedantic-errors,如果你想它们是错误而不是警告)。参考Options Controlling C Dialect.
1994年和1996年发表的两个技术勘误表修正了1990年ISO C标准的一些错误。GCC不支持未修正的版本。
1990标准的一个修正版在1995年发表。这个标准把有向图(digraphs)和__STDC_VERSION__加入语言,但是如果没有的话就要考虑库。这个标准通常被称为AMD1;被修正的标准有时被称为C94或者C95。我们可以通过-std=iso9899:199409在GCC中选择这个标准(在其他版本标准中,使用-pedantic来获得所有必需的特性)。
一个新版本的ISO C标准“ISO/IEC 9899:1999”在1999年发表,通常被称为C99。GCC对这个版本有不完全的支持。参考
http://gcc.gnu.org/gcc-4.0/c99status.html
获得更多细节。可以使用-std=c99或者-std=iso9899:1999来选择这个标准(这个标准正在发展中,它的草案被称为C9X)。
2001年和2004年发表的两篇技术勘误表修正了1999 ISO C标准中的错误。GCC不支持未修正的版本。
默认的,GCC提供了C语言的一些拓展,在少数情况下,这些拓展会和C标准产生冲突。参考Extensions to the C Language Family.使用上面列举的-std选项会禁止[和选择的C标准相冲突的]拓展。也可以使用-std=gnu89 (带GNU拓展的C89) or -std=gnu99 (带GNU拓展的C99)来明确的选择一个C语言的拓展版本。当没有明确的选项给出时,默认选项是-std=gnu89。在未来的版本中,当对C99的支持完成时默认选项将会变为-std=gnu99。一些C99标准中的特性被当成C89标准的拓展。
ISO C标准定义了(条款4)两类一致的实现。一致主机实现支持包括所有库工具在内的整个标准,一致独立实现只提供某些库工具:它们位于、 、和;从AMD1起,也在中;在C99中,同样位于和。C99中增加的复杂类型并未要求单独的实现。这一标准同时还定义了两种编程环境,一种是独立环境,处理程序起动和终止实施被定义的必需所有实施;另一种是主机环境,它不是必需的,提供所有的库工具,启动是通过函数int main (void)或int main (int, char *[])。一个操作系统内核是一个独立环境,一个使用操作系统工具的程序通常是在主机环境中。
GCC的目标是能当作一个一致的独立实现,或者一个一致的主机实现的编译器。默认的,它会作为一个主机实现的编译器,定义__STDC_HOSTED__为1。当使用ISO C函数时,标准中有语义定义。若要使GCC作为独立环境中的一致独立实现,使用-ffreestanding选项,它会定义__STDC_HOSTED__为0,并对标准库中的函数名不做假定,除了以下列出的例外。为生成一个操作系统内核,你需要为链接和启动作出安排。参考Options Controlling C Dialect。
GCC没有提供主机实现需要的库工具,和所有C99中独立环境需要的的工具;要使用主机环境的工具时,你需要在别处找到它们(例如在GNU C库中)。参考Standard Libraries。
GCC中多数的编译器支持程序在libgcc中,也有少数例外。GCC需要独立环境来提供memcpy、memmove、memset和memcmp。最后,如果使用__builtin_trap,而且目标没有实现陷阱模式,那么GCC会产生一个中断。
在网络上可以找到技术勘误表、基本原理文档和C的历史相关的文档,参考
http://gcc.gnu.org/readings.html

Objective-C和Objective-C++没有正式的标准。最权威的说明是“面向对象程序和Objective-C语言”,在以下网站可以找到:

http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/
是最近的版本(周期性更新);

http://www.toodarkpark.org/computers/objc/
是一个旧的版本;

http://www.gnustep.org

http://gcc.gnu.org/readings.html
有额外的有用信息。
GCC的一个样本语言前端Treelang没有标准,它存在的唯一目的是给希望为GCC写一个新语言的人提供一个样本。它的文档位于gcc/treelang/treelang.texi,可以以HTML方式查看。
参考GNAT Reference Manual查看关于Ada编译器一致性和兼容性的信息。
参考Standards查看gfortran支持的标准细节。
参考Compatibility with the Java Platform查看gcj和Java平台之间的兼容性细节。

3.1通用选项
编译可包括四个过程:预处理、编译、汇编和链接。始终按照这个顺序来进行。gcc能够预处理和编译一些文件成为几个汇编输入文件或一个汇编输入文件.然后,每个汇编输入文件产生一个目标文件.最后,gcc结合所有的目标文件来生成一个可执行文件.
对于任何给定的输入文件,该文件名后缀决定了编译的哪个过程已经完成:
[color="#990033"]file.c
必须要进行预处理的c源文件
[color="#990000"]file.i
不应该再进行预处理的c源文件
[color="#990000"]file.ii
不应该再进行预处理的c++源文件
[color="#990000"]file.h
C, C++, Objective-C or Objective-C++的头文件,将会转变为预编译头
[color="#990000"]file.cc
file.cp
file.cxx
file.cpp
file.CPP
file.c++
file.C
必须要进行预处理的c++源代码.
[color="#990000"]file.hh
file.H
file.hp
file.hxx
file.hpp
file.HPP
file.h++
file.tcc
将要转化为预编译头的c++头文件
[color="#990000"]file.s
汇编代码
[color="#990000"]file.S
必须要预编译的汇编代码
你可以使用-x选项来明确地指定输入文件使用的语言:
[color="#990000"]-x language
明确地为接下来(此处的-x和下一个-x之间)的输入文件指定语言类型,而不是让编译器根据文件名后缀选择默认的语言类型.这个语言类型只能应用于这个-x和下一个-x之间.可用的语言类型值如下:
   c  c-header  c-cpp-output
          c++  c++-header  c++-cpp-output
          objective-c  objective-c-header  objective-c-cpp-output
          objective-c++ objective-c++-header objective-c++-cpp-output
          assembler  assembler-with-cpp
          ada
          f77  f77-cpp-input f95  f95-cpp-input
          java
[color="#990000"]-x none
关闭任何使用-x指定的语言类型.接下来,编译器根据文件名后缀选择默认的语言类型.
[color="#990000"]-pass-exit-codes
通常情况下,假如在编译的任一阶段(共四个阶段)返回non-success的返回值,gcc会return 1.假如你指定了-pass-exit-codes,gcc会返回一个错误指示符.假如编译过程中有error发生,C,
C++, and Fortran frontends return 4.
假如你仅仅需要编译的某几个阶段,你可以使用-x来告诉gcc什么时候开始,而-c,-S,-E这三个选项
之中的一个则告知gcc什么时候结束.注意,一些组合(比如"-x cpp-output -E")指示gcc什么都不作.
[color="#990000"]-c
编译 or 汇编源文件,但不链接.最终的输出,是每个源文件的目标文件的形式.by default,每个源文件对应的目标文件的名字是通过替换源文件的后缀'.c','.i','.s'为'.o'来产生的。
[color="#990000"]-S
编译以后停止,不进行汇编。by default,每个源文件对应的目标文件的名字是通过替换源文件的后缀'.c','.i'为'.s'来产生的。
[color="#660000"]-E
预处理完成后停止,不进行编译。
[color="#660000"]-o
指定输出文件。这适用于不论在任何类型的输出正在制作,无论是一个可执行文件,一个目标文件,汇编文件或预处理的C代码。
[color="#990000"]-v
在标准错误输出打印命令所执行的详细的命令。同时打印编译器的驱动程序的版本号和预处理器和编译器的版本号。
[color="#660000"]-pipe
使用管道而不是临时文件来作为不同编译阶段的通讯手段。需要注意的是,在有些系统上,汇编程序不能从管道读取,使用此选项会导致失败。但是GUN 汇编程序是没有问题的。
[color="#660000"]-combine
假如你在编译多个源文件,'-combine'告诉gcc驱动马上传递所有的源文件给编译器.这将会允许IMA(intermodule analysis)被编译器执行.目前,仅c语言支持这么做。
[color="#990000"]--target-help
在标准输出端打印对每个工具的target-specific命令选项的描述。
[color="#660000"]--help={class|[^]qualifier}[,...]
输出(在标准输出)能被编译器识别的符合制定类和限定词的命令行选项.这些是所支持的类:
'optimizers'
显示编译器支持的所有的优化选项
'warnings'
显示控制警告信息的选项
'target'
显示target-specific选项。不同于--target-help,target-specific的链接和汇编选项不会被显示
'params'
显示能被'--param'选项识别的值
language
显示被language支持的选项。此处的language是被这个版本的gcc所支持的语言之一的名字。
'common'
显示针对所有语言都共有的选项
这些是所支持的限定词:
'undocumented'
显示没有经正式文件确认得选项
'joined'
显示后面通过等号带有一个变量的选项,比如:'--help=target'
'separate'
显示后面带有一个分隔符分开的选项的选项,比如:'-o  output-file'
examples:
--help=target,undocumented
显示所有未被正式文件承认的、target-specific的选项
note:限定词的语义可以通过添加'^'发生反转。
--help=warnings,^joined,^undocumented
显示所有控制警告信息的选项(不显示'--help=target'这种类型的、不显示没有经正式
文件确认的选项)
--help=target,optimizers
显示target-specific的优化选项
[color="#660000"]-no-canonical-prefixes

[color="#660000"]--version
显示gcc的版本号和版权
[color="#660000"]-wrapper
为所有的子程序添加包装程序。
eg:gcc -c t.c -wrapper gdb,--args
这将会为gcc的各个子程序添加包装程序"gdb –args"。因而gcc的cc1调用将会变成
"gdb --args cc1 ...".
[color="#660000"]-fplugin=name.so
从name.so文件中加载插件代码。比如编译器通过dlopen从一个共享文件name.so里加载插件代码。每个插件都应该定义在插件API里边指定的回调函数。
[color="#990000"]-fplugin-arg-name-key=value
为名为name的插件定义变量key,key的值为value。
[color="#660000"]@file
从file文件读取命令行选项。
3.2c语言选项
[color="#990000"]-ansi
in C mode,这等价于'-std=c89';in c++ mode,这等价于 '-std=c++98'这将会关闭gcc的某些特性,比如和ISO C90不兼容的特性(当编译c模式时),再比如标 准c++里边,asm和typeof关键字,以及象unix和vax这些指定你所运行的系统的type的预 定义宏 。它还使能不受人欢迎的、很少使用的ISO三元符特征。对于c编译器,将关 闭c++类型的'//'注释符以及inline关键字.一些备用的关键字,如__asm__,__extension__,__inline__以及__typeof__,不管有没有指定-ansi,都可以正常使用.你不应该在ISO c程序里边使用它们.but it is useful  to put them in header files that might be included in compilations done with  -ansi.备用预定义宏,如__unix__和__vax__,不管有没有-ansi,仍旧可以正常使用.-ansi选项不会无理的拒绝non-ISO程序.-pedantic被要求添加在-ansi选项的后面.当-ansi选项被指定时,宏__STRICT_ANSI__被预定义.一些头文件会注意到此宏并且不会声明一些ISO标准不要求的函数或宏定义.这是为了避免与任何可能会使用这些名字作其他事情的程序冲突.当-ansi被使用时,一些没有按照ISO C的语法定义的内建函数不再作为内建函数被使用.
[color="#660000"]-std
决定语言标准.这个选项目前仅仅支持c/c++编译器可以接受好几个基本标准,比如'c89' or 'c++98',以及gnu语调下的'gnu89' or  'gun++98'.通过指定一个标准,编译器将会接受所有[遵循此标准和与此标准不矛盾的gnu扩展]的程序.比如'-std=c89'关闭gcc的某些与ISO C90不兼容的特性,比如asm和typeof
关键字,但不会关闭在ISO C90没有含义的其他gnu扩展.另一方面,通过指定gnuc语调的标准,编译器支持的所有特性都是被支持的,甚至当这些特性改变了基本标准的语义或严格的一致性检查可能被拒绝. 具体的标准是使用'-pedantic'来确定gnu的哪些特性在那个版本的标准上是可用的.比如,'-std=gun89 -pedantic'会对c++类型的注释符"//"引起警 告,而'-std=gun99 -pedantic'则不会这个选项的值可能是:
`c89'
`iso9899:1990'
支持所有的ISO C90程序(和ISO C90冲突的一些gun扩展不可用).sanme as -ansi for c  
code
`iso9899:199409'
ISO C90修正版1
`c99'
`c9x'
`iso9899:1999'
`iso9899:199x'
ISO C99,注意此标准目前还没有被完全支持.
  'gnu89'
gun语调的ISO C90(包括一些c99的特性).this is default for c code
'gnu99'
'gnu9x'
gnu语调的ISO C99.等gcc完全支持ISO C99的时候,gun99 will become the default.
'gnu9x'这个名字是不赞成被使用的.
'c++98'
1998 ISO C++标准的修订版.Sanme as -ansi for c++ code
'gnu++98'
gnu语调的-std=c++98.this is the default for c++ code
'c++0x'
即将出来的ISO C++0x标准的工作草案.
'gun++0x'
gun语调的-std=c++0x
[color="#660000"]-fgnu89-inline
-fgnu89-inlineg选项告诉gcc在C99模式下使用传统的gnu语法来描述inline函数.这个选项被4.13以上不包括4.3版本的gcc所忽略.在gcc版本4.3以上,此选项改变了gcc在c99的行为.使用这个选项相当于为所有的inline函数添加gnu_inline这个函数属性.
[color="#990000"]-fno-gnu89-inline
明确告诉gcc在C99或者gnu99下使用C99的语法来描述inline函数.这个选项首先被gcc4.3支持.此选项不支持C89或gnu89模式预处理宏定义__GNUC_GNU_INLINE__和__GNUC_STDC_INLINE__可以被用来测试那种语义的inline函数在起作用.
[color="#660000"]-aux-info filename

[color="#660000"]-fno-asm
不把asm,inline或typeof识别为关键字,这样,代码就可以使用这些单词作标识符.你可以使用关键字__asm__,__inline__和__typeof__代替asm,inline和typeof.-ansi选项默认
-fno-asm选项.
在c++,这个选项仅仅作用于typeof关键字,因为asm和inline是标准关键字.你或许应该使用
-fno-gnu- keywords 标记,这和-fno-asm起同样的作用.在C99模式(-std=c99或-std=gnu99)这个选项仅仅作用于asm和typeof关键字,因为在ISO C99中,inline是标准关键字.
[color="#660000"]-fno-builtin
-fno-builtin-function
不识别不以'__builtin_'为前缀的内置函数.gcc通常通过产生特殊的代码去  操作内置函数来提高效率.例如,对alloca的调用可能是单指令的;对memcpy的调用可能是内联的循环拷贝.这样产生的代码不仅短小而且运行快.但是这样做也由于几个缺点,比如,你不能在这些函数调用上面设置断点,也不能通过连接不同的库来改变函数的行为.使用-fno-builtin-function选项来禁止内置函数.假如你想在使用fno-builtin或-
ffreestanding的时候有选择的使用内置函数,你可以这样做:
#define abs(n)          __builtin_abs ((n))
#define strcpy(d, s)    __builtin_strcpy ((d), (s))
[color="#660000"]-fhosted
声明汇编发生在主机环境里.this implies -fbuiltin.一个主机环境是这样一个环境:在这个环境里,所有的标准库是可用的,并且main有一个int类型的返回值.此选项等价于-fno-freestanding
[color="#660000"]-ffreestanding
声明汇编发生一个独立环境中.this implies -fno-builtin.一个独立环境是这样一个环境:在这里环境里,标准库是不存在的,并且应用程序的入口不一定是main.最明显的一个例子是一个OS kernel.此选项等价于-fno-hosted
[color="#660000"]-fopenmp
OpenMP提供了对并行算法的高层的抽象描述,程序员通过在原始碼中加入专用的pragma来指明自己的意图,由此编译器可以自动将程序进行并行化,并在必要之处加入同步互斥以及通信。当选择忽略这些pragma,或者编译器不支持OpenMP时,程序又可退化为通常的程序(一般为串行),代码仍然可以正常运作,只是不能利用多线程来加速程序执行。使能openMP的操作指示符(在c/c++是'#pragma omp').当-fopenmp被指定时,编译器根据OpenMP Application Program Interface v3.0产生平行代码.this option implies
-pthread.所以,此选项仅仅在支持-pthread的平台上面有效.
[color="#660000"]-fms-extensions
接受一些非标准结构的、使用在微软上的头文件。有时候,struct和union有一些未命名的fields,这只能被此选项接受。查看
http://gcc.gnu.org/onlinedocs/gcc/Unnamed-Fields.html#Unnamed-Fields
[color="#660000"]-trigraphs
支持ISO C三元符。三元符允许C程序只通过ISO 646-1983代码集进行编写。但是在ISO 646-1983代码集中并不支持一些符号,通过三元符可以使ISO 646-1983代码集合表示相应的C语言字符符号。三元符是一种由三个字符构成的字符串,当编译器解释的时候首先会将三元符转换成当个字符。通常为了C代码的安全,不推荐使用三元符。the ansi option implies -trigraphs
[color="#660000"]-no-integrated-cpp
按照预处理和编译这两个步骤执行编译的过程。使用该选项可以允许用户通过-B选项指定
"cc1", "cc1plus",或者 "cc1obj"。用户指定的编译步骤可以在正常的预处理之后,编译之前通过额外的预处理的方式加入整个编译的过程。默认使用内在的cpp。
[color="#660000"]-traditional
-traditional-cpp
以前,这些选项将会让GCC试图仿效早期的标准C编译器。现在,这些选项只有在使用-E选项的时候才起作用。预处理仍支持早期的C标准模式。参阅GNU CPP手册获得详细信息。
[color="#660000"]-fcond-mismatch
允许条件表达式的第二个和第三个参数的类型不匹配。这样一个表达式的值为viod。c++不支持该选项。
[color="#660000"]-flax-vector-conversions
允许具有不同元素个数或不同元素内容的向量进行隐式的转换。这个选项不应该在新的代码中使用。
[color="#660000"]-funsigned-char
将char类型无符号化,像unsigned char一样。各种机器都有自己缺省的char类型.既可能是unsigned char也可能是signed char。理想情况下,当依赖于数据的符号性时,一个可移植程序总是应该使用signed char或unsigned char.但是许多程序已经写成只用简单的char,并且期待这是有符号数(或者无符号数,具
体情况取决于编写程序的目标机器).这个选项,和它的反义选项,使那样的程序在对应的相反的默认值上仍能正常工作.char的类型始终应该明确定义为signed char或unsigned char,即使 它表现的和其中之一完全一样
.
[color="#660000"]-fsigned-char
把char类型符号化,像signed char一样。
[color="#660000"]-fsigned-bitfields
-funsigned-bitfields
-fno-signed-bitfields
-fno-unsigned-bitfields
如果没有明确声明`signed'或`unsigned'修饰符,这些选项用来定义有符号位域(bitfield)或无符号位域.缺省情况下,位域是有符号的,因为他们继承的基本整数类型,如int,是有符号数.
3.3连接选项
[color="#660000"]-c
-S
-E
假如上面选项中任意一个被使用,连接器不会运行。
[color="#660000"]-llibrary
-l library
连接时搜索名为library的库。(第二种形式仅仅用于POSIX标准,一般而言,是不被推荐使用的)在命令行中,你把这个选项放在不同的位置,它会产生不同的效果;连接器搜索并运行库和目标文件。这些库和目标文件是按顺序指定的。因而,'foo.o -lz bar.o'会在foo.o之后、bar.o之前搜索libz.a。假如bar.o也引用了libz.a里边的函数,那些函数是不会被加载的。连接器会从标准目录列表中寻找名为liblibrary.a的库,搜索的目录包括几个标准系统目录和任何用'-L'选项指定的目录。
通常,通过这种方法找到的文件都是库文件(其实是档案文件,档案文件的成员是一个一个的目标文件。一个文件定义一个符号,比如printf.o定义printf函数)。连接器扫描档案文件,寻找档案文件中那些[到目前为止已经被引用,但还没有被定义]的符号;但是假如找到的文件是一个普通的目标文件,它就会在普通的方式下被连接。使用'-l'选项和指定一个文件名的区别是:'-l' 用'lib'和'.a'包围'library'且'-l'搜索好几个目录。
[color="#990000"]-lobjc
你需要使用-l这个特殊选项来连接一个Objective-C或Objective-C++程序
[color="#660000"]-nostartfiles
连接时不使用标准系统启动文件,但标准系统库可以正常使用。除非-nostdlib或-nodefaultlibs选项被指定
[color="#660000"]-nodefaultlibs
连接时不使用标准系统库。 只有你指定的库才会被传递给连接器,一些指定系统库连接的选项,比如
-static-libgcc或-shared-libgcc,将会被忽略。标准启动文件可以正常使用,除非-nostartfiles选项被使用。对于memcmp,memset,memcpy和memmove,编译器会产生一些调用。这些入口一般会被libc里边对应的入口解析。当这个选项被指定的时候,这些入口指针应该通过一些其他的机制来提供(很明显,不使用标准系统库,当然就不使用libc库,所以需要其它的方式来实现如上几个函数)。
[color="#660000"]-nostdlib
连接时,不使用标准系统启动文件或标准系统库。对于memcmp,memset,memcpy和memmove,编译器会产生一些调用。这些入口一般会被libc里边对应的入口解析。当这个选项被指定的时候,这些入口指针应该通过一些其他的机制来提供(很明显,不使用标准系统库,当然就不使用libc库,所以需要其它的方式来实现如上几个函数)。标准库里边可以忽略-nostdlib和-nodefaultlibs选项的库是libgcc.a。libgcc.a是一个内部子程序的库,gcc使用它来克服一些特定机器的缺陷或某些语言的特定需要。在很多例子里边,即使当你避免使用标准系统库时,你也需要libgcc.a.换句话说,当你指定-nostdlib或-nodefaultlibs选项的时候,你通常也应该指定-lgcc.这可以确保你对内部gcc子程序库不会有未解决的引用。(比如,'__main',被用来确保c++构造器被调用)
[color="#660000"]-pie
用来生成与位置无关的代码。
Produce a position independent executable on targets which support it. For predictable results, you must also specify the same set of options that were used to generate code (-fpie, -fPIE, or model suboptions) when you specify this option.
[color="#990000"]-rdynamic
在支持此选项的平台上,把'-export-dynamic'传递给elf连接器。这将让连接器添加所有的符号、而不仅仅是用到的符号到动态符号表中。This option is needed for some uses of dlopen or to allow obtaining backtraces from within a program.
[color="#990000"]-s
从可执中移除所有的符号表和重定位信息。
[color="#990000"]-static
对那些支持动态链接的系统,用来预防那些共享库的连接。而对于其他的系统,这些选项对此没有任何效果。
[color="#660000"]-shared
产生一个[可以连接到其它目标文件生成一个可执行文件]的共享目标。不是所有的系统都支持这个选项。对于可预见的结果,当你指定这个选项的时候,你必须同时指定(-fpic,-fPIC等)这类选项来产生代码。
[color="#660000"]-shared-libgcc
-static-libgcc
在支持libgcc为共享库的那些系统上,这些选项让用户独立选择使用动态的libgcc或静态的libgcc
。当设置编译器的时候,如果没有建立共享的libgcc版本,那么这些选项无效。有很多情况下,一个应用程序应该使用共享的libgcc,而不是静态的libgcc。最常见的情况是:当应用程序希望抛出或抓获不同共享库里的异常。在怎种情况下,每个库连同应用程序都应该使用共享libgcc。因而,当你使用G++和GCJ编译一个共享库或者一个应用程序时,G++和GCJ自动添加-shared-libgcc选项。因为C++和java程序使用了异常处理,所以这就是需要做的合法的事情。相反的,如果你使用GCC驱动器去创建共享库,那你会发现它们通常不和共享的libgcc连接。如果在配置时间内,GCC发现你有一个不支持--eh-frame-hdr的non-GNU选项的连接器或GNU连接器,它就会通过缺省值来连接共享的libgcc。否则,它默认连接静态的libgcc。
[color="#660000"]-static-libstdc++
当G++程序用来连接一个C++程序时,它通常会自动连接libstdc++.假如存在libstdc++的共享库,并且
-static选项没有被使用,那么将会连接libstdc++的共享库版本.通常情况下,这是ok的.但是,有时候需要静态连接libstdc++.'-static-libstdc++'选项指示g++驱动仅仅静态连接libstdc++,同时不会静态连接其他的库.
[color="#660000"]-symbolic
当建立一个共享的目标文件时约定对全局符号的引用。警告任何一个未决的引用(除非不被连接的
`-Xlinker -z -Xlinker defs'编辑选项考虑)。只有很少的一部分系统会支持这些选项。
[color="#990000"]-T script
使用script作为连接脚本.这个选项被大多数[支持GNU的连接器]支持.在一些没有操作系统的"裸平台"上,需要指定'-T'来避免对未定义符号的引用.
[color="#660000"]-Xlinker option
把option作为一个选项给连接器.你可以使用这个选项来指定gcc不识别的、system-specific的连接选项。如果你想向连接器传递一个[带有一个分开的参数]的选项,那么你必须使用两次-Xlinker,一次是为选项,另一次则是为了参数。例如,为了传递'-assert definitions',你必须写成`-Xlinker
-assert -Xlinker definitions'。而不能写成-Xlinker "-assert definitions",因为这会将整
个字符串作为一个变量传递给连接器,这不是连接器所期待的。对于GNU连接器,还有一个更方便的方法是:使用"option=value"这样的语法来给连接器传递变量。比如,你可以指定'-Xlinker -Map=output.map'。这会比`-Xlinker -Map -Xlinker output.map'这种方式方便很多。但仅仅GNU连接器可以这样使用,其他的连接器可能不支持这么用

[color="#660000"]-Wl,option
把option作为一个选项给连接器。假如option包含了逗号,option在逗号处被分为多个选项。你可以使用这个语法来传递一个参数给选项。比如,`-Wl,-Map,output.map'传递`-Map output.map'给连接器。假如GNU连接器,这等价于`-Wl,-Map=output.map'。
[color="#660000"]-u symbol
假定symbol没有被定义,强行连接定义它的库模块。你可以多次使用'-u'选项来加载额外的需要的库模块。(Pretend the symbol symbol is undefined, to force linking of library modules to define it. You can use -u multiple times with different symbols to force loading of additional library modules. )
未完待续

               
               

本文来自ChinaUnix博客,如果查看原文请点:http://blog.chinaunix.net/u2/73067/showart_2168182.html
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP