WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: Rationale for /lib vs /lib64 in Corepure64?  (Read 5172 times)

Offline qopit

  • Jr. Member
  • **
  • Posts: 81
Rationale for /lib vs /lib64 in Corepure64?
« 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:
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.


Offline Juanito

  • Administrator
  • Hero Member
  • *****
  • Posts: 14638
Re: Rationale for /lib vs /lib64 in Corepure64?
« Reply #1 on: February 11, 2016, 03:06:38 AM »
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?
« Last Edit: February 11, 2016, 03:09:05 AM by Juanito »

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 10992
Re: Rationale for /lib vs /lib64 in Corepure64?
« Reply #2 on: February 11, 2016, 04:43:39 AM »
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.
The only barriers that can stop you are the ones you create yourself.

Offline qopit

  • Jr. Member
  • **
  • Posts: 81
Re: Rationale for /lib vs /lib64 in Corepure64?
« Reply #3 on: February 11, 2016, 11:07:50 AM »
Thanks, guys.  Opinions obviously vary wildly as the drama over the use of /lib was pretty high. :)

Quote
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. :)

Quote
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.


Offline dentonlt

  • Sr. Member
  • ****
  • Posts: 318
    • the trombone analog
Re: Rationale for /lib vs /lib64 in Corepure64?
« Reply #4 on: March 18, 2016, 09:49:38 PM »
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


Offline andyj

  • Hero Member
  • *****
  • Posts: 1023
Re: Rationale for /lib vs /lib64 in Corepure64?
« Reply #5 on: April 03, 2016, 05:22:15 PM »
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 

Offline Juanito

  • Administrator
  • Hero Member
  • *****
  • Posts: 14638
Re: Rationale for /lib vs /lib64 in Corepure64?
« Reply #6 on: April 05, 2016, 03:29:36 AM »
Fixed, thanks for reporting this.