objdump查看库的编译环境

㈠ ubuntu中怎么查看文件是gcc编译出来的还是arm-linux-gcc编译的

使用objmp试试吧
如果是ubuntu下得gcc编译出来的话，应该带有i386字样

具体方法（假设要看a.out）
objmp -a a.out
我的输出为：
a.out: file format elf32-i386
如果是跨平台的话，比如我这边 mips编译出来的 用objmp看到的就是 file format elf32-little

如果通过这个-a参数还区别不出来 可以试试其他的。比如 -d 反编译看下

㈡ 如何利用android studio 编译c code

学习 android 逆向分析过程中，需要学习 Arm 指令，不可避免要编写一些 test code 并分析其指令，这是这篇文档的背景。

在目前 android 提供的开发环境里，如果要编写 c / cpp code， 一般是通过 ndk 开发套件，基本方法就是在
windows 或 linux 发行版上下载 ndk 环境，然后编写 c / cpp code 然后编写 Android.mk 文件，最后用
ndk-build 等工具进行编译，编译出来的可执行文件再通过 adb push 的方式提交到 devices 或 emulator
运行，如果要分析其指令，需要下载 android 提供的 prebuilts binutils 工具集（如android 源码的
prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.7/arm-linux-androideabi/bin/
目录），如果你在linux上用file命令查看一下这些工具，会发现 ：

root@ubuntu:bin# file objmp
objmp: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, stripped

它们是x86架构的，这样，你要分析devices或emulator里的elf文件，需要adb pull 下来，放在本地的linux环境或者windows里，用上述prebuilt工具分析。

稍微思考一下就会发现上述 ndk
的方式，对我们的需求来说有点太复杂了，我们真正希望的是像在标准linux发行版上那样，可以用vi/vim等编辑工具写 c/cpp
code,然后用 gcc /g++ 等编译工具编译，然后能直接运行或者用gdb调试，
或者用readelf/objmp等命令查看elf结果和汇编码。问题变成了：如何在android上实现这一切？

下面的方式是经过本人收集和实际测试证明可行的，我的环境是：

目标机：小米2手机， android4.4.4, miui 6.3.5

本地机： win7

效果：在本地机adb目标机的shell, 然后用vi写 c/cpp code, 直接在shell上用gcc编译，用objmp分析指令

实现步骤如下：

1. 首先安装 busybox apk . 这个app提供了后续需要的 busy vi, busy tar 等工具

2. 下载 adb putty ,http://yunpan.cn/cZ5x9UrDFUDdK （提取码：e70e）

这个工具用来做终端，这里为什么不用win7自带的cmd或者其他增强版如 powerCmd 呢？ 因为用 windows 的 cmd 终端，adb shell 连接上手机后，执行 busybox vi 等命令，会出现乱码，参考http://www.hu.com/question/20624475， 用这款 adb putty 终端则可以正常使用。

3. 下载 gcc arm,http://yunpan.cn/cZ5YVZzbvJqq4 （提取码：80b8）

㈢ 怎么查看linux库是使用哪个版本的编译器编

如果是你自己编译的 那么gcc -v 查看本机版本号。

如果是你拿到的别人的，可以

objmp-s--section=.commentyour_program

查看程序编译器版本

㈣ 如何解决源码包安装时的依赖性问题

