交叉編譯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下。
直接就能找到，你看看。