arm builds are linked against wrong library

[errnoh]

ARM builds for consul-template are linked against non-arm library, resulting in them not being executable.

Comparison of dynamically linked nomad build and dynamically linked consul-template build:

> uname -a
Linux scw-sleepy-ishizaka 4.9.93-mainline-rev1 #1 SMP Tue Apr 10 09:42:40 UTC 2018 armv7l armv7l armv7l GNU/Linux
> wget https://releases.hashicorp.com/consul-template/0.23.0/consul-template_0.23.0_linux_arm.zip; unzip consul-template_0.23.0_linux_arm.zip
> ./consul-template
-bash: ./consul-template: No such file or directory
> file ./consul-template
./consul-template: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, stripped

> nomad version
Nomad v0.10.1 (0d4e5d949fe073c47a947ea36bfef31a3c49224f)
> file /usr/local/bin/nomad
/usr/local/bin/nomad: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=e61e9b348b4607ffe8813aba5593a91ff8224ebf, not stripped

> ls /lib/*.so.3
/lib/ld-linux-armhf.so.3

There's a workaround for this: copy/symlink the armhf library to the location consul-template expects it to be at, but that's not solving the real issue.

NOTE: Probably only affects arm and not arm64:
arm64: consul-template: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, stripped

[eikenb]

Thanks for the report @errnoh

This looks like this might be a case of this issue.. golang/go#12443

I'll try the solutions they discuss there and see what I can come up with.

[eikenb]

@errnoh Could you run these and paste the output here. Thanks.

$ uname -m

$ readelf -a /proc/self/exe | grep -q -c Tag_ABI_VFP_args && echo "armhf" || echo "armel"

[errnoh]

Thank for the reply @eikenb, here you go:

> uname -m
armv7l

> readelf -a /proc/self/exe | grep -q -c Tag_ABI_VFP_args && echo "armhf" || echo "armel"
armhf

[eikenb]

I think what is going on is that the docs I read and based my compiles on must have not been 100% right or complete. According to it a binary compiled with CC=arm-linux-gnueabi-gcc was supposed to run on ARM 5+ while one compiled with arm-linux-gnueabihf-gcc being 6+. My guess is that arm-linux-gnueabi-gcc doesn't work for 6+ out of the box. I have no way to test this as the emulators seem to only cover ARM7+ and I don't have the hardware.

That issue I mentioned (golang/go#12443) seems to indicate it should work, but I've tried with the settings they suggest (-mfloat-abi=hard) and it didn't change the linking with arm-linux-gnueabi-gcc. It does if I use arm-linux-gnueabihf-gcc.

I'm thinking I'll just change the 32bit ARM support to be 6+ and use arm-linux-gnueabihf-gcc. If there is someone still using ARM 5 I could add another build for it, but I think I'll wait to see if someone asks for it.

I'm going to be doing a minor release soon and will include the change in the ARM compiler setup then as it sounds like you have a workaround for now. If you need a build before then, I can look into doing a one-off for you.