交叉編譯es前端

⑴ 如何判斷提取出的ES流是真正的裸流

這個問題已經解決了！首先說一下，我提取出來的流不知道是不是完整的ES流，也即所謂的標准裸流，因為當時用VLC播放不了，所以我自己也不敢確定，怕自己提取的數據不完整什麼的。除了版主提供的播放工具，再告訴大家一個方法，那就是用vlc-0.8.6i-win32這個版本的VLC，如果可以播放，就是純正的裸流！注意，最新版本的VLC是不能播放264文件的！

⑵ 前端好還是後端

前後端應該都挺有發展前景，相對來說前端會比較簡單一點。但是現在對於同個層次的人，一般公司前後端待遇都差不多，待遇好的肯定是你技術過硬的。那就要看自己的愛好了。以下是web前端開發和java後端開發兩者的分析。

具體步驟

• 首先說JAVA，JAVA是作為後端開發的。現在後端開發主要是PHP和JAVA，當然還要加上資料庫MySQL、Oracle。PHP比較適合交互比較少的後端，適合小規模的應用。JAVA做後端安全性、穩定性都較好，所以大、中企業用JAVA開發。當然後端開發還有C++等語言，C++的特點是開發快、成本低，一些手機游戲就用C++作為後端語言。

• Web前端主要用的語言是Html5、CSS3、JavaScript，還要加上AJAX。前端開發還有什麼前端呢？移動應用(APP)前端。2015年之前，開發APP的前端，要用android和IOS，而且還必須分別開發。

• 2015年開始，興起了APP前端統一開發，比如MUI框架、react native。這兩種開發我都涉及到，原生android我也做過幾款APP。MUI開發用的就是Web前端的那一套東西，只不過封裝了很多的類。react native開發模仿的就是Web前端開發，用的語言是ES5，ES6。你網路上查一查就知道ES跟JS其實沒啥區別。

• 所以，要說哪個有前途。真不好說，因為這兩個技術就是相輔相成的。現在學前端就是從 Web前端開始。但是對於個人來說，從事前端或者後端還是有區別的。前端開發，對於有美術功底的人是有優勢的，後端開發適合編程技術功底扎實的人。

⑶ 前端是啥呢

前端即網站前台部分，運行在PC端，移動端等瀏覽器上展現給用戶瀏覽的網頁。簡單地說，能夠從 App 屏幕和瀏覽器上看到的東西都屬於前端。前端技術一般分為前端設計和前端開發，前端設計一般可以理解為網站的視覺設計，前端開發則是網站的前台代碼實現，包括基本的HTML和CSS以及JavaScript/ajax，最新的高級版本HTML5、CSS3，以及SVG等。

⑷ 前端構建工具Gulp.js 你知多少..(webpack/gulp/grunt)

@ TOC

閱讀本文章之前，相信你已經對前端構建工具(webpack、gulp、grunt)有一定的認知和了解了，那麼他們之間究竟有什麼區別呢？

gulp文檔上面有這么一句話 ，也就是說 gulp是一個自動化構建工具；
gulp的一些功能如下(包括但不限於):

其實Webpack和另外兩個並沒有太多的可比性

傻瓜式起步照搬官網文檔
1.安裝

2.在項目根目錄下創建一個名為 gulpfile.js 的文件：

3.運行 gulp：

默認的名為 default 的任務（task）將會被運行，在這里，這個任務並未做任何事情。
具體詳情可以查看 gulpjs.com文檔

新建一個項目gulp-test
環境:

1.新建文件以下文件如下

其中 gulpfile.js 是我們gulp的配置文件，啟動gulp默認會找個這個文件並執行；
2.接下來安裝依賴

一直按回車Enter初始化package.json文件(小技巧: npm iniy -y 可以免去繁瑣的enter步驟)
此時我們的目錄結構是這樣了

安裝依賴

這里頁面實時刷新只講這個 gulp-connect ，其他詳情可以參照 Browsersync 和文章 gulp-livereload

