Tiny Core Linux
Tiny Core Base => Corepure64 => Topic started by: qopit on February 10, 2016, 09:14:58 PM
-
I've recently run into issues trying to run a compiled go executable that failed to run because it was expecting ld-linux-x86-64.so.2 to be in /lib64/ instead of /lib/, where it is with Corepure64.
This took a while to dig out, eventually via a chain like this:
$ ./influxd
-sh: ./influxd: not found
$ file ./influxd
./influxd: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), stripped
$ ldd ./influxd
linux-vdso.so.1 (0x00007fff7bffe000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007f0a668cc000)
libc.so.6 => /lib/libc.so.6 (0x00007f0a66552000)
/lib64/ld-linux-x86-64.so.2 => /lib/ld-linux-x86-64.so.2 (0x00007f0a66aeb000)
$ strace ./influxd
execve("./influxd", ["./influxd"], [/* 23 vars */]) = -1 ENOENT (No such file or directory)
write(2, "strace: exec: No such file or di"..., 40strace: exec: No such file or directory
) = 40
exit_group(1) = ?
+++ exited with 1 +++
$ readelf -a ./influxd | grep lib64
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
$ sudo ln -s /lib/ld-linux-x86-64.so.2 /lib64/ld-linux-x86-64.so.2
$ ./influxd
<now works perfectly!>
I traced this back to Go having a hard-coded expectation for the amd64 ld.so being in /lib64 :
https://github.com/golang/go/blob/master/src/cmd/link/internal/amd64/obj.go#L78
When asking why this was the case to the Go folks, I got absolutely lambasted for working with an OS (TinyCore) that breaks the convention of x86_64 libs being in /lib64 instead of /lib. Responses were a bit excessive, but such is the internet.
Anyway - digging into the convention I did find this in the FHS spec, which does say that "The 64-bit architectures PPC64, s390x, sparc64 and AMD64 must place 64-bit libraries in /lib64":
http://www.pathname.com/fhs/pub/fhs-2.3.html#LIB64
I'm curious... what was the reason for Corepure64 to use /lib instead of /lib64?
It is also interesting to me that ldd seems to have worked out the correct location for ld-linux-x86-64.so.2. Couldn't Go's binaries latch on to the same .so finding logic? This was deemed as a completely irrational statement/request by Go people.
-
Comments on /lib versus /lib64 aside, it's often not a great idea to use binaries compiled on one distro on another distro.
I see there's a go extension in the x86 repo and the go source code is available, so why not compile it yourself for the x86_64 repo?
-
The lib vs lib64 is mostly a matter of opinion. Not even Ubuntu follows FHS, if you boot a recent Ubuntu, you will see only ld-linux-x86-64.so.2 and some other small support libs are in /lib64, all the rest is in /lib/x86-64-whatever/ and /usr/lib/x86-64-whatever.
IMHO lib64 is ugly like that, but that's my opinion. I would recommend a dir symlink instead (sudo ln -s /lib /lib64) with the symlink added to backup.
-
Thanks, guys. Opinions obviously vary wildly as the drama over the use of /lib was pretty high. :)
I would recommend a dir symlink instead (sudo ln -s /lib /lib64) with the symlink added to backup.
I was thinking of doing that. Thanks for the suggestion and saving me the need to ask if it was a good idea. :)
I see there's a go extension in the x86 repo and the go source code is available, so why not compile it yourself for the x86_64 repo?
I will definitely be doing that. This is my first experience with a go binary, and I was giving their vaunted portability a go. Looks pretty good once that ld situation is sorted out, but to be safe I will try building it myself.
Still curious why ldd could figure out the path to the so, but Go went with hard codding the path. I just don't know enough about the ld logic.
-
fwiw, I had a firefox install that required the same (link lib to lib64). Same cause, though: using pre-built binary...
Sent from my HTC_0P6B6 using Tapatalk
-
While we're on this subject, /usr/bin/locale requires ld-linux-x86-64.so.2 to be in /lib64, or else it dies with a "not found" error. This is with NO extensions loaded, just base. Something to add to the fix list for 7.1 :P
-
Fixed, thanks for reporting this.