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