问题标签 [object-files]

基本上，我曾经objdump -D反汇编一个目标文件和一个 ELF 文件。我看到两者之间的主要区别是。

我看到（各个段的）目标文件中的指令有一个以0开头的地址。因此， 的连续地址偏移某个值，可能取决于对应于该特定指令的操作码的长度。

另一方面，对于 ELF 罚款，我看到指令的32 位地址空间main。另外，如果我在我的程序中打印地址。相当于我反汇编的ELF中的地址。

这里的问题是。

• ELF 文件中的地址实际上指的是什么？
• 链接器如何计算它们？

我有一个游戏，有两个单独的项目，用于应用程序本身和测试。我正在源代码中构建所有项目。这是我的项目结构的缩短版本：

应用程序专业版：

我的问题是所有tests项目都使用项目中的类app，这意味着它们正在编译所有这些类，即使它们在app构建时已经被编译。以layer测试项目为例：

层.pro：

那么如何将 qmake 指向已经生成的.o（和qrc_等）文件？为此目的是否有一些 qmake 变量，或者我的项目结构是否存在根本缺陷？.mocapp

我目前正在处理从一些 C 源文件生成的 ELF 格式的目标文件（我没有，只有目标文件可用）。当我编写一个提取所有未定义符号的小工具时，我遇到了一些具有指向保留部分的部分索引的符号：

详细地：

ELF 文件中的每个symbol条目Symbol Table都有一个带有整数的字段，指向符号section header entry index所属的范围。关于后一种，ELF 规范只有很少的信息，说明这些部分0undefined symbols0xFF00 - 0xFFFF

保留用于特定于处理器的语义。

我的问题是：

哪个代码会导致一个符号的节头表索引指向这样一个reserved section？如果它不是来自源代码本身，而是来自编译器或其他东西，请解释:)

提前致谢！

当我们编译代码时，会生成一个目标文件。从该目标文件，在链接过程中生成一个可执行文件。

为什么我们需要一个目标文件？目标文件有什么用？不能直接生成可执行文件吗？毕竟，我们使用的是可执行文件来运行程序。

我由 GHC 编译的程序崩溃*，并gdb显示调用函数的名称为s10kL_info. s10kL_info是否可以通过让 GHC 将调试符号写入目标文件来显示人类可读的函数名称，或者至少是上述函数的人类可读的名称？

_{*（我的崩溃可能是使用了外部库或者不安全的IO函数造成的）}

我正在尝试创建一个 .lib 库文件，其中包含调用 c++ 函数的 Fortran 函数，但我得到了可怕的“错误 LNK2019：未解析的外部符号...”。代码最终将与一堆其他库一起编译为 DLL，并在单独的程序 (PSSE) 中使用。当 PSSE 尝试使用我的库创建 DLL 时，我收到编译错误。这是我尝试使用的代码，然后是编译代码。代码应该只是将两个数字相加并输出答案。

fort_code.f

cpp_code.cpp

编译.bat

当 PSSE 程序尝试创建 DLL 时，这是我得到的输出：

conec/conet 只是对外部库函数的 Fortran 调用：

我见过几个从 Fortran 调用 c++ 函数的不同示例，但它们看起来都略有不同。我注意到的一件事是_c++ 函数名称之前或之后的不同用途。我怎么知道要使用哪个：_CPPFUNCTION、CPPFUNCTION或CPPFUNCTION_. 我需要使用 C++ 导出函数__declspec( dllexport )吗？我需要ALIAS:'_CPPFUNCTION'在 Fortran 代码中创建一个吗？

我正在使用以下编译器：ifort：IVF IA-32 v12.1.0.233 cl：v16.00.30319.01 x86

我是否缺少将 c++ 代码正确链接到 Fortran 函数的内容？

我正在编写 mex 代码和 cuda 代码。我想知道每个代码有两个目标文件并从 mex 文件中调用 cuda 内核，因为我通过组合它们的目标文件来获得可执行文件。因此我需要知道（如果可能的话）我如何从另一个目标文件中调用一个目标文件的函数。它是否可以使用单独的编译器编译 mex 和 cuda 并以这种方式组合它们？

我对使用库很陌生，并且正在尝试了解有关静态库和目标文件的一些细节。

