Rationale for /lib vs /lib64 in Corepure64?

[qopit]

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:

Code: [Select]

$ ./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.

[Juanito]

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?

[curaga]

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.

[qopit]

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.

[dentonlt]

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

[andyj]

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   

[Juanito]

Fixed, thanks for reporting this.