Announcement

Collapse
No announcement yet.

Distributing linux binaries, pure64

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

  • 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?

  • #2
    I myself use the $ORIGIN feature of the rpath flag during linking. That way, no scripts or env vars are needed. It's the best invention since sliced bread

    More info:

    Comment


    • #3
      Thanks, but unfortunately that's not what I asked about.

      Loading libs tends to be difficult if the app wants /lib/ld* and the system has it in /lib64.

      Comment


      • #4
        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.

        Comment


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

          Comment


          • #6
            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.

            Comment


            • #7
              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?

              Comment


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

                Comment


                • #9
                  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.

                  Comment


                  • #10
                    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

                    Comment

                    Working...
                    X