2013-01-23 60 views
3

我有一個將boost庫鏈接到我的交叉編譯的C++程序的問題。 我編寫的代碼與Ubuntu 12.04下的CodeSourcery交叉編譯,用於arm-target(Pandaboard,也是Ubuntu 12.04)。 編譯沒有庫的簡單測試程序可以正常工作,即使使用靜態庫的OpenCV也能正常工作。連接boost庫時程序退出時沒有錯誤

當鏈接Boost庫(-lboost_thread -lboost_system)程序編譯沒有錯誤,但在目標執行時,它crosscompiled,什麼都不會發生:

但這裏連接升壓1.52.0庫時的問題。

程序無錯地完成,就好像它從未執行過一樣。

當CodeSourcery與CodeSourcery交叉編譯時,沒有鏈接boost庫:一切工作正常。 用g ++本地編譯:一切都很好。

出於測試目的,我剝奪了我的代碼下面幾行: (誤差甚至出現時不使用計時功能只是鏈接使得差)

的main.cpp

#include <iostream> 
using namespace std; 

#include<boost/chrono.hpp> 

int main(int argc, char* argv[]) { 

    cout << "!!!this test worked!!!" << endl; 

    return 0; 
} 

鏈接器命令是(下蝕):

arm-none-linux-gnueabi-g++ -L/home/xy/arm-none-linux-gnueabi/lib -o "testARM" ./src/main.o -lpthread -lboost_thread -lboost_system 

升壓文庫具有CodeSourcery臂-NONE-Linux的gnueabi-G ++ followi交叉編譯ng this guide。 我將它們全部複製到/ usr/lib文件夾中,並將/ usr/lib添加到PATH和LD_LIBRARY_PATH中。

我試着用eclipse和遠程調試一樣:啓動程序..程序終止於1. 但是沒有任何結果。

它甚至不打印錯誤或抱怨丟失的東西。 因此,現在我不能想到更多我可以谷歌,我還沒有嘗試過...

你能給我任何提示什麼,我可以嘗試解決這個問題嗎?

非常感謝提前!


更新:

