Announcement

Collapse
No announcement yet.

Distributing linux binaries, pure64

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • curaga
    started a topic Distributing linux binaries, pure64

    Distributing linux binaries, pure64

    I was wondering if any of the heavyweights around (Svartalf?) could enlighten me with this.

    If one is going to distribute 64-bit linux binaries, the issue of where the dynamic linker is becomes, well, an issue. LD_ vars can't be used to set it.
    Pure64 systems have it in /lib and multilib systems in /lib64, generally.

    I was thinking it would need a wrapper script such as
    [ -d /lib64 ] && /lib64/ld-linux-x86-64.so.2 $APP || $APP
    What's the preferred way to solve this?

  • curaga
    replied
    Thanks, I guess I'll just ignore it, while properly linking to /lib and not /lib64 like the two mentioned binaries..

    Leave a comment:


  • Svartalf
    replied
    Originally posted by RealNC View Post
    I still wouldn't worry too much about it. The majority of systems, pure 64 or multilib, have a /lib that contains 64-bit libs. On multilib ones it's simply a lib->lib64 link.

    That means your binaries, 32bit as well as 64bit, should always link to /lib, not /lib64. That should be the best approach.
    If I'm not mistaken, that's best practices. You won't, however, be able to compensate for, and magically make to just work, something where you've got the 32-bit compat stuff in the mix and not the 64-bit stuff installed (it IS possible... ). You'll get...odd...things to happen and there's nothing you can do to prevent them.

    Leave a comment:


  • Svartalf
    replied
    Originally posted by nanonyme View Post
    Note that you can hardcode search paths into binaries in linker phase. (-rpath or sometimes -R)
    And you can add them in post-linkage via tools like patchelf. :-D

    Leave a comment:


  • RealNC
    replied
    I still wouldn't worry too much about it. The majority of systems, pure 64 or multilib, have a /lib that contains 64-bit libs. On multilib ones it's simply a lib->lib64 link.

    That means your binaries, 32bit as well as 64bit, should always link to /lib, not /lib64. That should be the best approach.

    Leave a comment:


  • nanonyme
    replied
    Note that you can hardcode search paths into binaries in linker phase. (-rpath or sometimes -R)

    Leave a comment:


  • curaga
    replied
    I've hit this one myself in the past, in reverse. Here's how I understand the problem.

    - Path to dynamic linker is hardcoded at compile-time.
    - No variable can change that, the LD* vars only affect things once the linker is loaded
    - If the linker is not at that exact full path, error out

    To my knowledge there's no stub or likewise to try another if the hardcoded one isn't found.

    Example: apps compiled on a multilib system want /lib64/ld-linux-x86-64.so.2, such as Opera or the UPX binary.
    Since my systems are pure64, they won't run (no /lib64 at all, 64-bit libs in /lib).

    Thus I promptly made a symlink lib64 -> lib, but that is advanced knowledge, I want to know how to have this "just work" for the user. How do the professionals handle this problem. Or do they just ignore it like Opera and UPX?

    Leave a comment:


  • RealNC
    replied
    No, he misunderstood what you meant, just as I did.

    To my knowledge, the /lib/ld-*.so libraries are special; the runtime linker chooses then automatically, so there shouldn't be a problem.

    Leave a comment:


  • curaga
    replied
    I mean the case where lib/ is 32-bit, not where it doesn't exist (are there those too?).

    Leave a comment:


  • pingufunkybeat
    replied
    Shouldn't multilib systems provide a /usr/lib symlink?

    Mine does (gentoo), and it seems to me that a system without /usr/lib is broken.

    Leave a comment:

Working...
X