链接器

# ########################################## # Makefile for simple programs # ########################################## INC= LIB =- lpthread CC = gcc CXX =g++ LINK =g++ # -fpermissive：表示兼容老语法 C_FLAGS= -g -Wall -fpermissive -std= c11 CXX_FLAGS = -g -Wall -fpermissive -std=c++11 INC_PATH = -I ./ -I ./kenlm -I ./kiss_fft130 -I ./iniparser2/ src LIB_PATH =-L ./ EXT_LIB = -Wl,-rpath,./ -ltensorflow -lkenlm -lkenlm_util -lkenlm_builder -lkenlm_filter -lkenlm_interpolate -lbz2 -lz -llzma - pthread PRG = test SRCS =$(wildcard * .c) SRCS +=$(wildcard * .cpp) C_OBJS =$(patsubst %.c,%.o,$(wildcard * .c)

初学Linux C编程遇到编译出错 运行下面编译命令，出错 错误信息: /tmp/ccYw8W8E.o: In function `md5test': /home/rivulet/work/Tinyhttpd-master/httpd.c:666: undefined reference to `MD5_Init' /home/rivulet/work/Tinyhttpd-master/httpd.c:667: undefined reference to `MD5_Update' /home/rivulet/work/Tinyhttpd-master/httpd.c:668: undefined reference to `MD5_Final' collect2: error: ld returned 1 exit status make: *** [httpd] Error 1 一开始以为是库没找到，但是在/user/local/lib下面明明存在libcrypto.so库，后来发现下面命令能编译成功 编译时候，-l所知识的库需要跟在.c文件的后面，表明依赖关系，库与库的之间的依赖关系需要通过顺序定义好，写在前面的库依赖于 写在后边的库 具体解释如下： -l $ gcc -Wall calc.c -lm -o calc (correct order) -lm $ cc

原文: .NET Core 3.0 构建和部署 Default Executables 默认可执行文件 在 dotnet build 或 dotnet publish 期间，将创建一个与你使用的 SDK 的环境和平台相匹配的可执行文件。 和其他本机可执行文件一样，可以使用这些可执行文件执行相同操作，例如： 可以双击可执行文件。 可以直接从命令提示符启用应用程序，如 Windows 上的 myapp.exe ，以及 Linux 和 macOS 上的 ./myapp 。 下面是一个基于 .NET Core 2.2 的项目： 当我 Build 该项目之后，在bin /Debug/netcoreapp2.2 目录下有这些文件： 这里没有 .exe 文件。 下面是一个 .NET Core 3.0 的项目： 当我build项目后，bin /Debug/netcoreapp3.0 目录下有这些文件： 值得注意的就是，这里有一个exe文件，点击它可以直接运行该项目。 而且这个exe文件的大小也很小，这是因为它依赖于 .NET Core 运行时，它所需要的依赖项在我电脑上是全局可用的。 还有另外一个地方也值得注意，项目所有的依赖也都复制到了这个输出的文件夹里。 Single-file Executables 单文件可执行文件 这种部署方式很方便，、。 dotnet publish  

Default Executables 默认可执行文件 在 dotnet build 或 dotnet publish 期间，将创建一个与你使用的 SDK 的环境和平台相匹配的可执行文件。 和其他本机可执行文件一样，可以使用这些可执行文件执行相同操作，例如： 可以双击可执行文件。 可以直接从命令提示符启用应用程序，如 Windows 上的 myapp.exe ，以及 Linux 和 macOS 上的 ./myapp 。 下面是一个基于 .NET Core 2.2 的项目： 当我 Build 该项目之后，在bin /Debug/netcoreapp2.2 目录下有这些文件： 这里没有 .exe 文件。 下面是一个 .NET Core 3.0 的项目： 当我build项目后，bin /Debug/netcoreapp3.0 目录下有这些文件： 值得注意的就是，这里有一个exe文件，点击它可以直接运行该项目。 而且这个exe文件的大小也很小，这是因为它依赖于 .NET Core 运行时，它所需要的依赖项在我电脑上是全局可用的。 还有另外一个地方也值得注意，项目所有的依赖也都复制到了这个输出的文件夹里。 Single-file Executables 单文件可执行文件 这种部署方式很方便，、。 dotnet publish   命令支持将应用打包为特定于平台的单文件可执行文件。  

方法1: 选择项目->属性->预处理器->预处理定义, 增加:HYCOMMONWINAPI_EXPORTS 方法2: 就是在 #ifdef HYCOMMONWINAPI_EXPORTS #define HYCOMMONWINAPI_API __declspec(dllexport) #else #define HYCOMMONWINAPI_API __declspec(dllimport) #endif 前面增加 #define HYCOMMONWINAPI_EXPORTS 其实这两种方法都是增加定义 方法3：在你的dll cpp文件中把 #define HYCOMMONWINAPI_EXPORTS 加在#include <接口文件.h> 的前面 方法4：右击dll工程 -- 属性，打开属性页，展开：配置属性 -- C++ --预处理器，在预处理器定义的最后面填入：_AFXEXT，再次编译则搞掂。 以上方法逐一试下，不知道能不能帮到你。另外这种问题最好去CSDN社区去问比较好，百度上牛X的人比较少，我就经常去CSDN。 非常郁闷的是，这个问题在relaese dll时又会出现，而且，上面的第4种解决方式没有作用，其它的几种方式暂时不甚了解到底怎么操作，因为第3种方法按它的做，出错 ---------------------------------------------------

内核初步   在这节教程, 我们将深入研究一些汇编程序, 学习创建链接脚本的基础知识以及使用它的原因。最后, 我们将学习如何使用batch(批处理)文件自动汇编、编译和链接这个最基本的受保护模式下的内核。本教程假定你已经安装了NASM和GCC, 并且了解一点点x86汇编语言。 内核入口   内核的入口点是当引导程序(bootloader)调用内核时最先执行的代码段。这段代码一直以来几乎都是使用汇编编写的, 因为有些工作如设置新的栈, 加载新的GDT、IDT或寄存器, 你简单地使用C语言根本没法做到。在很多初学者写的内核, 和更专业的内核中, 会将所有汇编程序代码放在一个文件中, 并将其余源代码分别放在几个C文件中。   如果至少知道一点点汇编语言, 那么下面这段汇编代码应该非常简单明了了。就代码而言, 这个文件做的只有加载一个新的8KB栈, 然后跳转到一个死循环中。这个栈是一块很小的内存, 它用于存储或传递参数给C函数。它还可以用来保存你函数中声明和使用的局部变量。其他的全局变量则存储在BSS区域中。在 mboot 和 stublet 代码块之间的代码用于生成特殊的签名, GRUB通过该签名校验即将加载的二进制输出文件, 实际上该文件就是内核。不过不用费力去理解多重引导头(multiboot header)。   内核启动文件 “start.asm” 的内容如下: start

目录 <> vim、gcc、gdb： gcc： gcc和g++是c/c++的linux系统集成的编译器，源文件的后缀应为 .C/.cpp/.c++/.cc等 编译器可以将C、C++等语言源程序、汇编程序编译、链接成可执行程序。 gdb： 是 GNU 开发的一个Unix/Linux下强大的程序调试工具。 gcc 基本格式：gcc [options] file1 file2... //若不加入参数，则按默认参数依次执行编译、汇编和链接操作，生成的可执行文件名为 a.out 常用参数：-E //只执行预处理操作 　　　　　-S //只执行到编译操作完成，不进行汇编操作，生成的是汇编文件(.s 或 .asm),内容为汇编语言 　　　　　-c //执行编译和汇编，但不进行链接，即只生成可重定位目标文件(.o),为二进制文件，不生成完整的可执行文件 　　　　　-o filename //将操作后的内容输出到filename指定的文件中 　　　　　-static //对于支持动态链接的系统，使用静态链接而不是动态链接进行链接操作 　　　　　-g　　　　　　　　　 //编译时生成debug有关的程序信息(供gdb使用) 　　　　　--save-temps //生成编译过程的中间结果文件(包括预处理文件(x.ii)、汇编代码(x.s)、目标文件(x.o)和最终的可执行文件) 　　　　　-I PATH

在应用程序需要连接外部库的情况下，linux默认对库的连接是使用动态库，在找不到动态库的情况下再选择静态库。使用方式为： gcc test.cpp -L. -ltestlib 如果当前目录有两个库libtestlib.so libtestlib.a 则肯定是连接libtestlib.so。如果要指定为连接静态库则使用： gcc test.cpp -L. -static -ltestlib 使用静态库进行连接。 当对动态库与静态库混合连接的时候，使用-static会导致所有的库都使用静态连接的方式。这时需要作用-Wl的方式： gcc test.cpp -L. -Wl,-Bstatic -ltestlib -Wl,-Bdynamic -ltestdll 另外还要注意系统的运行库使用动态连接的方式，所以当动态库在静态库前面连接时，必须在命令行最后使用动态连接的命令才能正常连接 ，如： gcc test.cpp -L. -Wl,-Bdynamic -ltestdll -Wl,-Bstatic -ltestlib -Wl,-Bdynamic 最后的-Wl,-Bdynamic表示将缺省库链接模式恢复成动态链接。 其中用到的两个选项：-Wl,-Bstatic和-Wl,-Bdynamic。这两个选项是gcc的特殊选项，它会将选项的参数传递给链接器，作为链接器的选项。比如-Wl,

本文简单介绍了程序的链接原理。学习链接原理有助于程序员理解程序的本质，同时也可以为日后的大型软件的代码开发打下坚实的基础。由此可知链接原理的重要性，尤其是一些程序员被一些莫名其妙的错误困扰的时候，更加能够体会到这一点。 1 连接器的任务 连接器将多个目标文件链接成一个完整的、可加载、可执行的目标文件。其输入是一组可重定位的目标文件。链接的两个主要任务如下： (1) 符号解析，将目标文件内的引用符号和该符号的定义联系起来。 (2) 将符号定义与存储器的位置联系起来，修改对这些符号的引用。 2 目标文件 典型的目标文件分为以下3种形式： (1) 可重定位目标文件 这种文件包含二进制代码和数据，这些代码和数据已经转换成了机器指令代码和数据，但是还不可以直接执行。因为这些指令和数据中往往引用其他模块(目标文件)中的符号，这些其他模块的符号对于本模块来说是未知的，这些符号的解析需要链接器将所有模块进行链接。这种操作称为“重定位”，因此，这种目标文件被称为“可重定位的目标文件”，后缀名通常为*.o (2) 可执行目标文件 这种文件同样包含了二进制代码和数据。所不同的是，这种文件已经经过了链接操作，和所有的模块(目标文件)都产生了联系。链接器将所有需要的可重定位目标文件连接成一个可执行目标文件。这时，每个目标文件中引用其他目标文件中的符号都已经得到了解析和重定位。因此，每个符号都是已知的了

为什么会出现LNK2005 许多Visual C++的使用者都碰到过LNK2005:symbol already defined和LNK1169:one or more multiply defined symbols found这样的链接错误，而且通常是在使用第三方库时遇到的。对于这个问题，有的朋友可能不知其然，而有的朋友可能知其然却不知其所以然，那么本文就试图为大家彻底解开关于它的种种疑惑。 大家都知道，从C/C++源程序到可执行文件要经历两个阶段:(1)编译器将源文件编译成汇编代码，然后由汇编器(assembler)翻译成机器指令(再加上其它相关信息)后输出到一个个目标文件(object file,VC的编译器编译出的目标文件默认的后缀名是.obj)中；(2)链接器(linker)将一个个的目标文件(或许还会有若干程序库)链接在一起生成一个完整的可执行文件。 编译器编译源文件时会把源文件的全局符号(global symbol)分成强(strong)和弱(weak)两类传给汇编器，而随后汇编器则将强弱信息编码并保存在目标文件的符号表中。那么何谓强弱呢？编译器认为函数与初始化了的全局变量都是强符号，而未初始化的全局变量则成了弱符号。比如有这么个源文件: extern int errorno; int buf[2] = {1,2}; int *p; int main() {