當運行我的strace的測試程序,該日誌包含以下信息:

 

    $ vi strace-testARM.log 
    22:23:56.511385 execve("./testARM", ["./testARM"], [/* 17 vars */]) = 0 
    22:23:56.512789 brk(0)     = 0xfae000 
    22:23:56.512972 uname({sys="Linux", node="panda", ...}) = 0 
    22:23:56.514010 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) 
    22:23:56.514315 mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6f9b000 
    22:23:56.514498 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) 
    22:23:56.514742 open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 
    22:23:56.514986 fstat64(3, {st_mode=S_IFREG|0644, st_size=52288, ...}) = 0 
    22:23:56.515353 mmap2(NULL, 52288, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb6f72000 
    22:23:56.515536 close(3)    = 0 
    22:23:56.515688 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) 
    22:23:56.515902 open("/lib/arm-linux-gnueabihf/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3 
    22:23:56.516207 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\5P\0\0004\0\0\0"..., 512) = 512 
    22:23:56.516451 lseek(3, 66332, SEEK_SET) = 66332 
    22:23:56.516573 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1400) = 1400 
    22:23:56.516787 lseek(3, 65924, SEEK_SET) = 65924 
    22:23:56.516909 read(3, "A6\0\0\0aeabi\0\1,\0\0\0\0057-A\0\6\n\7A\10\1\t\2\n\4\22"..., 55) = 55 
    22:23:56.517153 fstat64(3, {st_mode=S_IFREG|0755, st_size=100802, ...}) = 0 
    22:23:56.517519 mmap2(NULL, 107024, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6f57000 
    22:23:56.517642 mprotect(0xb6f67000, 28672, PROT_NONE) = 0 
    22:23:56.517794 mmap2(0xb6f6e000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xf) = 0xb6f6e000 
    22:23:56.517977 mmap2(0xb6f70000, 4624, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb6f70000 
    22:23:56.518160 close(3)    = 0 
    22:23:56.518313 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) 
    22:23:56.518557 open("/lib/arm-linux-gnueabihf/tls/v7l/neon/vfp/libboost_thread.so.1.52.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 
    22:23:56.518832 stat64("/lib/arm-linux-gnueabihf/tls/v7l/neon/vfp", 0xbea34ea8) = -1 ENOENT (No such file or directory) 
    22:23:56.519076 open("/lib/arm-linux-gnueabihf/tls/v7l/neon/libboost_thread.so.1.52.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file 
... [ lots of other directories with file not found ] ... 
    22:23:56.545382 stat64("/usr/lib/neon/vfp", 0xbea34ea8) = -1 ENOENT (No such file or directory) 
    22:23:56.545565 open("/usr/lib/neon/libboost_thread.so.1.52.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 
    22:23:56.545748 stat64("/usr/lib/neon", 0xbea34ea8) = -1 ENOENT (No such file or directory) 
    22:23:56.545932 open("/usr/lib/vfp/libboost_thread.so.1.52.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 
    22:23:56.546115 stat64("/usr/lib/vfp", 0xbea34ea8) = -1 ENOENT (No such file or directory) 
    22:23:56.546298 open("/usr/lib/libboost_thread.so.1.52.0", O_RDONLY|O_CLOEXEC) = 3 
    22:23:56.546481 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\324\331\0\0004\0\0\0"..., 512) = 512 
    22:23:56.546755 lseek(3, 121020, SEEK_SET) = 121020 
    22:23:56.546878 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1200) = 1200 
    22:23:56.547091 lseek(3, 119052, SEEK_SET) = 119052 
    22:23:56.547213 read(3, "A(\0\0\0aeabi\0\1\36\0\0\0\0055TE\0\6\4\10\1\t\1\22\4\24\1\25"..., 41) = 41 
    22:23:56.547396 exit_group(1)   = ? 


更新2:

我編譯我的編上一個Ubuntu主機RAM,文件轉移到PANDABOARD和發出以下命令的建議通過@ShaunMarko:

`ldd testARM` => `not a dynamic executable` 

`file testARM` => `testARM: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, not stripped` 

`file libboost_thread.so.1.52.0` => `libboost_thread.so.1.52.0: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, not stripped` 

添加-v -H到編譯克++表達式我得到:

... /xy/CodeSourcery/bin/../lib/gcc/arm-none-linux-gnueabi/4.7.2/../../../../arm-none-linux-gnueabi/include/boost/utility/result_of.hpp 

COLLECT_GCC_OPTIONS='-O0' '-g3' '-Wall' '-c' '-fmessage-length=0' '-v' '-H' '-MMD' '-MP' '-MF' 'main.d' '-MT' 'main.d' '-o' 'main.o' '-shared-libgcc' '-march=armv5te' '-mtls-dialect=gnu' '-funwind-tables' '-D' '__CS_SOURCERYGXX_MAJ__=2012' '-D' '__CS_SOURCERYGXX_MIN__=9' '-D' '__CS_SOURCERYGXX_REV__=64' 
/xy/CodeSourcery/bin/../lib/gcc/arm-none-linux-gnueabi/4.7.2/../../../../arm-none-linux-gnueabi/bin/as -v -march=armv5te -meabi=5 -o main.o /tmp/cceTwLmn.s 
GNU assembler version 2.23.51 (arm-none-linux-gnueabi) using BFD version (Sourcery CodeBench Lite 2012.09-64) 2.23.51.20120829 
COMPILER_PATH=/xy/CodeSourcery/bin/../libexec/gcc/arm-none-linux-gnueabi/4.7.2/:/xy/CodeSourcery/bin/../libexec/gcc/:/xy/CodeSourcery/bin/../lib/gcc/arm-none-linux-gnueabi/4.7.2/../../../../arm-none-linux-gnueabi/bin/ 
LIBRARY_PATH=/xy/CodeSourcery/bin/../lib/gcc/arm-none-linux-gnueabi/4.7.2/:/xy/CodeSourcery/bin/../lib/gcc/:/xy/CodeSourcery/bin/../lib/gcc/arm-none-linux-gnueabi/4.7.2/../../../../arm-none-linux-gnueabi/lib/:/xy/CodeSourcery/bin/../arm-none-linux-gnueabi/libc/lib/:/xy/CodeSourcery/bin/../arm-none-linux-gnueabi/libc/usr/lib/ 
COLLECT_GCC_OPTIONS='-O0' '-g3' '-Wall' '-c' '-fmessage-length=0' '-v' '-H' '-MMD' '-MP' '-MF' 'main.d' '-MT' 'main.d' '-o' 'main.o' '-shared-libgcc' '-march=armv5te' '-mtls-dialect=gnu' '-funwind-tables' '-D' '__CS_SOURCERYGXX_MAJ__=2012' '-D' '__CS_SOURCERYGXX_MIN__=9' '-D' '__CS_SOURCERYGXX_REV__=64' 

**** Build Finished **** 

(這是最後一部分,上面列出了包含的標題噸。在XY路徑是安裝在我的主目錄CodeSourcery的)

+0

你可以用strace(https://wiki.ubuntu.com/Strace)在目標上運行你的程序嗎? –

+0

感謝您的回答。我上面張貼了strace-log。你能從中得到任何有用的信息嗎? – Felix

+0

您可以在目標上發佈「'ldd' testARM」以確保所有參考都已解決。 –

回答

3

構建ARM應用程序(實際上它必須是任何平臺真)

您必須編譯整個程序通則相同的ABI,並與一組兼容的庫鏈接。

在你的情況下最後一個項目看起來像/usr/lib/libboost_thread.so.1.52.0,並因爲它也涉及到您的使用情況,確保libboost_thread匹配,你是交叉編譯的主機上的一個。

22:23:56.546298 open("/usr/lib/libboost_thread.so.1.52.0", O_RDONLY|O_CLOEXEC) = 3 
22:23:56.546481 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\324\331\0\0004\0\0\0"..., 512) = 512 
22:23:56.546755 lseek(3, 121020, SEEK_SET) = 121020 
22:23:56.546878 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1200) = 1200 
22:23:56.547091 lseek(3, 119052, SEEK_SET) = 119052 
22:23:56.547213 read(3, "A(\0\0\0aeabi\0\1\36\0\0\0\0055TE\0\6\4\10\1\t\1\22\4\24\1\25"..., 41) = 41 
22:23:56.547396 exit_group(1)   = ? 

隨着ARM系統,你可以有一個像不同的ABI或VFP/NEON支持和得到一個現成的工具鏈庫的許多變體可能不符合你的缺省目標,只是因爲它是ARM。

更新

如果檢查以前的日誌

22:23:56.515902 open("/lib/arm-linux-gnueabihf/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3 
22:23:56.516207 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\5P\0\0004\0\0\0"..., 512) = 512 
22:23:56.516451 lseek(3, 66332, SEEK_SET) = 66332 
22:23:56.516573 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1400) = 1400 
22:23:56.516787 lseek(3, 65924, SEEK_SET) = 65924 
22:23:56.516909 read(3, "A6\0\0\0aeabi\0\1,\0\0\0\0057-A\0\6\n\7A\10\1\t\2\n\4\22"..., 55) = 55 

你看兩點,一是你的系統是從路徑hf。在讀取的數據中,我們也看到7-A,這可能意味着ARMv7-A與5TE相比,這可能意味着libboost_thread庫中的ARMv5TE。您應該使用工具鏈中的readelf來獲取有關elf文件的信息,而不是文件實用程序。

我試着用-march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard來編譯boost,並把得到的二進制文件放在`/ usr/lib/vfp下。

我認爲從Debian網站讀取vfp stuff可以大大地幫助你,你應該自己做一些小練習,而不是處理提高的編譯過程以瞭解情況。

+0

感謝您的提示,我現在做了一些關於ABI和abihf(顯然是Ubuntu 12.04的默認設置)的研究。 我現在已經嘗試編譯完整的boost庫,之後我的程序使用標誌'-mfloat-abi = hard',以及'-mfloat-abi = softfp'不幸的是在兩種情況下都沒有改變。 – Felix

+0

從我讀到目前爲止,我可以想象的一件事是該程序在運行時混合硬和軟浮點庫。 有沒有辦法執行程序強制它只搜索所需的共享庫? (例如,'libstdC++'等等......)'/ usr/lib /'文件夾中有一個,'/ usr/lib/arm-linux-gnueabihf'中有一個,我需要說'使用一個' – Felix

+0

@Felix更新了我的答案。 – auselen

相關問題