安裝完依賴後配置gulpfile.js如下:

大概講解一下gulpfile.js:

gulp.task 是gulp的api 定義一個使用 Orchestrator 實現的任務（task）
如上我們定義了 my-task-js ， my-task-css ， html ， clean ， default ， watch ， server 等任務，其中:

my-task-js 是將 符合所提供的匹配模式的js 進行檢測(gulp-jshint)、壓縮(gulp-uglify)、合並(gulp-concat)、重命名(gulp-rename)、輸出(gulp.dest)到/dist/js目錄下；

my-task-css 是將 符合所提供的匹配模式的sass進行編譯(gulp-sass)、壓縮(gulp-uglify)、合並(gulp-concat)、重命名(gulp-rename)、輸出(gulp.dest)到/dist/css目錄下；

html 是將 符合所提供的匹配模式的html進行監聽，如果有變化則connect.reload()

clean 是如果任務重新啟動時 刪除舊文件；

default gulp默認啟動的任務

watch gulp的api 監視文件，並且可以在文件發生改動時候做一些事情。它總會返回一個 EventEmitter 來發射（emit） change 事件。

server 依賴gulp-connect啟動一個伺服器

配置完gulpfile.js之後，我們給js和css及html加點東西:

首先js/helloworld.js

css/index.scss

index.html

運行gulp

瀏覽器效果:

接下來我們修改helloworld.js來看看是否能實時刷新
修改如下:

按保存之後，終端給我們報了一個錯:

查看js發現我們用了es6語法的聲明語句 但當前gulp無法處理es6語法，有問題解決問題，es6=>es5

解決方案:
安裝gulp-babel babel-core babel-preset-es2015

gulpfile.js修改如下:

運行

依然報上面的錯；找了一些原因發現，雖然安裝了相關依賴，卻沒有配置.babelrc文件，即babel還沒轉化es6

根目錄添加.babelrc文件

重新運行:

查看dist下的js文件

改變helloworld.js檢查頁面是否刷新

保存，頁面的天空藍換成你們喜歡的yellow顏色

修改index.scss 查看是否會刷新頁面

最後修改index.html 查看是否會刷新頁面

今天主要學習了gulp的簡單項目搭建及實時更新配置；其實gulp類似於grunt的弱化版，但更簡單好用，只是插件會少一些，目前主流的項目搭建工具主要是webpack，但依然有不少項目還用著gulp或者grunt

擴展:

下面還有一些樓主的學習筆記:

有興趣的可以多多交流@ 樓主博客

⑸ 前端面試計劃（二）ES6「v2-附加代碼」

## 01. 你能說說ES6有哪些內容嗎？

- let、const- 模板字元串- 解構賦值- 擴展運算符- 字元串的擴展方法(includes, startsWith, endsWith, padStart, padEnd, repeat, replaceAll, trimStart, trimEnd...)- 數組的擴展方法(includes, isArray, from, fill, find, findIndex...)- 箭頭函數- 函數的rest參數，函數參數的默認值- Symbol- Reflect- Proxy- Promise- Generator- Map- WeakMap- Set- WeakSet- class- import & export- ...

### Symbol
- Symbol 除了表示獨一無二的值- 還具有元編程的能力，比如我們手寫 Promise 的時候，如果不定義 Symbol.toStringTag 為 Symbol，那麼通過 Object.prototype.toString.call 得到的結果就是 [object Object]- 還可以用於判斷某對象是否為某構造器的實例 Symbol.hasInstance，很多人手寫 instanceof 的時候都是通過 __proto__ 的方式，這在 ES5 是沒問題的，然而在 ES6 是通過 Symbol.hasInstance

### Reflect
Reflect 將對象的操作集中起來，可以通過 Reflect. 的方式來使用，比如：- Reflect.ownKeys 可以獲取對象的普通屬性和Symbol類型的屬性，如果不使用 Reflect.ownKeys() ，就要使用 Object.keys() 和 Object.getOwnPropertySymbols 將獲取到的普通類型的屬性和 Symbol 類型的屬性拼接起來- Reflect.has 可以判斷一個對象是否存在某個屬性，如果不用 Reflect.has 就要使用 key in object

