0

I am building a simple C++ benchmark using a custom compilation tool (which has in-built clang plugin) and it simply is another regular C++ compiler. However whenever I try to run the compiled (and linked) binary, it never looks up for LD_LIBRARY_PATH to find the correct libstdc++ version. It always look for the standard /usr/lib64 and the libstdc++ version there is too old for my executable. I want to point my binary to look up in LD_LIBRARY_PATH when it runs. (I don't have root access.)

Below is the output when running it:

[xx@login-01 src]$ ./executable.x
./executable.x: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by ./executable.x)

Below is output from gcc --version command. This GCC version is sufficient but my executable doesn't look for its lib path, which is in LD_LIBRARY_PATH.

gcc (GCC) 9.2.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

echo $LD_LIBRARY_PATH output is below. Notice it has correct GCC lib path.

/cm/local/apps/gcc/9.2.0/lib:/cm/local/apps/gcc/9.2.0/lib64:/home/ri-wshilpage/tools/LLVM/llvm-project/build/lib:/home/ri-wshilpage/tools/LLVM/llvm-project/build/lib/libomp.so:/opt/gcc/8.1.0/snos/lib64:/opt/cray/pe/papi/6.0.0.7/lib64:/cm/shared/apps/pbspro/19.2.8.20200925072630/lib/

Below I have checked the output from readelf -d ./executable.x and its RPATH shows only /usr/lib64 and the lib path of the custom compiler.

Dynamic section at offset 0x92d58 contains 34 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libhipSYCL-rt.so]
 0x0000000000000001 (NEEDED)             Shared library: [libboost_context.so.1.66.0]
 0x0000000000000001 (NEEDED)             Shared library: [libboost_fiber.so.1.66.0]
 0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libomp.so]
 0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000000f (RPATH)              Library rpath: [/lustre/home/xx/sycl-compilers/hipSYCL/build/install/bin/../lib/:/usr/lib64]
 0x000000000000000c (INIT)               0x407000
 0x000000000000000d (FINI)               0x477d98
 0x0000000000000019 (INIT_ARRAY)         0x493980
 0x000000000000001b (INIT_ARRAYSZ)       160 (bytes)
 0x000000000000001a (FINI_ARRAY)         0x493a20
 0x000000000000001c (FINI_ARRAYSZ)       8 (bytes)
 0x0000000000000004 (HASH)               0x400320
 0x000000006ffffef5 (GNU_HASH)           0x400b70
 0x0000000000000005 (STRTAB)             0x402798
 0x0000000000000006 (SYMTAB)             0x400e90
 0x000000000000000a (STRSZ)              12941 (bytes)
 0x000000000000000b (SYMENT)             24 (bytes)
 0x0000000000000015 (DEBUG)              0x0
 0x0000000000000003 (PLTGOT)             0x494000
 0x0000000000000002 (PLTRELSZ)           4056 (bytes)
 0x0000000000000014 (PLTREL)             RELA
 0x0000000000000017 (JMPREL)             0x405fe8
 0x0000000000000007 (RELA)               0x405df0
 0x0000000000000008 (RELASZ)             504 (bytes)
 0x0000000000000009 (RELAENT)            24 (bytes)
 0x000000006ffffffe (VERNEED)            0x405c40
 0x000000006fffffff (VERNEEDNUM)         6
 0x000000006ffffff0 (VERSYM)             0x405a26
 0x0000000000000000 (NULL)               0x0

And finally here's the Makefile.

#-----------------------------------------------------------------------
# This file compiles for OpenMP and MPI hybrid operations using the GNU
# compile chain.

MINIFE_TYPES =  \
        -DMINIFE_SCALAR=double   \
        -DMINIFE_LOCAL_ORDINAL=int      \
        -DMINIFE_GLOBAL_ORDINAL=int \
        -DMINIFE_RESTRICT=__restrict__

MINIFE_MATRIX_TYPE = -DMINIFE_CSR_MATRIX

#-----------------------------------------------------------------------
CXX       = syclcc
CC        = syclcc
OPTIMIZE  = yes

CPPFLAGS = --gcc-toolchain=/lustre/projects/bristol/modules/gcc/9.2.0 --hipsycl-targets=omp -I. -I../utils -I../fem $(MINIFE_TYPES) -I../../include/ $(MINIFE_MATRIX_TYPE) \
           -std=c++17 -I/home/xx/tools/LLVM/llvm-project/build/projects/openmp/runtime/src

