Re: [PATCH v2 1/4] pmemblk, dev-dax: load libpmem and libpmemblk at startup

[Jens Axboe <axboe@fb.com>]

On Tue, Jan 10 2017, Robert Elliott wrote:
> From: Robert Elliott <elliott@hpe.com>
> 
> The pmemblk and dev-dax ioengines were loading libpmem.so and
> libpmemblk.so using dlopen() at runtime.
> 
> Although the upstream nvml Makefile installs a libpmem.so
> symbolic link, some of the distros (e.g. SUSE Linux Enterprise
> Server 12 SP2) are just installing so.1 symbolic links.  So,
> fio fails to find the libpmem.so and libpmemblk.so library files.
> 
> http://www.ibm.com/developerworks/linux/library/l-shlibs/index.html
> says applications should always load the versioned filenames to
> avoid compatibility issues; the non-versioned filenames are just
> for the compiler and linker.
> 
> Change ./configure to pass -lpmem and -lpmemblk to the compiler
> so the fio binary loads the versioned filename at startup like
> the other libraries, rather than open the non-versioned filename
> with dlopen() during runtime.
> 
> This way they show up in ldd:
> $ ldd fio
>         linux-vdso.so.1 (0x00007ffc290aa000)
>         libpmemblk.so.1 => /lib64/libpmemblk.so.1 (0x00007f65b5bc4000)
>         libpmem.so.1 => /lib64/libpmem.so.1 (0x00007f65b59be000)
>         libnuma.so.1 => /lib64/libnuma.so.1 (0x00007f65b57b3000)
>         librt.so.1 => /lib64/librt.so.1 (0x00007f65b55ab000)
>         libaio.so.1 => /lib64/libaio.so.1 (0x00007f65b53a9000)
>         libz.so.1 => /lib64/libz.so.1 (0x00007f65b5191000)
>         libm.so.6 => /lib64/libm.so.6 (0x00007f65b4e88000)
>         libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f65b4c6a000)
>         libdl.so.2 => /lib64/libdl.so.2 (0x00007f65b4a66000)
>         libc.so.6 => /lib64/libc.so.6 (0x00007f65b46a0000)
>         libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f65b449b000)
>         /lib64/ld-linux-x86-64.so.2 (0x0000559f4d872000)

Added 1-4, thanks Robert.

-- 
Jens Axboe