交叉编译so文件找不到

❶ linux下用交叉编译器编译时，已经指定了库的路径跟库的名字，可是还是报错找不到库。

看起来它不是个库，倒像是个可执行程序
一般so都放在lib这样的目录下，你这个是bin，而且和它在一起的都是可执行程序，并且它没有so后缀名。

❷ 交叉编译busybox显示libc.so.6丢失！

拷贝C 库
交叉应用程序的开发需要用到交叉编译的链接库，我们在移植应用程序到我们的目标板的时
候，需要把交叉编译的链接库也一起移植到目标板上，这里我们用到的交叉工具链的路径是
/usr/local/arm/...../,链接库的目录是/usr/local/arm/...../arm-linux/lib，将其中部分库文件及符号链接拷贝到root_nfs(你创建的busybox的根目录）文件夹下的lib文件夹中。
部分库文件及符号链接有：ld-2.3.2.so,ld-linux.so.2,libc-2.3.2.so,libc.so.6

❸ gcc交叉编译怎么找头文件及lib库的

是在specs里面读取的路径信息。
命令行中键入 gcc -v
Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs
Configured with: /usr/build/package/orig/test.respin/gcc-3.4.4-3/configure --ver
bose --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libe
xecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-langu
ages=c,ada,c++,d,f77,pascal,java,objc --enable-nls --without-included-gettext --
enable-version-specific-runtime-libs --without-x --enable-libgcj --disable-java-
awt --with-system-zlib --enable-interpreter --disable-libgcj-debug --enable-thre
ads=posix --enable-java-gc=boehm --disable-win32-registry --enable-sjlj-exceptio
ns --enable-hash-synchronization --enable-libstdcxx-debug
Thread model: posix
gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)

注意“--prefix=/usr” 以及“--libdir=/usr/lib ”
表示gcc ld as 等可执行文件安装在/usr/bin,而libc.a 等文件是在/usr/lib中。
解压缩交叉编译器时，也是要解压缩在在--prefix 指定的目录下。
比如 下载了arm-linux 的交叉编译器cross-3.3.2.tar.bz2,解压缩之后，运行 arm-linux-gcc -v
得到 --prefix=/usr/local/arm。那么就要把 bin lib 等所有的文件和文件夹到/usr/local/arm目录下。
否则到时候运行arm-linux-gcc hello.c会提示找不到stdio.h 或者 lib.so.6 等

HOWTO Use the GCC specs file

About Specs file
The "gcc" program invoked by users is a convenient front-end driver executable which will invoke other programs in the background such as cc1, as or ld to do its work according to the command line parameter given. A specs file is plain text used to control the default behavior for the "gcc" front-end. The specs file is usually built-in but for flexibility purposes, it can be overridden with an external version.
Basic Specs file modifications
CC will proce a specs file via the following command.
gcc -mpspecs > specs
You may use a text editor of your choice to inspect it. It may be confusing at first, but there are many places of interest. To use the specs file, invoke gcc with -specs= or place it at "/mingw/lib/gcc/mingw32//specs" to make GCC use it by default, where refers to the GCC version installed.
Adding include directories to the search path
& #160;he *cpp: section should be modified. It contains the following by default:
*cpp:
%{posix:-D_POSIX_SOURCE} %{mthreads:-D_MT}
If "z:\libx\include" needs to be added to the GCC includes search path, it should be changed to the following
*cpp:
%{posix:-D_POSIX_SOURCE} %{mthreads:-D_MT} -I/z/libx/include
Adding lib directories to the search path
& #160;he *link_libgcc: section should be modified. It contains the following by default:
*link_libgcc:
%D
& #160;f "z:\libx\lib" needs to be added to the GCC library search path, it should be changed to the following
*link_libgcc:
%D -L/z/libx/lib

❹ 关于交叉编译工具链的问题

核心转储是崩溃报告的一个过程，他只是把当前崩溃的信息转存出来方便差错。而且这个核心转储几个字也不过是个提示输出信息。这个提示不会给与任何与错误相关的内容，必须看其他的错误信息或者他转储出来的东西来分析。
不过核心转储，应该是程序运行出错而崩溃。这种问题出现在你正在运行的程序，而不是编译过程出现的编译错误（也就是说，出现核心转储应该就是 GCC 或者他调用的程序自己崩溃了）。出现这个问题的原因很多。

如果是因为没有找到某些 header 文件，不应该是核心转储错误，而是编译器或者某个过程提示错误信息后退出，他会输出错误信息告诉你问题所在。

至于你编译的这些东西版本都比较老，我建议还是尝试降级整个系统来编译、运行你现在的这些东西。或者升级你这个交叉编译工具链到当前主流的版本来用。

