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:
    http://freegamedev.net/wiki/Portable...ur_application

    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


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

                      Comment


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

                        Comment

                        Working...
                        X