How to build mongo-tools from source code?

[satya_dommeti]

Hi,

I am trying to build mongo-tools from source code. I got errors regarding golang settings

cd /opt/mongo-tools-r4.2.3
sudo ./build.sh
Current path ‘/opt/mongo-tools-r4.2.3’ doesn’t resemble a GOPATH-style path. Aborting.

$which go
/usr/bin/go

$go env
GOARCH=“amd64”
GOBIN=""
GOEXE=""
GOHOSTARCH=“amd64”
GOHOSTOS=“linux”
GOOS=“linux”
GOPATH="/usr/bin/go"
GORACE=""
GOROOT="/usr/lib/golang"
GOTOOLDIR="/usr/lib/golang/pkg/tool/linux_amd64"
GCCGO="/usr/bin/gccgo"
CC=“gcc”
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build916680123=/tmp/go-build -gno-record-gcc-switches"
CXX=“g++”
CGO_ENABLED=“1”
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG=“pkg-config”

Thanks,
Satya

[Tim_Fogarty]

Hi Satya,

The tools need to be placed inside your Go workspace. The go workspace is a directory with a specific structure where Go expects you to put your source code. $GOPATH should point to this workspace directory, not to the Go binary. You can read more about $GOPATH here: https://golang.org/cmd/go/#hdr-GOPATH_environment_variable

People usually set $GOPATH to $HOME/go. Then you must clone the tools into $GOPATH/src/github.com/mongodb/mongo-tools.

These are all Go conventions. We’re working on updating the readme to make this a bit clearer. We’ll also soon be migrating to go modules, which will allow you to keep the tools source code outside of the Go workspace if you wish.

[Tim_Fogarty]

By the way, is there a particular reason you’re building the tools yourself rather than downloading the pre-built binaries? I work on the tools, so I’m always interested in learning more about how people are using the tools.

[satya_dommeti]

Hi Tim,

Thank you for your reply. Its working fine

But I am getting the below error when I run build.sh
$ sudo ./build.sh
Building bsondump…
import cycle not allowed
package main
imports github.com/mongodb/mongo-tools-common/log
imports fmt
imports errors
imports runtime
imports runtime/internal/atomic
imports unsafe
imports runtime
import cycle not allowed
package main
imports github.com/mongodb/mongo-tools-common/signals
imports github.com/mongodb/mongo-tools-common/util
imports go.mongodb.org/mongo-driver/mongo
imports crypto/tls
imports crypto/x509
imports net
imports runtime/cgo
imports runtime/cgo
Error building bsondump

Mongo tools are placed in below path
/home/mongoadm/go/src/github.com/mongodb/mongo-tools

GOPATH="/home/mongoadm/go"

Please help me in this regard.

Regards,
Satya

[satya_dommeti]

Hi Tim,

We are building tools for security purposes and client wants to use source version in production.

Please let me know if there is any issues with source code.

Regards,
Satya

[satya_dommeti]

Hi Tim,

I could able to build mongo tools successfully after upgrade go version go1.14.4. Thank you.

Download the Go archive and extract it into /usr/local , creating a Go tree in /usr/local/go
Reference : https://golang.org/doc/install

Set GOROOT to Go root directory and GOPATH to work space directory.
$GOROOT="/usr/local/go"
$GOPATH="$HOME/go"

Add /usr/local/go/bin to the PATH environment variable
$export PATH=/usr/local/go/bin:$PATH

Run build.sh
$ sudo ./build.sh

Regards,
Satya

[Tim_Fogarty]

Hi Satya,

Great to hear it’s working! Thanks for the info on your use case. Just make sure to always build from a version tag (e.g. git checkout 100.0.2). The master branch is unstable and could break at any time, but the version tags will always be stable.

[Stennie]

@satya_dommeti

We are building tools for security purposes and client wants to use source version in production.

Please let me know if there is any issues with source code.

Hi @satya_dommeti,

You mentioned a similar requirement for building the server from source. I will reiterate my comment on that discussion since it also applies here:

@Stennie

I noticed you are building MongoDB 4.2.3. The latest 4.2 release is currently 4.2.8 (see MongoDB 4.2 Minor Releases). I strongly recommend staying current with minor releases for the latest security and stability fixes.

If your client is concerned about security and stability, the official packages should provide more assurance on that front than building from source. All builds are extensively tested via our public (and open source) Evergreen CI and published packages are signed for verification.

If you build from source, there may be variations in your build environment that cause unexpected issues.

It is fine if you prefer to build from source, but typically the motivation for doing so would be to make alterations or build for an unsupported platform. If security is a key concern, you should also keep up with the latest minor releases.

Regards,
Stennie