Linux具備gcc開發環境離線安裝go版本mysql2markdown

前言

曾經要用工版本的mysql2markdown結果由于不具備go編譯環境，當初使用安裝go和人更新操作半天沒有成功。改成自己寫linuxC的版本的mysql2markdown。最近他們一堆PAAS的k8s的東西。當初flag大言不慚的說不搞go。玩錘子。他們這些開源谷歌對齊了。就重新把go版本的搞一下。由于有一定基礎，就直奔go.mod以及Makefile。

環境

linux已經具備gcc和make的編譯環境，具備解壓tar指令。

我去拉取了go1.4和go1.7的源碼。

mysql的go驅動第三方庫源碼。

mysql2markdown的待編譯項目源碼。

我都是通過一台可以連接配接外網的浏覽器直接浏覽器下載下傳的。

所謂離線并不是石頭生雞蛋。是這裡是用通用的浏覽器http下載下傳。比如不需要在聯網的電腦再額外安裝go了。

安裝步驟

go要用1.7的首先要先安裝go1.4。這是我第一次失敗中已經了解到的go的雞生蛋蛋生雞原理。

go1.4.src.tar.gz 

go1.17.3.src.tar.gz

利用下面指令将會把對應的go目錄解壓到 $HOME/local/go1.4和$HOME/local/go1.17下。

mkdir -p $HOME/local/go1.4
tar -C $HOME/local/go1.4 -xzvf go1.4.src.tar.gz
mkdir -p $HOME/local/go1.17
tar -C $HOME/local/go1.17 -xzvf go1.17.3      

GOROOT_FINAL 表明最終安裝路徑，沒有設定則用預設GOROOT ，源碼編譯時使用的環境變量

#可更新的解壓

#源碼編譯會把GOROOT設定為下面的環境參數

export GOROOT_FINAL=$HOME/local/go1.4/go

cd $HOME/local/go1.4/go/src

./all.bash

export PATH=$HOME/local/go1.4/go/bin:${PATH}

go env 

go version

#需要高版本1.17

export GOROOT_FINAL=$HOME/local/go1.17/go

cd $HOME/local/go1.17/go/src

./all.bash

go env 

go version

#更新後可以設定使用新的重新進入設定PATH

export PATH=$HOME/local/go1.17/go/bin:${PATH}

#區域網路會出現檢測失敗

go test proxy running at GOPROXY=http://127.0.0.1:35237/      

在 go1.12，go釋出了官方的包管理工具 Go Module

Go1.11及以後版本才能使用

go.mod檔案是文本檔案，是可以自己手動編輯的。

Go子產品版本控制的下載下傳檔案及資訊會存儲到GOPATH的pkg/mod檔案夾裡。

熟悉linuxC的可以了解這個指定第三方依賴庫類似支援 -L指定路徑選擇依賴編譯。

go版本的mysql2markdown原始目錄樹結構

Dockerfile

go.mod

go.sum

LICENSE

Makefile

mysql_markdown.go

README.md

在此目錄結構把依賴的mysql驅動解壓

對依賴說明go.mod進行改動

module mysql_markdown



go 1.17





 require(

 github.com/go-sql-driver/mysql v1.5.0

)

 replace github.com/go-sql-driver/mysql => ./github.com/go-sql-driver/mysql      

執行編譯指令

make build-unix      

生成的可執行檔案在release目錄下

附錄

require直接通過github位址和版本号(tag)來下載下傳對應依賴

預設下載下傳最新版本

go.mod

A module is defined by a tree of Go source files with a go.mod file in the tree's root directory. Module source code may be located outside of GOPATH. There are four directives: module, require, replace, exclude

Can I control when go.mod gets updated and when the go tools use the 

network to satisfy dependencies?

By default, a command like go build will reach out to the network as 

needed to satisfy imports.

Some teams will want to disallow the go tooling from touching the 

network at certain points, or will want greater control regarding

 when the go tooling updates go.mod, how dependencies are obtained, 

 and how vendoring is used.

The go tooling provides a fair amount of flexibility to adjust or 

disable these default behaviors, including via -mod=readonly, -mod=vendor, 

GOFLAGS, GOPROXY=off, GOPROXY=file:///filesystem/path, go mod vendor, and