## 02. 箭頭函數和普通函數有什麼區別呢？
1. 箭頭函數沒有自己獨立的作用域，即它的 this 指向它定義時的作用域2. 箭頭函數沒有 prototype 屬性3. 箭頭函數沒有 arguments 和 caller4. 箭頭函數不能作為構造函數

## 03. Map 和 WeakMap (Set 和 WeakSet) 的區別？
- WeakMap 的 key 只能是對象- WeakMap 沒有 size 屬性，沒有 clear 方法，不支持遍歷- WeakMap 是弱引用

## 04. 各種模塊化規范的細節
- CommonJs
CommonJS 主要是 Node.js 使用，通過 require `同步載入`模塊，exports 導出內容。在 CommonJS 規范下，每一個 JS 文件都是獨立的模塊，每個模塊都有獨立的作用域，模塊里的本地變數都是私有的
- AMD(Asynchronous Mole Definition)
AMD，即非同步模塊定義。AMD定義了一套JavaScript模塊依賴非同步載入標准，用來解決瀏覽器端模塊載入的問題。AMD主要是瀏覽器端使用，通過 define 定義模塊和依賴，require 非同步載入模塊，推崇依賴前置
- CMD(Common Mole Definition)
CMD，即通用模塊定義。CMD定義了一套JavaScript模塊依賴非同步載入標准，用來解決瀏覽器端模塊架子啊的問題。CMD主要是瀏覽器端使用，通過 define 定義模塊和依賴，require 非同步載入模塊，推崇依賴就近
- UMD(Universal Mole Definition)
UMD，即通用模塊定義。UMD主要為了解決 CommonJS 和 AMD 規范下的代碼不通用的問題，同時還支持將模塊掛載到全局，是跨平台的解決方案
- ESM(ECMAScript Mole)
ESM，即ESMole。官方模塊化規范，現代瀏覽器支持，通過 import 載入模塊，export 導出內容

⑹ web前端es是什麼意思

es就是ECMA是European Computer Manufacturers Association的縮寫，即歐洲計算機製造商協會。歐洲計算機製造商協會是制定信息傳輸與通訊的國際化標准組織。

ECMAScript是ECMA制定的標准化腳本語言。

目前JavaScript使用的ECMAScript版本為ECMAScript-262。

ECMAScript被國際化標准組織採納為ISO/IEC 16262。

⑺ 進行OPENGL | ES移植到開發板上，使用軟體包PicoGL，最終編譯完的程序在開發板上運行出錯

換上對應的交叉編譯工具，重新編譯lib庫。

⑻ 快畢業了，很多人都不推薦做前端，前端業內最真實情況是什麼樣的

一、從個人發展角度——前端是個比較「難積累經驗」的領域

如何判斷一個行業對個人發展是否有利？

最簡單的就是從身邊的人做對比，隨著時間的積累，個人發展能否得到提升，讓我覺得不安的是，一個工作了五年的騰訊前端工程師，跟工作兩年的前端工程師，卻很難有技術能力上的差異。

前端變化快，新技術新概念多，但也代表前端技術不穩定。這也是為什麼知乎上的前端普遍都很「焦慮」。每次問及前端，都必須聲明自己碾壓活在底層的「切圖仔」。

二、行業壁壘——對於普通人來說，前端天花板不高

很多人說現在的前端已經模塊化，工具化，規范化了，有Webpack、Parcel、Eslint、React、Vue、Angular、PWA、Puppeteer、Electron各種技術等等，前端已經是一個非常工程化的東西了，區別於用jQuery的切圖仔了！所以前端特別有競爭力！還有其他答主說前端入門很難，高級就不容易了！

