Page 1 of 2 12 LastLast
Results 1 to 10 of 12

Thread: Distributing linux binaries, pure64

Hybrid View

  1. #1
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    4,987

    Default 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. #2
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,776

    Default

    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

  3. #3
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    4,987

    Default

    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.

  4. #4
    Join Date
    Jun 2009
    Posts
    2,926

    Default

    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.

  5. #5
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    4,987

    Default

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

  6. #6
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,776

    Default

    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.

  7. #7
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    4,987

    Default

    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?

  8. #8
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,577

    Default

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

  9. #9
    Join Date
    Jun 2006
    Posts
    3,046

    Default

    Quote 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

  10. #10
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,776

    Default

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •