[ld-linux-x86-64.so.2] 最近在Linux 环境下开发,搞了好几天 Compiler 和 linker,觉得有必要来写一篇关于Linux环境下 ld.so的文章了,google上搜索了很多相关介绍性的文档,发现国内百度上却很少有相关类文档,觉得有必要来梳理一下: ld-linux.so.2 是linux下的动态库加载器/链接器,这篇文章主要来讲一下 ld-linux.so.2 是如何和Linux 以及相关应用打交道的. 1. 什么是 ld.linux.so ? 很多现代应用都

  在近一段时间里,由于多次参与相关专业软件Linux运行环境建设,深感有必要将这些知识理一理,供往后参考. 编译时和运行时 纵观程序编译整个过程,细分可分为编译(Compiling,指的是语言到平台相关目标文件这一层次)和链接(Linking,指目标文件到最终形成可执行文件这一层次),这个总的过程可称为编译时:就动态链接而言,还存在一个运行时,即程序在被操作系统加载的过程中,系统将该程序需要的动态库加载至内存到程序开始运行的这一段过程.明确这两个过程在一般linux开发中的地位,以及了解每个“

原文网址:http://tsecer.blog.163.com/blog/static/15018172012414105551345/ 一.动态链接工具ldd和ldconfig是动态链接的两个重要辅助工具,所谓“辅助”,是相对于真正的主角动态链接器ld.so,说它是工具,是只它相对于配置文件/etc/ld.so.conf文件.ldd不直接参与链接过程,它依赖于ld.so,但是ld.so不依赖于这个工具,事实上,ldd只是一个脚本,它在调用ld.so的时候传递了一些约定好的环境变量,从而使ld.

  在近一段时间里,由于多次参与相关专业软件Linux运行环境建设,深感有必要将这些知识理一理,供往后参考. 编译时和运行时 纵观程序编译整个过程,细分可分为编译(Compiling,指的是语言到平台相关目标文件这一层次)和链接(Linking,指目标文件到最终形成可执行文件这一层次),这个总的过程可称为编译时:就动态链接而言,还存在一个运行时,即程序在被操作系统加载的过程中,系统将该程序需要的动态库加载至内存到程序开始运行的这一段过程.明确这两个过程在一般linux开发中的地位,以及了解每个“

概述 动态链接器可以被正在运行的动态链接程序或者动态对象(没有对动态链接器指定命令选项,动态链接器被存储在程序的.interp区域)间接调用,也可以直接运行程序, 例如:/lib/ld-linux.so.*  [OPTIONS] [PROGRAM [ARGUMENTS]] 描述 ld.so和ld-linux.so*查找并且装载其他程序所依赖的动态链接对象,当装载完毕之后,就开始运行程序 Linux二进制运行程序要求动态链接(在运行时链接)除非在汇编期间指定-static选项 转载地址:https

转载于:http://www.cnblogs.com/xingyun/archive/2011/12/10/2283149.html   我们知道函数名就是一个内存地址,这个地址指向函数的入口.调用函数就是压入参数,保存返回地址,然后跳转到函数名指向的代码.问题是,如果函数在共享库中,共享库加载的地址本身就不确定,函数地址也就不确定了,那如何调用共享库中的函数呢?这就是本文要回答的. 我们先来看一小段代码(test.c): #include <stdio.h>void hello_world(

进程与 API 动态链接的共享库是 GNU/Linux® 的一个重要方面.该种库允许可执行文件在运行时动态访问外部函数,从而(通过在需要时才会引入函数的方式)减少它们对内存的总体占用.本文研究了创建和使用静态库的过程,详细描述了开发它们的各种工具,并揭秘了这些库的工作方式. 0 评论: M. Tim Jones, 顾问工程师, Emulex Corp. 2008 年 9 月 08 日 内容 库用于将相似函数打包在一个单元中.然后这些单元就可为其他开发人员所共享,并因此有了模块化编程这种说法 —

