GCC和链接环境变量和标志

Ame*_*ina 17 linker gcc build environment-variables

海湾合作委员会官方文件中的以下链接:

http://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html

解释以下环境变量:

LANG
LC_CTYPE
LC_MESSAGES
LC_ALL
TMPDIR
GCC_COMPARE_DEBUG
GCC_EXEC_PREFIX
COMPILER_PATH
LIBRARY_PATH
CPATH
C_INCLUDE_PATH
CPLUS_INCLUDE_PATH
OBJC_INCLUDE_PATH
DEPENDENCIES_OUTPUT
SUNPRO_DEPENDENCIES
Run Code Online (Sandbox Code Playgroud)

但我之前也听过/读过这些其他编译标志:

  • 编译C代码:CC,CFLAGS
  • 用于编译的C++代码:CXX,CPPFLAGS

和链接标志:

  • 对于链接阶段: LDFLAGS
  • 编译代码后: LD_LIBRARY_PATH

是什么意思CC,CFLAGS,CXX,和CPPFLAGS?为什么它们不包含在官方环境变量列表中gcc

Ale*_*aev 23

首先,所有的变量,你提到的:CC,CFLAGS,CXX,CXXFLAGS,LDFLAGS,LD_LIBRARY_PATH,都源于Unix操作系统家族.这些变量首先与GCC无关,这就是为什么你在手册中看不到它们的痕迹.

这些中唯一有意义的变量(与GCC没有直接联系)是LD_LIBRARY_PATH.你可能会发现这个变量可以在任何类似现代Unix的操作系统上开箱即用.这是Linux程序员手册中的LD.SO(8)手册页,其中提及了LD_LIBRARY_PATH它的用途.这是另外一个提取:

LD_LIBRARY_PATH环境变量包含由搜索到的目录的冒号分隔的列表动态链接程序寻找一个共享库加载时.

按照提及的顺序搜索目录.

如果未指定,则链接器使用默认值,即/lib:/usr/lib:/usr/local/lib.

正如您所看到的LD_LIBRARY_PATH,只有特定于操作系统的环境变量才能正确加载共享库.Windows在这方面有类似的环境变量:PATH.在搜索动态链接库(DLL,Linux上的SO对应物)时,Windows将扫描其中列出的目录.

关于变量的其余部分(CC,CFLAGS,CXX,CXXFLAGS,LDFLAGS),你看他们这样往往由于历史的原因.自Unix时代兴起以来,软件项目都是使用Make构建的(向下滚动并查看典型makefiles 的示例) - 一种开创性的构建工具.这些变量在makefiles中被如此广泛地使用,最终它们变成了一种约定(例如,参见隐式规则).这就是为什么你甚至可以在Linux上看到它们开箱即用的原因,并且最有可能指向GCC(因为它被认为是Linux的本机工具链).

最后,关键是:不要抓你的头了CC,CFLAGS,CXX,CXXFLAGS,LDFLAGS,和朋友,他们只是从过去的爆炸.;)

奖金


使用普通的旧版Make直接构建复杂的软件很快变得乏味且容易出错.结果,开发了许多复杂的构建系统生成器,如GNU AutomakeCMake.简而言之,他们的目标是提供(可以说)更易读,易于维护和高级的语法,以便为要构建的任意软件项目定义任意复杂的构建系统.通常,在实际构建项目之前,必须生成本机构建系统(也可以用普通的构建系统来表示)makefiles,例如,出于可移植性的原因,但不一定)使用相应的工具集来定义这个高级定义.最后,必须使用与生成的(本机)构建系统相对应的工具来构建项目(例如,在普通旧makefiles的情况下制作,但不一定).

由于您提出这些问题,我怀疑您即将使用C或C++深入了解本机软件开发.如果是这样,我强烈建议你首先选择一个现代的构建系统(CMake将是我的个人推荐),玩它,并学习它.

  • 别客气.我知道在原生编程领域为初学者一次性掌握所有这些内容是多么困难(或者说是不可能),因为周围有很多东西:编译,链接,构建系统,新语言标准,旧语言标准,平台,∞......从一开始就遵循错误的路径是多么容易.不幸的是,很难找到有用的和最新的材料来阅读.唯一的方法是在这里寻求一些指导.祝你未来的事业顺利,无论他们是什么. (2认同)