最近將自己開發的sip協議棧移植到arm晶元下的嵌入式linux，遇到乙個奇怪問題，這篇小文簡要記錄解決過程。
相同的**在windows下、centos linux下都正常，交叉編譯到arm晶元的64位linux下總是崩潰，估計堆疊、記憶體被破壞，用valgrind沒辦法定位到具體的出錯位置。經過多次用最原始的printf()跟蹤，發現和md5加密函式有關，篩查了**死活也沒發現錯誤。如此折騰了將近一周，神經高度緊張。
後來仔細分析相關的源**，終於發現問題所在。
協議棧用到乙個md5的函式庫，這個庫比較古老，dos時代就存在。其中的標頭檔案md5.h有問題：
#ifdef __alpha
typedef unsigned int uint32;
#else
typedef unsigned long uint32;
#endif
dos時代（或windows nt 3.1時代），alpha晶元是32位的，因此定義乙個32位無符號整數，用unsigned int，而intel的286之類的晶元int型別是16位的，所以32位無符號整數需定義為unsigned long。
到了現在的64位時代，這些就有問題了。
在windows下：int - 4位元組32位，long - 4位元組32位，long long - 8位元組64位
在linux下：int - 4位元組32位，long - 8位元組64位，long long - 8位元組64位
上述定義，非_alpha，32位無符號整數被定義為typedef unsigned long uint32，在windows下沒問題，在linux下是有問題的，實際上成了64位。很多因此定義的緩衝區，在操作時就可能出錯。
也許會問，同樣linux，為何centos下沒問題呢？那是因為intel和arm晶元的記憶體布局不一樣，arm會立即暴露而已。
後來將上述定義統一改為（反正不可能16位時代了）：
typedef unsigned int uint32;
重新編譯後，程式就非常穩定了。
移植pjsip到嵌入式linux下多dsp埠問題
想把pjsip移植到嵌入式linux下，該裝置有多個fxs fxo埠，每個埠對應乙個dsp通道。pjsip目前只是對音效卡類裝置進行支援，實現的pjsua也僅僅對乙個音效卡裝置支援，並不支援多埠。在移植中，可以考慮如下方法 1 把每個fxs fxo埠對應的dsp通道適配成乙個音效卡裝置，對pjsua...
ubuntu移植到嵌入式平台
ubuntu乙個以桌面應用為主的開源gnu linux作業系統。ubuntu 用在pc的intel框架，我們比較熟悉，ubuntu 在arm平台下執行，可能比較陌生。以下我們介紹ubuntu 14.04 到dlt rk3288 arm平台上。使用到的硬體平台 dlt rk3288 補充說明 雖然dl...
libcurl移植到嵌入式ARM
curl 庫的主要功能是用不同的協議連線不同的伺服器，也就是相當封裝了的 socket 的協議庫，libcurl 當前支援 等常用協議，libcurl 也支援https 證書授權，是網路程式開發的一把利器。unzip curl curl 7 50 0.zip 也可以把目錄名字修改為libcurl m...