[Linux] 計算程式運行的最低需求(Code size & Shared libraries) @ Ubuntu 12.04

這幾個月處理一些跑在 Embedded System 的小工具、小服務，每次 porting 後，總要計算一下程式的大小，這時計算的原理就是用 ldd、objdump 或 readelf 看一下呼叫了哪些 shared library，把他們加一加就差不多了。然而，需要留意的則是 shared library 還會在 link 其他 shared library，所以用到的 shared library 也要一併挑出來查看一下才行。

不知不覺就寫了 script 來處理，原理就是建 hash 來判斷 shared library 判斷過了沒。

$ git clone https://github.com/changyy/resource-calculator.git
$ ./resource-calculator/resource-calculator.sh
Usage> ./resource-calculator.sh -v -r path_bin_readelf -s path_bin_strip -o output_dir -l path_for_library_finding  [ BIN_FILE | BIN_DIR | LIB_FILE | LIB_DIR ] ...

其中 -r 是吃 readelf 工具位置，可以用 -r `which armv6-linux-gnueabi-readelf`；-s 是指定 strip 位置，也就是產出時順便 strip 一下；-o 則是輸出到指定輸出目錄；-l 是指定讀取 shared library 位置，如 cross compiler 的 library 位置、platform sysroot/lib 位置和第三方 shared library 位置等；最後的參數則是要驗證的 tool 或 library ，若接目錄則是進去撈 bin 或 so 出來。

實例 (已在 PATH 環境變數中加入 cross compiler 的搜尋位置)：

$ ./resource-calculator/resource-calculator.sh -o /tmp/output -r `which armv6-linux-gnueabi-readelf` -s `which armv6-linux-gnueabi-strip` -l /path/armv6-linux-gnueabi/compiler/lib -l /path/armv6-linux-gnueabi/platform/sysroot/lib -l /path/armv6-linux-gnueabi/3rd-party/lib /path/imagemagick-convert

[INFO] READELF: /path/armv6-linux-gnueabi-readelf
[INFO] STRIP: /path/armv6-linux-gnueabi-strip
[INFO] OTHER LIB: /path/armv6-linux-gnueabi/compiler/lib /path/armv6-linux-gnueabi/platform/sysroot/lib /path/armv6-linux-gnueabi/3rd-party/lib
[INFO] TARGET: /path/imagemagick-convert
[INFO] OUTPUT: /tmp/output/lib /tmp/output/bin /tmp/output/slib
-------------
..............*...............*
All:
       libdl.so.2 libm.so.6 librt.so.1 libpthread.so.0 libMagickWand-6.Q8.so.1 libgcc_s.so.1 libjpeg.so.62 libpng10.so.0 libtiff.so.5 libz.so.1 libMagickCore-6.Q8.so.1 libc.so.6 ld-linux.so.3 libxml2.so.2 libgomp.so.1

$ du -h /tmp/output/
6.7M    /tmp/output/lib
1.9M    /tmp/output/slib
12K     /tmp/output/bin
8.5M   /tmp/output/

$ ls -R /tmp/output/
/tmp/output/:
bin  lib  slib

/tmp/output/bin:
convert

/tmp/output/lib:
libdl.so.2     libMagickCore-6.Q8.so.1  libtiff.so.5
libgomp.so.1   libMagickWand-6.Q8.so.1  libxml2.so.2
libjpeg.so.62  libpng10.so.0            libz.so.1

/tmp/output/slib:
ld-linux.so.3  libc.so.6  libgcc_s.so.1  libm.so.6  libpthread.so.0  librt.so.1

故程式運行時所需的 size 是 8.5MB ，但其中有 sysroot libraries 為 1.9MB ，所以移植到板子上的程式碼大小 = 8.5MB - 1.9MB。

[Linux] 關於 Camera Orientation 問題 @ Ubuntu 12.04

得知隔壁 Team 碰到照片 Orientation 問題就稍微研究一下，舉個例來說，跨年時常看到有人用手機拍下 101 煙火影片，結果擺到電腦上要觀看時，頭則要旋轉 90 度才可以看 Orz

關於照片部分，在 JPEG 裡頭有 Exif Orientation Tag 資訊可以查看，簡易地用 iPad 2 with iOS 6.1.2 ，分別轉動 90 度拍下四張照片，並利用網路資源 jpegexiforient.c 查看：

$ mkdir ~/tmp 
$ wget http://sylvana.net/jpegcrop/jpegexiforient.c -O ~/tmp/jpegexiforient.c
$ cd ~/tmp
$ gcc jpegexiforient.c

$ find /path/photo -name "*.JPG" | -exec ~/tmp/a.out {} \;
3
8
6
1

由此 jpegexiforient.c 可知：

 * Value | 0th Row     | 0th Column
 * ------+-------------+-----------
 *   1   | top         | left side
 *   2   | top         | right side
 *   3   | bottom      | right side
 *   4   | bottom      | left side
 *   5   | left side   | top
 *   6   | right side  | top
 *   7   | right side  | bottom
 *   8   | left side   | bottom

