Include 'generator' in binary distributions

[candlerb]

There are convenient binary distributions of snmp_exporter, but these do not contain generator or generator.yml

The documentation says:

Due to the dynamic dependency on NetSNMP, you must build the generator yourself.

However, there are a number of posts 1 2 3 which show how to generate static go binaries.

I was able to build a static generate binary for Linux x86 using go 1.8.3 and:

cd ~/go/src/github.com/prometheus/snmp_exporter/generator
go build -a -ldflags '-extldflags "-static -lcrypto -ldl"'

It is about 10M instead of 6.5M. ldd shows it is not a dynamically linked executable, and ./generator generate runs successfully.

I have not experimented with CGO_ENABLED=0 or tried any other architectures.

(Without the -lcrypto flag there are errors about not being able to find various crypto functions, and if you add only that, it complains about not being able to find various dlopen-type functions)

[SuperQ]

We now have support for extldflags in promu. I've tested this with the latest mater and works well. Once we have a new release of promu, we can do this.

[candlerb]

golang #26492 proposes a native -static flag. Looks like this was pushed back to 1.13 though.

[candlerb]

FYI, you now also need to add -lpthread (tested with Ubuntu 18.04, golang 1.12.1). It emits warnings about functions in glibc, but still generates a static binary.

# go build -a -ldflags '-extldflags "-static -lcrypto -ldl -lpthread"'
# github.com/prometheus/snmp_exporter/generator
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libcrypto.a(dso_dlfcn.o): In function `dlfcn_globallookup':
(.text+0x11): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libnetsnmp.a(system.o): In function `netsnmp_str_to_gid':
(.text+0x14c4): warning: Using 'getgrnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
(.text+0x14d2): warning: Using 'endgrent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libnetsnmp.a(system.o): In function `netsnmp_str_to_uid':
(.text+0x1444): warning: Using 'getpwnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
(.text+0x1452): warning: Using 'endpwent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/tmp/go-link-149963594/000018.o: In function `_cgo_7e1b3c2abc8d_C2func_getaddrinfo':
/tmp/go-build/cgo-gcc-prolog:57: warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libnetsnmp.a(system.o): In function `netsnmp_gethostbyaddr':
(.text+0xc74): warning: Using 'gethostbyaddr' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libnetsnmp.a(system.o): In function `netsnmp_gethostbyname':
(.text+0x99f): warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
# ldd generator
	not a dynamic executable

[candlerb]

-static pushed back to 1.14, although now planned to be done early in the release cycle

[mitchellrj]

Any update on this?

[Andy1616]

++ thanks

[candlerb]

The underlying go issue still hasn't been fixed, you can track it here: golang/go#26492