make an option to compile libraries statically

[blshkv]

there is an issue with bettercap (its binary distribution) and an author decided to fork gopacket in order to compile it with libraries (libpcap in particular) statically.

Perhaps, you could make this option here instead.

For more details, see the following discussion:
bettercap/bettercap#101

[evilsocket]

Super interested in having this as a compilation option so I can drop my fork and keep using the main one ^_^

[negbie]

Why not simply use musl?

// Make a static 64 bit binary:

docker run --rm=true -itv $PWD:/mnt alpine:3.7 /mnt/build_static.sh

// Make a static 32 bit binary:

docker run --rm=true -itv $PWD:/mnt i386/alpine:3.7 /mnt/build_static.sh

set -ex

apk update

apk add linux-headers musl-dev gcc go libpcap-dev ca-certificates git

mkdir /go

export GOPATH=/go

mkdir -p /go/src/github.com/yourrepo

mkdir -p /mnt/out

cp -a /mnt /go/src/github.com/yourrepo/yourtool

cd /go/src/github.com/yourrepo/yourtool

rm -f yourtool*

go get -v ./ ./

go build --ldflags '-linkmode external -extldflags "-static -s -w"' -v ./

cp ./yourtool /mnt/out/

[evilsocket]

@negbie maybe I'm mistaken here, but the problem is not how we build our tool, but how gopacket is built. Given there're no conditional compilation flags (that I'm aware of), the only way to have a static build is to patch pcap/pcap.go cgo directives. I can trigger a static build for my tool, but regardless gopacket will link libpcap.so instead of libpcap.a.

[negbie]

Hmm ok I thought you just want a binary without external deps(empty ldd output). So that the user doesn't need libpcap installed.

[evilsocket]

@negbie yes that is the idea ... I'm not familiar enough with Docker so i'm afraid your instructions are not very clear to me then :) For instance, where does the build_static.sh come from?

[evilsocket]

@negbie dude you saved my day!

[negbie]

Mby I should provide a better explanation. The key here isn't the use of docker, its to circumvent the lack of glibc's static linking by using musl which comes out of the box in alpine linux. So the quickest way is to use the docker alpine container and install there some stuff we need for the static linking. So create a bash script build_static.sh with:

#!/bin/sh
set -ex
apk update
apk add linux-headers musl-dev gcc go libpcap-dev ca-certificates git

mkdir /go
export GOPATH=/go
mkdir -p /go/src/github.com/yourrepo
mkdir -p /mnt/out
cp -a /mnt /go/src/github.com/yourrepo/yourtool
cd /go/src/github.com/yourrepo/yourtool
rm -f yourtool*
go get -v ./ ./
go build --ldflags '-linkmode external -extldflags "-static -s -w"' -v ./
cp ./yourtool /mnt/out/

Inside the same folder run
docker run --rm=true -itv $PWD:/mnt alpine:3.7 /mnt/build_static.sh
This will give you a static binary inside the out folder

[blshkv]

@evilsocket so can close the bug? It looks like you can compile it in and this is an alternative solution

[evilsocket]

@blshkv Right now I'm using this ... the method mentioned by @negbie doesn't work for every OS as you can see on the build.sh script, but I guess that's not related to this issue. We dropped our fork of gopacket for the time being ... so I guess, yes? ( Needless to say, any suggestion on how to improve that build.sh is more than welcome :P)

[blshkv]

Ok, great! I don't have much time but was happy to help a bit. Thank you all for your work!

[blshkv]

Guys, I have a question. The latest version of bettercap (v2.2) is compiled statically and depends on libpcap for some reason. I actually expected to have an option to compile gopacket with shared libraries (libpcap and pfring) so that bettercap won't require either of them.

Is any way to archive this, similar to the usual C programs?

[evilsocket]

@blshkv no, 2.2 is not compiled statically on every platform, linux/amd64 build is not static for instance and will require libpcap.so to be present in the system.

[blshkv]

sorry, I wasn't clear. bettercap is compiled with gopacket and the outcome is one big binary.
But I'm new to Go and did not realised that this is a language limitation.

Here is the background. At pentoo, we create ebuilds which should list down dependency. I have created a separate ebuild for gopacket which depends on libpcap (and pf_ring optionally). However, it was flagged that bettercap should also depend on libpcap since its binary requires it.

I guess there is nothing we can do here.