其實前端還是一個相對比較新的行業，互聯網發展早期（1995年~2005年）是沒有專業的前端工程師的。隨著互聯網的發展，到了2010年，互聯網開始全面進入移動時代，前端工程師的地位越來越重要。而前端的前景也十分的好。

前端薪資：有越來越高的趨勢

前端開發依舊是剛需，所以你想要做web前端，是完全可以的，以上的回答給你參考

⑼ cygwin 中如何安裝arm-linux-gcc交叉編譯器

交叉編譯工具鏈作為嵌入式Linux開發的基礎，直接影響到嵌入式開發的項目進度和完成質量。由於目前大多數開發人員使用Windows作為嵌入式開發的宿主機，在Windows中通過安裝VMware等虛擬機軟體來進行嵌入式Linux開發，這樣對宿主機的性能要求極高。Cygwin直接作為Windows下的軟體完全能滿足嵌入式Linux的開發工作，對硬體的要求低及方便快捷的特點成為嵌入式開發的最佳選擇。

目前網路上Cygwin下直接可用的交叉編譯器寥寥無幾且版本都比較低，不能滿足開源軟體對編譯器版本依賴性的要求(如低版本工具鏈編譯U-Boot出現軟浮點問題等);Crosstool等交叉工具鏈製作工具也是更新跟不上自由軟體版本的進度;同時系統介紹Cygwin下製作交叉編譯器方面的資料很少。針對上述情況，基於最新版gcc等自由軟體構建Cygwin下的交叉編譯器顯得尤為迫切和重要。
構建前准備工作
首先Cygwin下必須保證基本工具比如make}gcc等來構建bootstrap-gcc編譯器，這可以在安裝Cygwin時選擇安裝。參照gcc等安裝說明文檔來在Cygwin下查看是否已經安裝，如輸入gcc --v等。
源碼下載
gcc-4.5.0的編譯需mpc的支持，而mpc又依賴gmp和mpfr庫。從各個項目官方網站上下載的最新的源碼:
binutils-2.20. l .tar.bz2
gmp-S.O. l .tar.bz2
mpc-0.8.2.tar.gz
mpfr-3.O.O.tar.bz2
gcc-4.S.O.tar.bz2
linux-2.6.34.tar.bz2
glibc-2.11.2.tar.bz2
glibc-ports-2. l l .tar.bz2
gdb-7. l.tar.bz2