ifeq ($(OPTIMIZE),yes)
  CFLAGS += -O3
endif

CXXFLAGS = $(CFLAGS)

include make_targets

Also note that I have built LLVM from source (version 12.0.1) and used it to build my custom compiler. Everything works fine except for the executable not looking up at LD_LIBRARY_PATH for shared libraries.

Edit: Check the output from ldd ./executable.x below.

./executable.x: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by ./executable.x)
    linux-vdso.so.1 (0x0000155555551000)
    libhipSYCL-rt.so => /lustre/home/xx/sycl-compilers/hipSYCL/build/install/bin/../lib/libhipSYCL-rt.so (0x00001555554ff000)
    libboost_context.so.1.66.0 => /usr/lib64/libboost_context.so.1.66.0 (0x0000155555128000)
    libboost_fiber.so.1.66.0 => /usr/lib64/libboost_fiber.so.1.66.0 (0x0000155554ec5000)
    libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000155554b30000)
    libm.so.6 => /usr/lib64/libm.so.6 (0x00001555547ae000)
    libomp.so => /home/xx/tools/LLVM/llvm-project/build/lib/libomp.so (0x000015555540d000)
    libgcc_s.so.1 => /usr/lib64/libgcc_s.so.1 (0x0000155554596000)
    libpthread.so.0 => /usr/lib64/libpthread.so.0 (0x0000155554376000)
    libc.so.6 => /usr/lib64/libc.so.6 (0x0000155553fb4000)
    libdl.so.2 => /usr/lib64/libdl.so.2 (0x0000155553db0000)
    /lib64/ld-linux-x86-64.so.2 (0x000015555532b000)
    librt.so.1 => /usr/lib64/librt.so.1 (0x0000155553ba7000)
    libboost_filesystem.so.1.66.0 => /usr/lib64/libboost_filesystem.so.1.66.0 (0x000015555398c000)
    libboost_system.so.1.66.0 => /usr/lib64/libboost_system.so.1.66.0 (0x0000155553787000)
wr93_
  • 130
  • 1
  • 1
  • 13
  • `readelf` doesn't read LD_LIBRARY_PATH. Try `ldd` or set env var LD_TRACE_LOADED_OBJECTS. Also see secure execution mode in `man ld.so`. – n. m. could be an AI Jul 13 '22 at 11:18
  • Sorry, I don't get. `ldd ./executable.x` only shows requested dynamic libs (I've updated the post with it). My problem is not about readelf or ldd but why doesn't it load libs from LD_LIBRARY_PATH. Also why run in secure mode? – wr93_ Jul 13 '22 at 11:30
  • Do you have any other LD_* environment variables set? E.g., LD_RUN_PATH. – Paul Floyd Jul 13 '22 at 11:38
  • @PaulFloyd No. Only LD_LIBRARY_PATH. – wr93_ Jul 13 '22 at 11:42
  • `ldd` shows where a library would be found. In your case it shows that it would be found in `/usr/lib64` and not where you think it is. I think it is because RPATH takes precedence over LD_LIBRARY_PATH. You should not be using RPATH, it is deprecated, and in any case a system directory like /usr/lib64 should not be there. Secure execution mode is something you might be in without realizing it, so just another thing to check. – n. m. could be an AI Jul 13 '22 at 11:59
  • @n.1.8e9-where's-my-sharem. That makes sense. I now realize my executable actually looks in LD_LIBRARY_PATH (it finds other binaries like libomp.so there) but since it first check in /usr/lib64 and finds libstdc++ (older version) it doesn't check any further for that. Do you know how can I prevent it looking in RPATH or /usr/lib64? – wr93_ Jul 13 '22 at 12:05
  • Rpath should not be there to begin with, I have no idea how it gets there without an explicit --rpath= option. But you can edit it post factum, see https://stackoverflow.com/questions/13769141/can-i-change-rpath-in-an-already-compiled-binary – n. m. could be an AI Jul 13 '22 at 13:32
  • Does your executable use execve in any way or form? If it does then using LD_LIBRARY_PATH may break what you are trying to exec. Where does that end? Every executable forced to use a wrapper script that sets LD_LIBRARY_PATH. Great. I strongly perfer a) RPATH with $ORIGIN b) RUNPATH if you are happy with every tom dick and harriet breaking your app with LD_LIBRARY_PATH c) LD_LIBRARY_PATH as the absolute last resort. – Paul Floyd Jul 13 '22 at 19:16

0 Answers0