When to patchelf

Habitat Help
#1

Hi there,

I’ve been learning habitat by building a concourse cluster in habitat, my plans are based on a newer release then what’s in core (4.2.2 vs 5.1.0) / I plan on raising a PR for core if that helps.
My questions was around the use of patchelf within the current core plan.

patchelf --interpreter "$(pkg_path_for glibc)/lib/ld-linux-x86-64.so.2" "${pkg_prefix}/bin/concourse"

I’m sorry if this is a silly question (I’m a windows guy) but is this being done because it errored before? like how would I know in the future that I have to do that? for my 5.1.0 build I haven’t done that and it seems to work, so I didn’t know if this is always required when packaging binaries in habitat.

Thanks in advance

Gary

#2

Usually binaries are linked with shared libraries and other stuff.
Use ldd <binary> to get list of linked libraries. Habitat should run on isolated environment and use only its dependencies, not system wide one. So correct habitatized binary is binary which has all linked libraries in /hab/ path.

This is good:

╰─○ ldd /hab/pkgs/core/hab-sup/0.78.0/20190313123140/bin/hab-sup
        linux-vdso.so.1 (0x00007fff482a4000)
        libpthread.so.0 => /hab/pkgs/core/glibc/2.27/20190115002733/lib/libpthread.so.0 (0x00007fb9fc00b000)
        libssl.so.1.0.0 => /hab/pkgs/core/openssl/1.0.2r/20190305210149/lib/libssl.so.1.0.0 (0x00007fb9fbf97000)
        libcrypto.so.1.0.0 => /hab/pkgs/core/openssl/1.0.2r/20190305210149/lib/libcrypto.so.1.0.0 (0x00007fb9fbcc5000)
        libzmq.so.5 => /hab/pkgs/core/zeromq/4.2.5/20190117202641/lib/libzmq.so.5 (0x00007fb9fbbfc000)
        libarchive.so.13 => /hab/pkgs/core/libarchive/3.3.3/20190305214120/lib/libarchive.so.13 (0x00007fb9fbb1f000)
        libsodium.so.23 => /hab/pkgs/core/libsodium/1.0.16/20190116014025/lib/libsodium.so.23 (0x00007fb9fba01000)
        libdl.so.2 => /hab/pkgs/core/glibc/2.27/20190115002733/lib/libdl.so.2 (0x00007fb9fb9fc000)
        librt.so.1 => /hab/pkgs/core/glibc/2.27/20190115002733/lib/librt.so.1 (0x00007fb9fb9f2000)
        libgcc_s.so.1 => /hab/pkgs/core/gcc-libs/8.2.0/20190115011926/lib/libgcc_s.so.1 (0x00007fb9fb9d8000)
        libc.so.6 => /hab/pkgs/core/glibc/2.27/20190115002733/lib/libc.so.6 (0x00007fb9fb820000)
        /hab/pkgs/core/glibc/2.27/20190115002733/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007fb9fd17d000)
        libm.so.6 => /hab/pkgs/core/glibc/2.27/20190115002733/lib/libm.so.6 (0x00007fb9fb68d000)
        libstdc++.so.6 => /hab/pkgs/core/gcc-libs/8.2.0/20190115011926/lib/libstdc++.so.6 (0x00007fb9fb483000)
        liblzma.so.5 => /hab/pkgs/core/xz/5.2.4/20190115013348/lib/liblzma.so.5 (0x00007fb9fb44d000)
        libbz2.so.1.0 => /hab/pkgs/core/bzip2/1.0.6/20190115011950/lib/libbz2.so.1.0 (0x00007fb9fb43a000)
        libz.so.1 => /hab/pkgs/core/zlib/1.2.11/20190115003728/lib/libz.so.1 (0x00007fb9fb419000)

This is bad, because binaries are outside of /hab and possible will NOT be available:

╰─○ ldd /hab/pkgs/core/concourse/4.2.2/20190211205442/bin/concourse
        linux-vdso.so.1 (0x00007fffdf766000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f22b3ec6000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f22b3ec1000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f22b3d00000)
        /hab/pkgs/core/glibc/2.27/20190115002733/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f22b3f17000)
2 Likes
#3

Thank you @jsirex for explaining that, I’ve patch the binary now to reference the core/glibc package
`

ldd ./concourse

    linux-vdso.so.1 =>  (0x00007ffdf09eb000)
    libpthread.so.0 => /hab/pkgs/core/glibc/2.27/20190115002733/lib64/libpthread.so.0 (0x00007f1c3409f000)
    libdl.so.2 => /hab/pkgs/core/glibc/2.27/20190115002733/lib64/libdl.so.2 (0x00007f1c34099000)
    libc.so.6 => /hab/pkgs/core/glibc/2.27/20190115002733/lib64/libc.so.6 (0x00007f1c33ee1000)
    /hab/pkgs/core/glibc/2.27/20190115002733/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f1c33e9f000)

`

1 Like