設置環境變數
HOST:工具鏈要運行的目標機器;BUILD:用來建立工具鏈的機器;TARGET工具鏈編譯產生的二進制代碼可以運行的機器。
BUILD=i686-pc-cygwin
HOST=i686-pc-cygwin TARGET=arm-linux
SYSROOT指定根目錄，$PREFIX指定安裝目錄。目標系統的頭文件、庫文件、運行時對象都將被限定在其中，這在交叉編譯中有時很重要，可以防止使用宿主機的頭文件和庫文件。本文首選$SYSROOT為安裝目錄，$PREFIX主要作為glibc庫安裝目錄。
SYSROOT=/cross-root
PREFIX=/cross-root/arm-linux
由於GCC-4.5.0需要mpfr,gmp,mpc的支持，而這三個庫又不需要交叉編譯，僅僅是在編譯交叉編譯鏈時使用，所以放在一個臨時的目錄。
TEMP_PREFIX=/build-temp
控制某些程序的本地化的環境變數:
LC ALL=POSIX
設置環境變數:
PATH=$SYSROOT/bin:兒in:/usr/bin
設置編譯時的線程數f31減少編譯時間:
PROCS=2
定義各個軟體版本:
BINUTILS V=2.20.1
GCC V=4.5.0
GMP V=5.0.1
MPFR V=3.0.0
MPC V二0.8.2
LINUX V二2.6.34
GLIBC V=2.11.2
GLIBC-PORTS V=2.11
GDB V=7.1
構建過程詳解
鑒於手工編譯費時費力，統一把構建過程寫到Makefile腳本文件中，把其同源碼包放在同一目錄下，執行make或順次執行每個命令即可進行無人值守的編譯安裝交叉工具
鏈。以下主要以Makefile執行過程為主線進行講解。
執行「make」命令實現全速運行
可在Cygwin的Shell環境下執行「make>make.log 2>&1」命令把編譯過程及出現的錯誤都輸出到make.log中，便於查找:
all:prerequest install-deps install-cross-stage-one install-
cross-stage-two
預處理操作
"make prerequest'，命令實現單步執行的第一步，實現輸出變數、建立目錄及解壓源碼包等操作。0'set十h」關閉bash的Hash功能，使要運行程序的時候，shell將總是搜索PATH里的目錄[4]。這樣新工具一旦編譯好，shell就可以在$(SYSROOT)/bin目錄里找到: prerequest:
set +h&&mkdir -p $(SYSROOT)/bin&&
mkdir -p $(PREFIX)/include&&
mkdir -p $(TEMP一REFIX)&&
export PATH LCes ALL&&
tar -xvf gmp-$(GMP_V).tar.bz2&&
tar -xvf mpfr-$(MPFR_V).tar.bz2&&
tar -xvf mpc-$(MPC_V).tar.gz&&
tar -xvf binutils-$(BINUTILS_V).tar.bz2&&
tar -xvf gcc-$(GCC_V).tar.bz2&&
tar -xvf linux-$(LINUX_V).tar.bz2&&
tar -xvf glibc-$(GLIBC_V).tar.bz2&&
tar -xvf glibc-ports-$(GLIBC-PORTS_V).tar.bz2&&
my glibc-ports-$(GLIBC-PORTS_V)
glibc-$(GLIBC_V)/ports&&
tar -xvf gdb-$(GDB V).tar.bz2
非交叉編譯安裝gcc支持包mpc
00make install-deps」命令實現單步執行的第二步，實現mpc本地編譯，mpc依賴於gmp和mpfr
install-deps:gmp mpfr mpc
gmp:gmp-$(GMP_V)
mkdir -p build/gmp&&cd build/gmp&&
../../gmp-*/configure
--disable-shared --prefix=$(TEMP_PREFIX)&&
$(MAKE)一$(PROCS)&&$(MAKE) install
mpfr:mpfr-$(MPFR_V)
mkdir -p b-uild/mpfr&&cd build/mpfr&&
../..//mpfr-*/configure
LDF'LAGS="-Wl,-search_paths_first」--disable-shared
--with-gmp=$(TEMP_PREFIX)
--prefix=$(TEMP_PREFIX)&&
$(MAKE)一$(PROCS) all&&$(MAKE) install
mpc: mpc-$(MPC_V) gmp mpfr
mkdir -p build/mpc&&cd build/mpc&&
../../mpc-*/configure
--with-mpfr=$(TEMP PREFIX)
--with-gmp=$(TEMP_PREFIX)
--prefix=$(TEMP_PREFIX)&&
$(MAKE)一$(PROCS)&&$(MAKE) install
交叉編譯第一階段
"make install-cross-stage-one'，命令實現單步執行的第三步，編譯安裝binutils,bootstrap-gcc和獲取Linux內核頭文件:
install-cross-stage-one:cross-binutils cross-gcc get-kernel-headers
編譯安裝binutils
cross-binutils: binutils-$(BINUTILS_ V)
mkdir -p build/binutils&&cd build/binutils&&
../..//binutils-*/configure --prefix=$(SYSROOT)
--target=$(TARGET)--disable-nls&&
$(MAKE)j$(PROCS)&&$(MAKE) install
編譯安裝bootstrap-gcc。使用一disable-shared參數的意思是不編譯和安裝libgcc_ eh.a文件。glibc軟體包依賴這個庫，因為它使用其內部的一lgcc_eh來創建系統[6]。這種依賴
性，可通過建立一個指向libgcc.a符號鏈接得到滿足，因為該文件最終將含有通常在libgcc- eh.a中的對象(也可通過補丁文件實現)。
cross-gcc:gcc-$(GCC_V)
mkdir -p build/gcc&&cd build/gcc&&
二//gcc-*/configure
--target=$(TARGET)--prefix=$(SYSROOT)
--disable-nls --disable-shared --disable-multilib
--disable-decimal-float--disable-threads
--disable-libmudflap --disable-libssp
--disable-libgomp --enable-languages=c
--with-gmp=$(TEMP_PREFIX)
--with-mpfr=$(TEMP_PREFIX)
--with-mpc=$(TEMP_PREFIX)&&
$(MAKE) -j$(PROCS)&&$(MAICE) install&&
In -vs libgcc.a'arm-linux-gcc -print-libgcc-file-name I
sed's/libgcc/& eh/'}
獲取Linux內核頭文件:
get-kernel-headersainux-$(LINUX_V)
cd linux-$(LINUX_V)&&
$(MAICE) mrproper&&$(MAKE) headers check&&
$(MAKE) ARCH=arm&&
INSTALLes HDR_ PATH=dest headers_ install&&
find dest/include
(-name .install一。-name ..installNaNd)-delete&&
cp -rv desdinclude/* $(PREFIX)/include
交叉編譯第二階段
編譯安裝glibc、重新編譯安裝binutils、完整編譯安裝gcc和編譯安裝gdb o "make install-cross-stage-two'，命令實現單步執行的第四步: install-cross-stage-two:cross-glibc cross-rebinutils cross-g++ cross-gdb
編譯安裝glibca glib。的安裝路徑特意選為$(PREFIX)，與gcc更好找到動態鏈接庫也有關系，選在$(SYSROOT)提示找不到crti.o; glibc已經不再支持i386; glibc對ARM等的處理器的支持主要通過glibc-ports包來實現;正確認識大小寫敏感(Case Sensitive)和大小寫不敏感(CaseInsensitive)系統，大小寫敏感問題主要影響到glibc，是交叉編譯glibc成功的關鍵:Cygwin幫助手冊中可知Cygwin是默認大小寫不敏感的n}，但是UNIX系統是大小寫敏感的，這也是Cygwin和UNIX類系統的一個區別。通過作者自行參考製作的glibc-2.11.2-cygwin.patch補T使glibc變為Case-Insensitive，此補丁主要是對大小寫敏感問題改名來實現。
交叉編譯過程中安裝的鏈接器，在安裝完Glibc以前都無法使用。也就是說這個配置的forced unwind支持測試會失敗，因為它依賴運行中的鏈接器。設置libc_ cvforced unwind=yes這個選項是為了通知configure支持force-unwind，而不需要進行測試。libc cv_c_cleanup=yes類似的，在configure腳本中使用libc_cv_c cleanup=yes，以便配置成跳過測試而支持C語言清理處理。
cross-glibc:glibc-$(GLIBC_V)
cd glibc-$(GLIBC_V)&&
patch -Np 1 –i...//glibc-2.11.2-cygwin.patch&&
cd..&&mkdir -p build/glibc&&
cd build/glibc&&
echo"libc cv_forcedes unwind=yes">config.cache&&
echo "libc cv_c_cleanup=yes">>config.cache&&
echo "libc cv_arm_tls=yes">>config.cache&&
../../glibc-*/configure --host=$(TARGET)
--build=$(../OneScheme/glibc-2.11.2/scripts/config.guess)
--prefix=$(PREFIX)--disable-profile
--enable-add-ons --enable-kernel=2.6.22.5
--with-headers=$(PREFIX)/include
--cache-file=config.cache&&
$(MAKE)&&$(MAKE) install
重新編譯安裝binutils。編譯之前要調整工具鏈，使其
指向新生成的動態連接器。
調整工具鏈:
SPECS=
'dirname $(arm-linux-gcc -print-libgcc-file-name)'/specs
arm-linux-gcc -mpspecs
sed -e 's@/lib(64)\?/ld@$(PREFTX)&@g' -e ,}/}}*cPP}$/{n;s,$，-isystem $(PREFIX)/include,}"
>$SPECS
echo "New specs file is: $SPECS"
unset SPECS
測試調整後工具鏈:
echo 'main(川』>mmy.c
arm-linux-gcc
-B/cross-root/arm-linux/lib mmy.c
readelf -1 a.out I grep』:/cross-roobarm-linux'
調整正確的輸出結果:
[Requesting program interpreter: /tools/lib/ld-linux.so.2j
一切正確後刪除測試程序:
rm -v mmy.c a.out
重新編譯binutils。指定--host,--build及--target，否則配置不成功，其config.guess識別能力不如gcc做的好。
cross-rebinutils: binutils-$(BINUTILS_V)
mkdir -p build/rebinutils&&
cd build/rebinutils&&CC="$(TARGET)-gcc
-B/cross-roodarm-linux/lib/"&&AR=$(TARGET)-ar&&
RANLIB=$(TARGET)-ranlib&&../..//binutils-*/configure
--host=$(HOST)--build=$(BUILD)--target=$(TARGET)
--prefix=$(SYSROOT)--disable-nls
--with-lib-path=$(PREFIX)/lib&&
$(MAKE)--$(PROCS)&&$(MAKE) install
高於4.3版的gcc把這個編譯當作一個重置的編譯器，並且禁止在被一prefix指定的位置搜索startfiles。因為這次不是重置的編譯器，並且$(SYSROOT)目錄中的startfiles對於創
建一個鏈接到$$(SYSROOT)目錄庫的工作編譯器很重要，所以我們使用下面的補丁，它可以部分還原gcc的老功能tai . patch -Npl –i../gcc-4.5.0-startfiles_fix-l.patch
在正常條件下，運行gcc的fixincludes腳本，是為了修復可能損壞的頭文件。它會把宿主系統中已修復的頭文件安裝到gcc專屬頭文件目錄里，通過執行下面的命令，可以抑
制fixincludes腳本的運行[9](此時目錄為/gcc-4.5.0)。
cp -v gcc/Makefile.in{,.orig}
sed 's@\./fixinc\.sh@-c true@'
gcc/Makefile.in.orig > gcc/Makefile.in
下面更改gcc的默認動態鏈接器的位置，使用已安裝在/cross-root/ann-linux目錄下的鏈接器，這樣確保在gcc真實的編譯過程中使用新的動態鏈接器。即在編譯過程中創建的所有
二進制文件，都會鏈接到新的glibc文件
for file in
$(find gcc/config -name linux64.h-o -name linux.h –o -name sysv4.h)
do cp -uv $file{,.orig}
sed -a 's@/lib(64)?(32)?/Id@/cross-root/arm-linux&@g』-e's@/usr@/cross-rootlarm-linux@g' $file.orig>$file echo『
#undef STANDARD INCLUDE DIR
#define STANDARD_ INCLUDE DIR "/cross-root/arm-linux/include"
#define STANDARD STARTFILE PREFIX 1 "/cross-root/arm-linux/lib"
#define STANDARD_ STARTFILE_ PREFIX_ 2」」』>>$file
touch $file.orig done
完整編譯安裝gcc。最好通過指定--libexecdir更改libexecdir到atm-linux目錄下。--with-local-prefix選項指定gcc本地包含文件的安裝路徑此處設為$$(PREFIX)，安裝後就會在內核頭文件的路徑下。路徑前指定$(Pwd)則以當前路徑為基點，不指定則默認以/home路徑為基點，這點要注意。
cross-g++:gcc-$(GCC-)
mkdir -p build/g十+&&cd build/g++&&
CC="$(TARGET)-gcc AR=$(TARGET)-ar&&
-B/cross-roodarm-linux/lib/"&&
RANLIB=$(TARGET)-ranlib&&
..//gcc-*/configure
--host=$(HOST)--build=$(BUILD)--target=$(TARGET)
--prefix=$(SYSROOT)--with-local-prefix=$(PREFIX)
--enable-clocale=gnu --enable-shared
--enable-threads=posix --enable -cxa_atexit
--enable-languages=c,c++--enable-c99
--enable-long-long --disable-libstdcxx-pch
--disable-libunwind-exceptions
--with-gmp=$(TEMP_PREFIX)
--with-mpfr=$(TEMP_PREFIX)
--with-mpc=$(TEMP_PREFIX)&&
$(MAKE) LD_IBRARY_ATH=
$(pwd)/$(../../gcc-4.5.0/config.guess)/libgcc&&
$(MAKE) install
編譯安裝gdb，至此完成整個工具鏈的製作。
cross-gdb: gdb-$(GDB V)
mkdir -p build/gdb&&cd build/gdb&&
../../gdb-*/configure --prefix=$(SYSROOT)
--target=$(TARGET)--disable-werror&&
$(MAKE)-j$(PROCS)&&$(MAKE) install
「make clean」命令清除編譯生成的文件和創建解壓的文件夾
.PHONY:clean
dean:
rm -fr $(TEMP_PREFIX) build
binutils-$(BINUTIL,S_V) gcc-$(GCC_V)
glibc-$(NEWL.IB_V) gdb-$(GDB_V)
gmp-$(GMP_V) mpc-$(MPC_V) mpfr-$(MPFR_V)
工具鏈測試
命令行中輸入以下內容:
echo 'main(){}』>mmy.c
arm-linux-gcc -o mmy.exe mmy.c
file mmy.exe
運行正常的結果:
mmy.exe: ELF 32-bit LSB executable, ARM, version 1,for GNU/Linux 2.6.22, dynamically linked (uses shared libs),not stripped.

⑽ 利用father build 開發前端組件庫實戰

我們的目標是建立一個前端組建庫, 使用的技術棧是father+docz，同時要支持typescript, 在build出來的es目錄中要能夠生成「.d.ts」後綴的類型聲明文件，因為只有生成類型聲明文件，我們在使用自己開發的組件庫的時候才能獲得更好的開發體驗。

之所以寫下這篇文章，是因為自己在使用father-build建設內部組件庫的過程中，遇到了一些問題且難以找到相關文檔，將自己的經驗總結下來希望看到這篇文章的人能避開這些坑，更加順利地搭建好自己的前端組件庫。

package.json

其中，main指定了入口文件，mole對應es mole的輸出，types對應你的typings文件，這樣在組件在被使用的時候編輯器才能識別出你的組件類型聲明

.fatherrc.js 配置father build打包方式, 具體詳情可以參考 umijs/father

tsconfig.json typescript的配置文件，注意只有declaration設置為true才能生成.d.ts後綴的文件

接下來我們在components目錄創建第一個自己的組件，下面是一個button的例子:

樣式文件可以直接使用less編寫

然後在入口文件index.ts將其導出，暴漏給外部使用。

使用文檔的後綴名為".mdx", 語法與markdown類似，更多詳情參考 docz 的文檔

我們可以執行 yarn start ，來實時查看文檔的效果。

現在命令行執行 yarn build 即可對組件庫進行打包了，注意我們在.fatherrc中配置了esm和cjs兩種打包方式，對應會生成 es 和 lib兩個目錄，其中 esm對應的是 es目錄，cjs對應lib目錄。

正常情況下，在的es和lib目錄下應該已經為我們寫的ts源碼自動生成了「.d.ts」後綴的類型聲明文件，如果沒有生成，請仔細對比.fatherrc.js和tsconfig.json這兩個配置文件，另外還要注意的是，如果我們基於antd封裝業務組件庫的話，不要在組件庫中使用css mole，否則也會造成無法自動產生類型聲明文件的問題。

文章未能詳盡部分，可以參考這個demo的github源碼地址： https://github.com/xitengfei/xui-components , 有問題歡迎批評指正。