至于交叉工具连当中的 GCC 和你当前本机的 GCC，完全是两个互相独立的 GCC 。
只是他们编译输出的二进制程序针对的指令集不同而已。相对的 binutils 和 glibc 和 kernel-header 都是一样的意思，针对目标而输出的相关程序。当然 glibc 和 kernel-header 主要是以“数据”方式存在，gcc 和 binutils 主要是以可以运行的程序方式存在（当然不是绝对的，比如 gcc 还会提供几个 lib 相关的内容，不过大部分情况下你可以这么理解更直观了解他们的作用）。
一般说来 GCC 是编译器，binutils 是连接器，glibc 是标准 C 库（主要是连接时，连接器必须有目标的函数库文件，也就是 .so 文件，对应 Windows 是 .dll 文件。连接器把函数调用正确的挂接到对应的函数入口上）。linux header 就是 C 语言常见的 C header 文件和相关的开发数据。一般主要用来编译 glibc ，glibc 作为中间层来提供内核相关调用。当然程序有些时候也会直接调用内核函数，这样这些程序在编译时也需要 kernel 的 header 。

这两套东西一个输出你当前 PC 的程序，一个输出 ARM 的程序。两个 GCC 套装之间不能互相替换。只能自己输出属于自己的程序。
但是这两套程序虽然输出的程序不同，但可以运行的部分，却都是在你的计算机上运行。而且你本机的 GCC 因为可以输出本机的程序。所以你需要用他来输出在你本机运行，但是却输出 ARM 程序的 GCC 套装。

这就好比两个锤子，一个锤子用来打铁，一个锤子用来打锡。用途不同，但这两个锤子都是铁做的。
你作这个交叉编译工具链，就是用你手里已经有的打铁的锤子，打出一个用铁制作的用来打锡的锤子。这个打锡的锤子是不能打铁的，同样这个打铁的锤子是不能用来打锡的。

❺ Linux下用交叉编译器编译报错缺少Libc.so.6【求教】

#打开/etc/ld.so.conf，在最后一行添加/home/xassassin/armlinuxdev/bin/lib/
$sudovim/etc/ld.so.conf
#执行此命令，然后再编译
$sudoldconfig

❻ 执行可执行文件时说找不到.so文件是为什么

当出现：error
while
loading
shared
libraries:
libz.so.1:
cannot
open
shared
object
file:
no
such
file
or
directory.时，我们首先知道的是缺少libz.so.1这个dll文件。
解决方法：很明显就是安装这个库所在包咯，可是我们怎么这知道
libz.s。

❼ libnet交叉编译只生成一个libnet.a文件，没有生成libnet.so文件，请问为什么

.a类似静态lib,.so类似与动态dll.所以这跟你的makefile相关

❽ linux下ndk-bulid编译形成了so文件，在windows环境下的eclipse怎么使用

可以直接在android工程下使用，因为android就是linux内核。

1. android的NDK开发需要在linux下进行： 因为需要把C/C++编写的代码生成能在arm上运行的.so文件，这就需要用到交叉编译环境，而交叉编译需要在linux系统下才能完成。

2. 2.安装android-ndk开发包，这个开发包可以在google android ： 通过这个开发包的工具才能将android jni 的C/C++的代码编译成库

3. 3.android应用程序开发环境： 包括eclipse、java、 android sdk、 adt等。

NDK编译步骤：

1. 选择 ndk 自带的例子 hello-jni ，位于E:android-ndk-r5sampleshello-jni( 根据具体的安装位置而定 ) 。

2. 2.运行 cygwin ，输入命令 cd /cygdrive/e/android-ndk-r5/samples/hello-jni ，进入到 E:android-ndk-r5sampleshello-jni 目录。

3. 3.输入 $NDK/ndk-build ，执行成功后，它会自动生成一个 libs 目录，把编译生成的 .so 文件放在里面。 ($NDK是调用我们之前配置好的环境变量， ndk-build 是调用 ndk 的编译程序 )

4. 4.此时去 hello-jni 的 libs 目录下看有没有生成的 .so 文件，如果有，ndk 就运行正常啦。
   

❾ android studio JNI开发时 编译成功 但是没有生成.so文件 什么原因

1
在交叉编译的时候怎么都无法生成so文件，javah生成头文件没错，c文件也没错，java文件也没错，
2.原因：是JNI文件夹路径不对
3
在执行javah命令时，我进入的是cd
app/src/main/java
这样jni文件夹在java文件夹下，作为一个包存在，这样就无法生成so文件
执行javah的正确姿势：
4
进入app/src/main目录：cd
app/src/main
执行javah命令：javah
javah
-d
jni
-classpath
./Java
lab.sodino.jnitest.MainActivity
5，
-d
jni
头文件生成到jni文件夹（当前在<Project>\app\src\main目录下，所以.h所在的目录为<Project>\app\src\main\jni
）
-classpath
./java
指定去当前路径下java下寻找包名指定的类
这样再rebuild一下，就会生成so文件了

❿ ARM交叉编译找不到对应的库文件，如何生成AR

那些so的lib文件都在目录/opt/arm-cross-soft/gcc-3.4.5-glibc-2.3.5/arm-softfloat-linux-gnu/arm-softfloat-linux-gnu/lib下。
直接就能找到，你看看。