动态可执行文件使用最初编译和链接程序时使用的库文件的共享对象名称来查找共享对象。它们在少数的几个标准位置查找，比如在/lib和/usr/lib目录及在LD_LIBRARY_PATH环境变量（主要用于指定查找共享库，比如我们在安装Oracle时指定路径，exportLD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib:/usr/local/lib）指定的目录中。顺便提一下，在这些库目录中找到的共享对象可能不是真正的文件;它们可能是指向位于其他位置的真实库文件的符号链接（但通常仍旧在标准库目录的一个目录中）。至少从系统管理员的观点是在用于创建共享库文件的共享库软件包的名称和共享库文件的名称之间通常没有什么关系。例如，GLIBC2.3软件包用于创建libc.so.6共享库文件。也从本示例中注意到，添加到共享库文件名结束的版本号(.6)跟用于创建它的版本号(2.3)没有关系。这是由共享库软件包开发人员有意完成的，以便GLIBC的新版本可以重用相同的共享库文件名libc.so.6。这允许您在系统上加载新版本的GLIBC，而不用中断动态链接到lib.so.6共享库文件的所有程序，当然假定新版本的GLIBC向后与动态可执行文件最初所链接的老版本GLIBC兼容。因此，即使库文件或共享对象文件有与它们相关的版本号，这些版本号也不能帮助你确定他们来自哪个版本的共享软件包。
注意：当将whatprovides选项用于rpm查询命令时，可以获得有关使用rpm软件包加载到系统的现有共享对象的信息。这种混乱是由下面的事实造成的：单个共享库文件可能支持某个范围的共享库软件包版本。例如，要检查soname库文件/lib/libc.so.6支持的GLIBC共享库软件包，运行下面的命令：
#objmp--all-headers/lib/libc.so.6|less
向下滚动此报告，直到到达Versiondefinitions:部分，以便查看libc.so.6共享库文件支持哪些GLIBC版本：
Versiondefinitions:
10x010x0865f4e6libc.so.6
20x000x0d696910GLIBC_2.0
30x000x0d696911GLIBC_2.1
GLIBC_2.0
40x000x09691f71GLIBC_2.1.1
GLIBC_2.1
50x000x09691f72GLIBC_2.1.2
GLIBC_2.1.1
60x000x09691f73GLIBC_2.1.3
GLIBC_2.1.2
70x000x0d696912GLIBC_2.2
GLIBC_2.1.3
80x000x09691a71GLIBC_2.2.1
GLIBC_2.2
90x000x09691a72GLIBC_2.2.2
GLIBC_2.2.1
100x000x09691a73GLIBC_2.2.3
GLIBC_2.2.2
110x000x09691a74GLIBC_2.2.4
GLIBC_2.2.3
120x000x09691a76GLIBC_2.2.6
GLIBC_2.2.4
130x000x0d696913GLIBC_2.3
GLIBC_2.2.6
140x000x09691972GLIBC_2.3.2
GLIBC_2.3
150x000x09691973GLIBC_2.3.3
GLIBC_2.3.2
160x000x09691974GLIBC_2.3.4
GLIBC_2.3.3
170x000x0d696914GLIBC_2.4
GLIBC_2.3.4
180x000x0d696915GLIBC_2.5
GLIBC_2.4
190x000x0963cf85GLIBC_PRIVATE
GLIBC_2.5
200x000x0b792650GCC_3.0
在本示例中，1ibc.so.6共享库文件支持原先为GLIBC版本2.0到2.5而开发的所有动态执行文件。注意：也可以使用objmp命令来从共享库文件中提取soname，命令如下所示：
#objmp--all-headers/lib/libcrypto.so.0.9.8b|grepSONAME
SONAMElibcrypto.so.6
objmp:/lib/libcrypto.so.0.9.8b:
接下来，将讨论rpm软件包是如何生成的，以便在新系统上安装rpm软件包时，这些共库依赖性是己知的。
三、Rpm软件包和共享库依赖性
当程序员生成rpm软件包时，ldd命令用于报告动态可执行文件软件包中所有动态可执行文件使用的所有共享库。另一个混乱是由下面的事实带来的：相同软件包中的不同动态可执行文件可能与相同的共享库软件包的不同版本进行链接。例如，Heartbeat软件包中的不同程序可能已经进行了开发，并动态链接到libc.so.6sonmae共享库文件的不同GLIBC版本。对rpm命令使用-q和--requires参数，可以看到rpm软件包需要的共享库的完整清单。例如，要看到Heartbeatrpm软件包所有的所需依赖性，请使用命令：
#rpm-q--requires-pheartbeat-1.x.x.i386.rpm
这产生了下面的报告：
sysklogd
/bin/sh
/bin/sh
/usr/bin/python
ld-linux.so.2
libapphb.so.0
libc.so.6
libc.so.6(GLIBC_2.0)
libc.so.6(GLIBC_2.1)
libc.so.6(GLIBC_2.1.3)
libc.so.6(GLIBC_2.2)
libc.so.6(GLIBC_2.3)
libccmclient.so.0
libdl.so.2
libglib-1.2.so.0
libhbclient.so.0
libpils.so.0
libplumb.so.0
libpthread.so.0
librt.so.1
libstonith.so.0
注意，在此报告中，libc.so.6soname是所需要的，此共享库必须支持使用GLIBC共享软件包版本号2.0、2.1、2.1.3、2.2和2.3进行链接的动态可执行文件。这是由下面的事实决定的：Heartbeat软件包中的不同动态可执行文件是针对不同版本的libc.so.6库的每个版本进行链接的。在了解了动态可执行文件、共享对象、soname和共享库软件包彼此是如何相关的后，下面准备来看这样的一个例子：当尝试安装rpm软件包，并且它由于依赖性错误而失败时，会发生什么。yum能够从指定的服务器自动下载RPM包并且安装，可以自动处理依赖性关系，并且一次安装所有依赖的软体包，无须繁琐地一次次下载、安装。
四、手工解决依赖性问题
通常，当尝试安装发行版中没有包括的软件包（及不能由像up2date、apt-get或Yum一样的更新工具自动解决其依赖性的软件包）时，将碰到rpm依赖性错误。例如，如果尝试在老的Linux发行版上使用rpm–ivh*rpm命令，例如所有的Heartbeatrpm包，那么在安装过程中就可能碰到下面的错误：
error:faileddependencies:
libc.so.6(GLIBC_2.3)isneededbyheartbeat-1.x.x
libc.so.6(GLIBC_2.3)isneededbyheartbeat-pils-1.x.x
libcrypto.so.0.9.6isneededbyheartbeat-stonith-1.x.x
libsnmp-0.4.2.6.soisneededbyheartbeat-stonith-1.x.x
注意，rpm命令没有干扰报告所需的每个GLIBC共享库软件包版本号——它只报告所需的最高编号的版本号(GLIBC_2.3)。(假定原来的软件包开发人员不会将相同软件包中的可执行文件链接到不兼容版本的共享库软件包)所有的这些故障都报告所需的共享库名称或soname（而不是文件名称，soname始终以“lib”开始）。但可以删除添加到rpm报告的soname结束的版本号，并快速检查以查看是否在系统中使用locate命令安装这些共享库(假设您的locate数据库是最新的，有关更多信息，请参阅locate或slocate的手册页)。例如，