至於解法嘛，有的是靠 Photo Reader 處理，例如在 Windows 8 顯示仍一切正常，但有的沒處理時，顯示則會出錯，故最後手段就是用程式處理一下，給它轉個 90度、180度、270度吧！產生照片的過程說誰錯也不對，只能說對使用者不方便就是程式設計師的錯吧 XD

[Linux] 確認 Tools 和 Shared Library 的 CPU 架構 @ Ubuntu 12.04

最近在移植一些工具，需要確認編譯出來的程式跟函式庫是不是板子可跑的，或是碰到程式不能跑時，該怎樣確認。

這時就可以用簡易的 file 指令來驗證：

$ file spawn-fcgi
spawn-fcgi: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.27, stripped

$ file lib/libjpeg.so.62
lib/libjpeg.so.62: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, stripped

驗證所需函式庫(有些 shared object 還會再 link 其他 shared objects)：

$ armv6-linux-gnueabi-readelf -a bin/spawn-fcgi | grep Shared
0x00000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x00000001 (NEEDED) Shared library: [libc.so.6]

$ armv6-linux-gnueabi-readelf -a lib/libjpeg.so.62 | grep Shared
Type: DYN (Shared object file)
0x00000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x00000001 (NEEDED) Shared library: [libc.so.6]

有時雖然已經是 ARM 架構，但丟上去就是不能跑，顯示 format 錯誤的訊息，這時有可能是板子雖然是 ARM 架構，但是 CPU 指令集不支援，例如在 ARMv6 的板子執行 ARMv7 編譯出來的程式，此時就需要判斷程式或函式庫是用哪個 compiler 編的：

$ armv6-linux-gnueabi-readelf -a modules/fuse.ko | grep -i CPU
Tag_CPU_name: "6"
Tag_CPU_arch: v6

 

把玩 TideSDK - 跨 PC 平台的 Desktop App 整合方案(HTML5/CSS3/JS + PHP/Python/Ruby)

最近有打算做 pc app ，想說一口氣做一個跨平台的程式，在找資料的過程中，除了 QT 方案外，被 TideSDK 吸引到！簡單說，若曾聽過 PhoneGap 的話，那對於 TideSDK 就不會陌生，皆是一樣的架構：

Plaftform framework (Support Ruby/Python/PHP) + Browser + HTML5  

接著還能幫你打包成個平台的安裝程式！真是佛心來的 Open Source 啦！操作上需下載 TideSDK 和 TideSDK Developer 套件，將 SDK 依系統擺在指定的位置上即可，更多細節請參考官方教學文件，本次在 Mac 10.8.2 跟 Windows 8 測試。

直接說測試結果好了...嗯...跨平台的事沒那麼簡單，光要跨平台就會面臨 browser rendering engine 的問題，所以我測試的結果是光 mac 跟 windows 的 TideSDK-Webkit 行為就不一樣 :P 簡單的說，原本的概念想說從 IE/Chrome/Firefox 多種瀏覽器支援，降到至少只要維護 TideSDK-Webkit 一個版本就好，用了之後反而變成要多支援數個瀏覽器版本(TideSDK-Webkit @ Windows, TideSDK-Webkit @ Mac)，故：

！！平台不是這麼容易跨的！！

所幸的，逛了一下 TideSDK API 中，有看到開啟系統內建瀏覽器的用法，或許急用的話就用這招吧！

Ti.Platform.openURL : Open the given URL in the system's default browser. ...

除此之外，這還是挺不錯的！還可以用 PHP/Ruby/Python 唷！

更換 ACER 筆電鍵盤

這是一台 2009 年購買的 ACER 的筆電，但其實購買沒半年，鍵盤就開始出現某些按鍵無效(6,8,9鍵)，除了人在外地很懶得去更換外，另一個主因是時好時壞，有時要 demo 給別人看也不見得好 demo ，就這樣撐到了 2013 年，基本上已經邁入完全外接鍵盤的用法了。在上個週末閒來無事順便找一下如何拆鍵盤，就默默地學會拆鍵盤，接著去露天找筆電型號，又找到還有人在賣這型號鍵盤，就賭了一把給它下標了！

幸運地，一切正如所料，換了鍵盤就好了 :P 再也不用外接鍵盤啦！不過當初拆建盤的主因是有人說只要重接鍵盤說不定會好，但此例是仍不ok啦，且事實上也有可能是內部接頭的問題，故沒拿去給別人檢驗而自己買零件來換是有風險的，需自己評估勇氣 XD

 

這台筆電分別在 ESC, F4, F8, F12, Del 上有個卡榫，往邊框(往螢幕那個方向)壓後就可以慢慢把鍵盤拆掉

anyway, 這台筆電又重生了！外加再找拆卸的工具時，發現之前有兩條替換 MBP 的記憶體默默地被收藏著，於是順手又把這台筆電升到 4GB 囉！還是要提一下，若保固內還是趕緊拿去換修，之前查文章的結果，給原廠修似乎要價 2500 元！真的不便宜，這次買露天的(可能是副廠做的)，含運花費不用 550 元，所以才賭了一把 :)