Ⅰ linux對應的安裝腳本怎樣查
在Linux 操作系統中，有一個系統軟體包，它的功能類似於Windows裡面的「添加/刪除程序」，但是功能又比「添加/刪除程序」強很多，它就是 Red Hat Package Manager(簡稱RPM)。此工具包最先是由Red Hat公司推出的，後來被其他Linux開發商所借用。由於它為Linux使用者省去了很多時間，所以被廣泛應用於在Linux下安裝、刪除軟體。下面就給大家介紹一下它的具體使用方法。
1.我們得到一個新軟體，在安裝之前，一般都要先查看一下這個軟體包里有什麼內容，假設這個文件是：Linux-1.4-6.i368.rpm，我們可以用這條命令查看：
rpm -qpi Linux-1.4-6.i368.rpm
系統將會列出這個軟體包的詳細資料，包括含有多少個文件、各文件名稱、文件大小、創建時間、編譯日期等信息。
2.上面列出的所有文件在安裝時不一定全部安裝，就像Windows下程序的安裝方式分為典型、完全、自定義一樣，Linux也會讓你選擇安裝方式，此時我們可以用下面這條命令查看軟體包將會在系統里安裝哪些部分，以方便我們的選擇：
rpm -qpl Linux-1.4-6.i368.rpm
3. 選擇安裝方式後，開始安裝。我們可以用rpm-ivh Linux-1.4-6.i368.rpm命令安裝此軟體。在安裝過程中，若系統提示此軟體已安裝過或因其他原因無法繼續安裝，但若我們確實想執行安裝命令，可以在 -ivh後加一參數「-replacepkgs」：
rpm -ivh -replacepkgs Linux-1.4-6.i368.rpm
4.有時我們卸載某個安裝過的軟體，只需執行rpm-e <文件名>;命令即可。
5.對低版本軟體進行升級是提高其功能的好辦法，這樣可以省去我們卸載後再安裝新軟體的麻煩，要升級某個軟體，只須執行如下命令：rpm -uvh <文件名>;，注意：此時的文件名必須是要升級軟體的升級補丁
6. 另外一個安裝軟體的方法可謂是Linux的獨到之處，同時也是RMP強大功能的一個表現：通過FTP站點直接在線安裝軟體。當找到含有你所需軟體的站點並與此網站連接後，執行下面的命令即可實現在線安裝，譬如在線安裝Linux-1.4-6.i368.rpm，可以用命令：
rpm -i ftp://ftp.pht.com/pub/linux/redhat/...-1.4-6.i368.rpm
7. 在我們使用電腦過程中，難免會有誤操作，若我們誤刪了幾個文件而影響了系統的性能時，怎樣查找到底少了哪些文件呢?RPM軟體包提供了一個查找損壞文件的功能，執行此命令：rpm -Va即可，Linux將為你列出所有損壞的文件。你可以通過Linux的安裝光碟進行修復。
8.Linux系統中文件繁多，在使用過程中，難免會碰到我們不認識的文件，在Windows下我們可以用「開始/查找」菜單快速判斷某個文件屬於哪個文件夾，在Linux中，下面這條命令行可以幫助我們快速判定某個文件屬於哪個軟體包：
rpm -qf <文件名>;
9.當每個軟體包安裝在Linux系統後，安裝文件都會到RPM資料庫中「報到」，所以，我們要查詢某個已安裝軟體的屬性時，只需到此資料庫中查找即可。注意：此時的查詢命令不同於1和8介紹的查詢，這種方法只適用於已安裝過的軟體包！命令格式：
rpm -參數<文件名>;
Ⅱ 如何查看程序被哪個版本編譯器編譯的linux-gcc
那是不可能的，除非你加入了調試信息，也就是編譯的時候加入了-g參數，然後用gdb調試就可以顯示。最大程度上查看一個elf文件信息。
｛
readelf -Wa a.out | head
readelf -wi a.out
readelf -p .comment a.out
objmp -s --section .comment audioplayer
｝
如下：
[root@localhost rootfs]# readelf -Wa bin/gzip
復制代碼
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: ARM
Version: 0x1
Entry point address: 0xa080
Start of program headers: 52 (bytes into file)
Start of section headers: 1975444 (bytes into file)
Flags: 0x5000002, has entry point, Version5 EABI
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 6
Size of section headers: 40 (bytes)
Number of section headers: 25
Section header string table index: 24
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .note.ABI-tag NOTE 000080f4 0000f4 000020 00 A 0 0 4
[ 2] .init PROGBITS 00008114 000114 00000c 00 AX 0 0 4
[ 3] .text PROGBITS 00008120 000120 17fcfc 00 AX 0 0 16
[ 4] __libc_freeres_fn PROGBITS 00187e1c 17fe1c 000f20 00 AX 0 0 4
[ 5] __libc_thread_fre PROGBITS 00188d3c 180d3c 0000e4 00 AX 0 0 4
[ 6] .fini PROGBITS 00188e20 180e20 000008 00 AX 0 0 4
[ 7] .rodata PROGBITS 00188e28 180e28 058147 00 A 0 0 8
[ 8] __libc_subfreeres PROGBITS 001e0f70 1d8f70 00005c 00 A 0 0 4
[ 9] __libc_atexit PROGBITS 001e0fcc 1d8fcc 000004 00 A 0 0 4
[10] __libc_thread_sub PROGBITS 001e0fd0 1d8fd0 000008 00 A 0 0 4
[11] .ARM.extab PROGBITS 001e0fd8 1d8fd8 001b04 00 A 0 0 4
[12] .ARM.exidx ARM_EXIDX 001e2adc 1daadc 006ea8 00 AL 3 0 4
[13] .tdata PROGBITS 001f1984 1e1984 000018 00 WAT 0 0 4
[14] .tbss NOBITS 001f199c 1e199c 000034 00 WAT 0 0 4
[15] .init_array INIT_ARRAY 001f199c 1e199c 000004 00 WA 0 0 4
[16] .fini_array FINI_ARRAY 001f19a0 1e19a0 000008 00 WA 0 0 4
[17] .jcr PROGBITS 001f19a8 1e19a8 000004 00 WA 0 0 4
[18] .data.rel.ro PROGBITS 001f19ac 1e19ac 00002c 00 WA 0 0 4
[19] .got PROGBITS 001f19d8 1e19d8 00007c 04 WA 0 0 4
[20] .data PROGBITS 001f1a58 1e1a58 0008f7 00 WA 0 0 8
[21] .bss NOBITS 001f2350 1e234f 004828 00 WA 0 0 8
[22] __libc_freeres_pt NOBITS 001f6b78 1e234f 00003c 00 WA 0 0 4
[23] .ARM.attributes ARM_ATTRIBUTES 00000000 1e234f 00002b 00 0 0 1
[24] .shstrtab STRTAB 00000000 1e237a 000118 00 0 0 1
Section to Segment mapping:
Segment Sections...
00 .ARM.exidx
01 .note.ABI-tag .init .text __libc_freeres_fn __libc_thread_freeres_fn .fini .rodata __libc_subfreeres __libc_atexit __libc_thread_subfreeres .ARM.extab .ARM.exidx
02 .tdata .init_array .fini_array .jcr .data.rel.ro .got .data .bss __libc_freeres_ptrs
03 .note.ABI-tag
04 .tdata .tbss
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "5TE"
Tag_CPU_arch: v5TE
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-1
Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align8_needed: Yes
Tag_ABI_align8_preserved: Yes, except leaf SP
Tag_ABI_enum_size: int
Tag_unknown_44: 1 (0x1)
復制代碼
How to retrieve the GCC version used to compile a given ELF executable? http://stackoverflow.com/questions/2387040/how-to-retrieve-the-gcc-version-used-to-compile-a-given-elf-executable
QUES: I'd like to retrieve the GCC version used to compile a given executable. I tried readelf but didn't get the information. Any thoughts?
ANS: To complete what others have said: it's not stored in the object (or exe) file, unless you compile with debugging information! (option -g). If you compile with debug info, you can get it back with readelf:
復制代碼
[root@localhost test]# gcc a.c
[root@localhost test]# readelf -wi a.out
[root@localhost test]# gcc a.c -g
[root@localhost test]# readelf -wi a.out
The section .debug_info contains:
Compilation Unit @ offset 0x0:
Length: 135
Version: 2
Abbrev Offset: 0
Pointer Size: 8
<0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
DW_AT_stmt_list : 0
DW_AT_high_pc : 0x400453
DW_AT_low_pc : 0x400448
DW_AT_procer : GNU C 4.1.2 20080704 (Red Hat 4.1.2-55)
DW_AT_language : 1 (ANSI C)
DW_AT_name : a.c
DW_AT_comp_dir : /work/farsight/test
<1><61>: Abbrev Number: 2 (DW_TAG_subprogram)
DW_AT_external : 1
DW_AT_name : main
DW_AT_decl_file : 1
DW_AT_decl_line : 4
DW_AT_prototyped : 1
DW_AT_type : <83>
DW_AT_low_pc : 0x400448
DW_AT_high_pc : 0x400453
DW_AT_frame_base : 0 (location list)
<1><83>: Abbrev Number: 3 (DW_TAG_base_type)
DW_AT_name : int
DW_AT_byte_size : 4
DW_AT_encoding : 5 (signed)
復制代碼
ANS2：
Ⅲ linux下，怎麼使用命令查看編譯好的程序信息比如想知道程序載入到什麼地址之類的信息
每個當前激活的進程都會在/proc目錄下有個文件夾，名稱是PID號
所有你能看到的信息都在裡面
變數能看到它們的邏輯地址，在maps文件裡面有，真實的物理地址就是CR3+邏輯地址
Ⅳ 如何加快linux android 的編譯速度
項目越來越大，每次需要重新編譯整個項目都是一件很浪費時間的事情。Research了一下，找到以下可以幫助提高速度的方法，總結一下。
1. 使用tmpfs來代替部分IO讀寫
2.ccache，可以將ccache的緩存文件設置在tmpfs上，但是這樣的話，每次開機後，ccache的緩存文件會丟失
3.distcc,多機器編譯
4.將屏幕輸出列印到內存文件或者/dev/null中，避免終端設備（慢速設備）拖慢速度。
tmpfs
有人說在Windows下用了RAMDisk把一個項目編譯時間從4.5小時減少到了5分鍾，也許這個數字是有點誇張了，不過粗想想，把文件放到內存上做編譯應該是比在磁碟上快多了吧，尤其如果編譯器需要生成很多臨時文件的話。
這個做法的實現成本最低，在Linux中，直接mount一個tmpfs就可以了。而且對所編譯的工程沒有任何要求，也不用改動編譯環境。
mount -t tmpfs tmpfs ~/build -o size=1G
用2.6.32.2的Linux Kernel來測試一下編譯速度：
用物理磁碟：40分16秒
用tmpfs：39分56秒
呃……沒什麼變化。看來編譯慢很大程度上瓶頸並不在IO上面。但對於一個實際項目來說，編譯過程中可能還會有打包等IO密集的操作，所以只要可能，用tmpfs是有益無害的。當然對於大項目來說，你需要有足夠的內存才能負擔得起這個tmpfs的開銷。
make -j
既然IO不是瓶頸，那CPU就應該是一個影響編譯速度的重要因素了。
用make -j帶一個參數，可以把項目在進行並行編譯，比如在一台雙核的機器上，完全可以用make -j4，讓make最多允許4個編譯命令同時執行，這樣可以更有效的利用CPU資源。
還是用Kernel來測試：
用make： 40分16秒
用make -j4：23分16秒
用make -j8：22分59秒
由此看來，在多核CPU上，適當的進行並行編譯還是可以明顯提高編譯速度的。但並行的任務不宜太多，一般是以CPU的核心數目的兩倍為宜。
不過這個方案不是完全沒有cost的，如果項目的Makefile不規范，沒有正確的設置好依賴關系，並行編譯的結果就是編譯不能正常進行。如果依賴關系設置過於保守，則可能本身編譯的可並行度就下降了，也不能取得最佳的效果。
ccache
ccache工作原理：
ccache也是一個編譯器驅動器。第一趟編譯時ccache緩存了GCC的「-E」輸出、編譯選項以及.o文件到$HOME/.ccache。第二次編譯時盡量利用緩存，必要時更新緩存。所以即使"make clean; make"也能從中獲得好處。ccache是經過仔細編寫的，確保了與直接使用GCC獲得完全相同的輸出。
ccache用於把編譯的中間結果進行緩存，以便在再次編譯的時候可以節省時間。這對於玩Kernel來說實在是再好不過了，因為經常需要修改一些Kernel的代碼，然後再重新編譯，而這兩次編譯大部分東西可能都沒有發生變化。對於平時開發項目來說，也是一樣。為什麼不是直接用make所支持的增量編譯呢？還是因為現實中，因為Makefile的不規范，很可能這種「聰明」的方案根本不能正常工作，只有每次make clean再make才行。
安裝完ccache後，可以在/usr/local/bin下建立gcc，g++，c++，cc的symbolic link，鏈到/usr/bin/ccache上。總之確認系統在調用gcc等命令時會調用到ccache就可以了（通常情況下/usr/local /bin會在PATH中排在/usr/bin前面）。
安裝的另外一種方法：
vi ~/.bash_profile
把/usr/lib/ccache/bin路徑加到PATH下
PATH=/usr/lib/ccache/bin:$PATH:$HOME/bin
這樣每次啟動g++的時候都會啟動/usr/lib/ccache/bin/g++，而不會啟動/usr/bin/g++
效果跟使用命令行ccache g++效果一樣
這樣每次用戶登錄時，使用g++編譯器時會自動啟動ccache
繼續測試：
用ccache的第一次編譯(make -j4)：23分38秒
用ccache的第二次編譯(make -j4)：8分48秒
用ccache的第三次編譯(修改若干配置，make -j4)：23分48秒
看來修改配置（我改了CPU類型...）對ccache的影響是很大的，因為基本頭文件發生變化後，就導致所有緩存數據都無效了，必須重頭來做。但如果只是修改一些.c文件的代碼，ccache的效果還是相當明顯的。而且使用ccache對項目沒有特別的依賴，布署成本很低，這在日常工作中很實用。
可以用ccache -s來查看cache的使用和命中情況：
cache directory /home/lifanxi/.ccachecache hit 7165cache miss 14283called for link 71not a C/C++ file 120no input file 3045files in cache 28566cache size 81.7 Mbytesmax cache size 976.6 Mbytes
可以看到，顯然只有第二編次譯時cache命中了，cache miss是第一次和第三次編譯帶來的。兩次cache佔用了81.7M的磁碟，還是完全可以接受的。
distcc
一台機器的能力有限，可以聯合多台電腦一起來編譯。這在公司的日常開發中也是可行的，因為可能每個開發人員都有自己的開發編譯環境，它們的編譯器版本一般是一致的，公司的網路也通常具有較好的性能。這時就是distcc大顯身手的時候了。
使用distcc，並不像想像中那樣要求每台電腦都具有完全一致的環境，它只要求源代碼可以用make -j並行編譯，並且參與分布式編譯的電腦系統中具有相同的編譯器。因為它的原理只是把預處理好的源文件分發到多台計算機上，預處理、編譯後的目標文件的鏈接和其它除編譯以外的工作仍然是在發起編譯的主控電腦上完成，所以只要求發起編譯的那台機器具備一套完整的編譯環境就可以了。
distcc安裝後，可以啟動一下它的服務：
/usr/bin/distccd --daemon --allow 10.64.0.0/16
默認的3632埠允許來自同一個網路的distcc連接。
然後設置一下DISTCC_HOSTS環境變數，設置可以參與編譯的機器列表。通常localhost也參與編譯，但如果可以參與編譯的機器很多，則可以把localhost從這個列表中去掉，這樣本機就完全只是進行預處理、分發和鏈接了，編譯都在別的機器上完成。因為機器很多時，localhost的處理負擔很重，所以它就不再「兼職」編譯了。
export DISTCC_HOSTS="localhost 10.64.25.1 10.64.25.2 10.64.25.3"
然後與ccache類似把g++，gcc等常用的命令鏈接到/usr/bin/distcc上就可以了。
在make的時候，也必須用-j參數，一般是參數可以用所有參用編譯的計算機CPU內核總數的兩倍做為並行的任務數。
同樣測試一下：
一台雙核計算機，make -j4：23分16秒
兩台雙核計算機，make -j4：16分40秒
兩台雙核計算機，make -j8：15分49秒
跟最開始用一台雙核時的23分鍾相比，還是快了不少的。如果有更多的計算機加入，也可以得到更好的效果。
在編譯過程中可以用distccmon-text來查看編譯任務的分配情況。distcc也可以與ccache同時使用，通過設置一個環境變數就可以做到，非常方便。
總結一下：
tmpfs： 解決IO瓶頸，充分利用本機內存資源
make -j： 充分利用本機計算資源
distcc： 利用多台計算機資源
ccache： 減少重復編譯相同代碼的時間
這些工具的好處都在於布署的成本相對較低，綜合利用這些工具，就可以輕輕鬆鬆的節省相當可觀的時間。上面介紹的都是這些工具最基本的用法，更多的用法可以參考它們各自的man page。
5.還有提速方法是把屏幕輸出重定向到內存文件或/dev/null,因對終端設備(慢速設備)的阻塞寫操作也會拖慢速度。推薦內存文件，這樣發生錯誤時，能夠查看。
Ⅳ 編譯linux內核要多久
至於說編譯 Linux 內核需要多長時間，這個和電腦的整體性能（例如：CPU主頻、內存大小等）有很大關系。我的親身體會就是：計算機性能差的，編譯 Linux 內核需要一個多小時的都有（以前在老舊的電腦上就需要這么長的時間）。
Ⅵ 怎麼查看linux庫是使用哪個版本的編譯器編譯的
如果是你自己編譯的
那麼gcc
-v
查看本機版本號。
如果是你拿到的別人的，可以
objmp -s --section=.comment your_program查看程序編譯器版本
Ⅶ linux 怎麼查看正在編譯的進程
linux系統中關於進程的命令 是ps 下面是ps 的命令格式：
ps [options] [--help]
常用選項：
-A 列出所有的進程
-w 顯示加寬可以顯示較多的資訊
-au 顯示較詳細的資訊
-aux 顯示所有包含其他使用者的行程
例子：
查看當前系統進程的uid,pid,stat,pri, 以uid號排序.
ps -eo pid,stat,pri,uid –sort uid