㈤ 使用objmp查看动态库和静态库中具有哪些

objmp 是 gcc 套件中用来查看 ELF 文件的工具，具体详细用法不进行介绍，此处只讲解如何进行一个动态库和静态库中导出函数的查看。

1). 查看依赖项：objmp -x xxx.so | grep "NEEDED" 。下面是我查看 libsf_modbus_preproce.so 时的输出截图：

㈥ 你好，我现在用qt中要使用了一个vs2010编译的.lib静态库。

对于C语言而言，用于连接dll的连接lib是可以通用的，dll也是可以通用的。但是静态库目前而言并不是通用的，一般的处理方式是编译成dll，然后生成连接lib(a)库，引入项目，或者使用libtdl动态加载dll文件。
静态库不可通用的原因是，基础库相差太多，objmp甚至都无法识别使用vc默认选项编译出啦的obj文件格式。另外reimp不是用于这个用途的，是为dll的连接lib(a)文件提供转换的。

对于C++而言，所有二进制代码都是不可通用的，毕竟名称修饰都相差甚远。

㈦ 查看c可执行程序依赖哪些库的函数 objmp

第一步，我先从简单的调用出发，定义了一个简单的函数，该函数仅仅实现一个整数加法求和： LIBEXPORT_API int mySum(int a,int b){ return a+b;} C# 导入定义： public class RefComm { [DllImport("LibEncrypt.dll", EntryPoint=" mySum ", Cha...

㈧ 使用objmp查看动态库和静态库中具有哪些函数

可以使用file命令, 比较全(加 -l)。 file libname.so 也可以使用objmp, 这个可以看到多少位的库 objmp -a libname.so

㈨ linux下，怎么使用命令查看编译好的程序信息比如想知道程序加载到什么地址之类的信息

每个当前激活的进程都会在/proc目录下有个文件夹，名称是PID号
所有你能看到的信息都在里面
变量能看到它们的逻辑地址，在maps文件里面有，真实的物理地址就是CR3+逻辑地址

㈩ 怎么查看linux库是使用哪个版本的编译器编译的

gcc -v 很简答的一个知识。 所有的linux程序都可以使用这个命令查看版本信息。 以后要是遇到了linux方面的问题， shell编程， linux系统管理问题， 都可以帮到大家。 希望~~