概括

我注意到的行为是我可以链接多个对象以毫无问题地生成可执行文件，但如果我采取将这些对象组合到静态库中的中间步骤，我无法在不额外指定的情况下链接这些静态库以生成可执行文件链接命令中需要 C 运行时库。

另外，或者记录，我正在从命令行使用 Visual Studio 2010 进行编译/链接。我正在遵循的过程的更多详细信息如下。

首先，假设我在一个项目中有四个源文件：main.c、util1.c、util2.c和util3.c.

什么有效

1. 我可以使用以下命令编译这些源
   
   cl -c main.c util1.c util2.c util3.c
   
   文件： 结果，我现在有四个目标文件：main.obj、util1.obj、util2.obj和util3.obj. 这些目标文件中的每一个都包含一个 DEFAULTLIB 语句，旨在通知链接器在链接这些目标文件时，它应该另外检查静态 C 运行时库 libcmt.lib 中是否存在任何未解决的外部依赖项。

2. 我可以通过使用以下命令链接这些对象来创建一个名为“app_objs.exe”的可执行文件：
   
   link -out:app_objs.exe main.obj util1.obj util2.obj util3.obj
   
   如步骤 1 中所述，由于编译器向对象添加默认库语句的步骤，链接器使用了运行时库。
   
   

我困惑的地方

1. 假设我想要一个将这些对象组合到静态库中的中间步骤，然后链接这些生成的 LIB 文件以创建我的可执行文件。首先，我可以使用以下命令创建这些库：
   
   link -lib -out:main.lib main.obj
link -lib -out:util.lib util1.obj util2.obj util3.obj

2. 现在，我最初的想法是，我可以简单地链接这些库并拥有我在“什么有效”的第 2 步中创建的相同可执行文件。我尝试了以下命令并收到链接器错误 LNK1561，它指出需要指定入口点：
   
   link -out:app_libs.exe main.lib util.lib

3. 从 Microsoft 的文档中，很明显，链接没有任何目标文件的库可能需要指定入口点，因此我修改了命令以将子系统设置为“控制台”以指定可执行文件旨在成为控制台应用程序（这似乎暗示某些入口点，从而解决该错误）：
   
   link -out:app_libs.exe -subsystem:console main.lib util.lib
   
   不幸的是，现在我收到一个链接器错误，指出 mainCRTStartup 是一个未解析的外部符号。我知道这是在 C 运行时库中定义的，因此我可以通过手动指定要链接到 libcmt.lib 来解决此问题，这为我提供了一个正常运行的可执行文件：
   
   link -out:app_libs.exe -subsystem:console main.lib util.lib libcmt.lib
   
   

我不明白的是为什么编译器放置在每个目标文件中的默认库信息不能用于解决对 libcmt.lib 的依赖关系。如果我可以在不明确声明我想要 libcmt.lib 的情况下链接目标文件，并且我创建了作为目标文件容器的静态库，为什么我不能在不明确声明我想要 libcmt.lib 的情况下链接这些静态库？事情就是这样，还是有什么方法可以创建静态库，以便链接器知道在运行时库中检查未解析的符号？

谢谢你的帮助。如果我在这里有一些根本不正确的想法，我会喜欢关于好的参考的建议，以正确学习所有这些。

我希望能够在不使用 makefile 的情况下编译 c++ 源文件。这是我的问题的原型......我有以下.cpp文件

在同一个目录中，我有以下makefile，可以让我.cpp成功编译文件

现在，出于我的目的，我想从.cpp文件目录中删除这个 makefile。同时，我希望能够编译.cpp文件...

知道 makefile 引用的目标文件和库将位于它们各自的目录中......

所以，我想做的就是在.cpp没有makefile的情况下编译文件。

是否可以为给定的情况做这样的事情？...如果是，您的建议非常感谢！

在 C++ 中，当您将目标文件归档为 .a 文件时，平台是否重要？

例如，我在使用 x64 编译器编译的 x64 平台上，我将一堆 CPP 文件编译成 .o 文件。使用 AR.exe，我将它们归档到 .a 文件中并分发。

.a 文件是 x32、x64 还是可互换的？或者它是否取决于使用 .a 文件的程序？