转自:Chapter 9. Dynamic Linking 参考:Linux动态链接器 Linux加载启动可执行程序的过程(一)内核空间加载ELF的过程 Linux加载启动可执行程序的过程(二)解释器完成动态链接 本文和 理解ld-linux.so.2 内容上有点重复 动态链接器——Dynamic Linker 动态链接器既可以直接运行,也可以间接运行 间接运行 动态链接器可以通过一些动态链接的程序(dynamically linked program) 或 共享对象(shared object

符号重定位 讲动态链接之前,得先说说符号重定位. c/c++ 程序的编译是以文件为单位进行的,因此每个 c/cpp 文件也叫作一个编译单元(translation unit), 源文件先是被编译成一个个目标文件, 再由链接器把这些目标文件组合成一个可执行文件或库,链接的过程,其核心工作是解决模块间各种符号(变量,函数)相互引用的问题,对符号的引用本质是对其在内存中具体地址的引用,因此确定符号地址是编译,链接,加载过程中一项不可缺少的工作,这就是所谓的符号重定位.本质上来说,符号重定位要解决的是当

1.   序 最近在折腾各种.so,碰到了一些问题,一开始对于很多错误也没有头绪,茫然不知所措.索性化了一天多时间将<<程序员的自我修养—链接.装载与库>>中部分内容略读了一遍,主要是关于编译,链接和加载这块的.于是顺便做个笔记,方便以后回顾.基本上知道了这些,对于编译,链接和加载过程中产生的各种问题,应该就能从根本上理解并解决了.其实以前上学时也看过那本经典的<<Linker and loader>>,当时还写了篇<<链接器和加载器原理>

摘自http://blog.csdn.net/zzxian/article/details/16820035 C编译器.链接器.加载器详解 一.概述 C语言的编译链接过程要把我们编写的一个c程序(源代码)转换成可以在硬件上运行的程序(可执行代码),需要进行编译和链接.编译就是把文本形式源代码翻译为机器语言形式的目标文件的过程.链接是把目标文件.操作系统的启动代码和用到的库文件进行组织形成最终生成可加载.可执行代码的过程. 过程图解如下: 预处理器:将.c 文件转化成 .i文件,使用的gcc命令是

9.1 DLL简介 DLL即动态链接库的缩写,它相对于Linux下的共享对象. Windows下的DLL文件和EXE文件实际上是一个概念,它们都是有PE格式的二进制文件. 微软希望通过DLL机制加强软件的模块化设计,使得各种模块之间能够松散地组合.重用和升级. 9.1.1 进程地址空间和内存管理 一个DLL在不同进程中拥有不同的使用数据副本.在ELF中,由于代码段是地址无关的,所以它可以实现多个进程之间共享一份代码,但是DLL的代码却并不是地址无关的,所以它只是在某些情况下可以被多个进程间共享.

关于ELF文件的详细介绍,推荐阅读: ELF文件格式分析 —— 滕启明.ELF文件由ELF头部.程序头部表.节区头部表以及节区4部分组成. 通过objdump工具和readelf工具,可以观察ELF文件详细信息. ELF文件加载过程分析 从编译.链接和运行的角度,应用程序和库程序的链接有两种方式.一种是静态链接,库程序的二进制代码链接进应用程序的映像中:一种是动态链接,库函数的代码不放入应用程序映像,而是在启动时,将库程序的映像加载到应用程序进程空间. 在动态链接中,GNU将动态链接ELF文件的

http://www.mamicode.com/info-detail-2358309.html   .netcore下已经实现了通过p/invoke方式调用linux的动态链接库(*.so)文件 1 [DllImport(@"libdl.so.2")] 2 public static extern IntPtr dlopen(string filename, int flags); 3 [DllImport("libdl.so.2")] 4 public stat

动态链接,在可执行文件装载时或运行时,由操作系统的装载程序加载库.大多数操作系统将解析外部引用(比如库)作为加载过程的一部分.在这些系统上,可执行文件包含一个叫做import   directory的表,该表的每一项包含一个库的名字.根据表中记录的名字,装载程序在硬盘上搜索需要的库,然后将其加载到内存中预先不确定的位置,之后根据加载库后确定的库的地址更新可执行程序.可执行程序根据更新后的库信息调用库中的函数或引用库中的数据.这种类型的动态加载成为装载时加载   ,被包括Windows和Linux

说道“动态库版本兼容”,很多人头脑中首先蹦出的就是“Dll Hell”.啊,这曾经让人头疼的难题.时至今日,这个难题已经很好地解决了. 在进一步讨论之前来思考一个问题:Linux下为什么没有让人头痛的“DllHell”?回答这个问题,非常easy,因为——Linux下根本没有dll! 哈哈,当然这只是个玩笑,接下来展开一下这个话题,很多有动态库的系统都会面临这个难题,但各自解决的思路却各不相同. Dll hell是指windows 上动态库新版本覆盖旧版本,但是却不兼容老版本.常常发生在程序升级

4. 共享库 4.1. 编译.链接.运行 组成共享库的目标文件和一般的目标文件有所不同,在编译时要加-fPIC选项,例如: $ gcc -c -fPIC stack/stack.c stack/push.c stack/pop.c stack/is_empty.c -f后面跟一些编译选项,PIC是其中一种,表示生成位置无关代码(Position Independent Code).那么用-fPIC生成的目标文件和一般的目标文件有什么不同呢?下面分析这个问题. 我们知道一般的目标文件称为Reloc

➠更多技术干货请戳:听云博客 动态链接 要解决空间浪费和更新困难这两个问题最简单的方法就是把程序的模块相互分割开来,形成独立的文件,而不再将它们静态的链接在一起.简单地讲,就是不对那些组成程序的目标文件进行链接,等到程序要运行时才进行链接.也就是说,把链接过程推迟到了运行时再进行,这就是 _动态链接(Dynamic Linking)_的思想. 延迟绑定(PLT) 动态链接比静态链接性能低,主要原因是动态链接下对于全局和静态的数据访问都要进行复杂的GOT定位,间接寻址:对于模块间的调用也要先定位G

1 平台 转http://blog.csdn.net/misskissc/article/details/43063419 1.1 硬件 Table 1. 硬件(lscpu) Architecture: i686(Intel 80386) Byte Order: Little Endian 1.2 操作系统 Table 2. 操作系统类型 操作系统(cat /proc/version) 位数(uname -a) Linux version 3.2.0-4-686-pae i686(32bit)

参考文献: <ELF V1.2> <程序员的自我修养---链接.装载与库>第6章 可执行文件的装载与进程 第7章 动态链接 <Linux GOT与PLT> 开发平台: [root@tanghuimin dynamic_link]# uname -a Linux tanghuimin -.el6.x86_64 # SMP Fri Feb :: UTC x86_64 x86_64 x86_64 GNU/Linux 实例讲解之前先来一段理论铺垫,文字很繁琐但很必要事先了解.

摘自http://gotowqj.iteye.com/blog/1926613 对动态库的实际应用还不太熟悉的读者可能曾经遇到过类似“error while loading shared libraries”这样的错误,这是典型的因为需要的动态库不在动态链接器ld.so的搜索路径设置当中导致的.         具体说来,动态链接器ld.so按照下面的顺序来搜索需要的动态共享库: 1．ELF可执行文件中动态段中DT_RPATH所指定的路径.这实际上是通过一种不算很常用,却比较实用的方法所设置的: