Library search path when building bazel

[trungnt13]

I need to set the library search path so bazel can find newer version of GMP, MPC, MPFR and libstdc++.so.6.0.20

I tried several way to make bazel recognize the new path (libstdc++.so.6.0.20 in /appl/opt/gcc/4.9.3/lib64)

export LD_LIBRARY_PATH=/homeappl/home/trungnt/appl_taito/usr/lib:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH=/appl/opt/gcc/4.9.3/lib64:$LD_LIBRARY_PATH

It still looks for libstdc++.so.6.0.20 in /usr/lib64, then, I tried other way, modify file tools/cpp/CROSSTOOL, added thess line to local_linux toolchain

  cxx_flag: "-std=c++0x"
  linker_flag: "-L/appl/opt/gcc/4.9.3/lib64/libstdc++.so.6.0.20"
  linker_flag: "-L/homeappl/home/trungnt/appl_taito/usr/lib"
  linker_flag: "-lstdc++"

It still didn't work.
The only way I can make it recognize path to other library path is:

LD_LIBRARY_PATH=/homeappl/home/trungnt/appl_taito/usr/lib ./compile.sh

But then I can not add 2 path add the same time. Any Suggestion?

[laszlocsomor]

I'm no domain expert of the C++ rules but I'll try to help.

When you edited the CROSSTOOL file, did you see bazel passing the linker flags to ld? Run the build with -s to see all commands that bazel executes, or with --verbose_failures to see the failing commands if any.

[bsilver8192]

Are you trying to make the Bazel binary itself use different shared libraries when running, have tools run by Bazel use different libraries, or have the binaries built by Bazel be linked against different libraries? LD_LIBRARY_PATH is the way to do the first one and the linker_flags are the way to do the third one. The second one is complicated.

For multiple paths in LD_LIBRARY_PATH (you said you got one working), did you try using : to separate them like this?

LD_LIBRARY_PATH=/homeappl/home/trungnt/appl_taito/usr/lib:/appl/opt/gcc/4.9.3/lib64/libstdc++.so.6.0.20 ./compile.sh

Also, keep in mind when changing environment variables that Bazel sometimes leaves a process running in the background, which won't pick up new environment variables. Make sure to do a bazel shutdown in between.

As far as editing CROSSTOOL, are you doing this on an OSX machine? If you are, you need to edit the local_darwin toolchain instead.

Adding -v and/or -Wl,-v as a linker_flag is often helpful for debugging issues with which files the compiler is using to link.

Another possible problem is the sandbox won't include files in those paths by default like it will /usr/lib64. Building with --sandbox_debug will show you everything that is included in the sandbox (everything not listed isn't). Alternatively, --spawn_strategy=standalone should disable the sandbox, which might help for debugging.

[damienmg]

@trungnt13 can you give update on your issue?

[trungnt13]

@bsilver8192 Yes I tried using : to separate them, but it only recognize the first one in the sequence. btw, this error happen when I tried to compile bazel, sorry this confusion. I tried to install bazel on RedHat server.
However, I got stuck into other problem. Bazel 0.1.1 require JDK 8 to compile. However, the server has only JDK 7, I have no permission to install anything on a remote server.
So I download Oracle JDK 1.8.66 and set JAVA_HOME to its path, then this error come up:

FIXED

[damienmg]

Can you try with the -jdk7 variant?

https://github.com/bazelbuild/bazel/releases/download/0.1.1/bazel-0.1.1-jdk7-installer-linux-x86_64.sh

[trungnt13]

Uncompressing......./homeappl/home/trungnt/bin/bazel: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /homeappl/home/trungnt/bin/bazel)

I don't know if I can change libc.so.6, I think it is fixed to the OS

[trungnt13]

I manage to fix error with my JDK 1.8, however, it falls back to this error again:
#585
and
#583

LD_LIBRARY_PATH=/homeappl/home/trungnt/appl_taito/usr/lib ./compile.sh

INFO: You can skip this first step by providing a path to the bazel binary as second argument:
INFO:    ./compile.sh build /path/to/bazel
�  Building Bazel from scratch............
�  Building Bazel with Bazel.
./homeappl/home/trungnt/appl_taito/libs/bazel/output/bazel: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.14' not found (required by /homeappl/home/trungnt/appl_taito/libs/bazel/output/bazel)
/homeappl/home/trungnt/appl_taito/libs/bazel/output/bazel: /usr/lib64/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by /homeappl/home/trungnt/appl_taito/libs/bazel/output/bazel)
/homeappl/home/trungnt/appl_taito/libs/bazel/output/bazel: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by /homeappl/home/trungnt/appl_taito/libs/bazel/output/bazel)

Building output/bazel

My local_linux toolchain:

toolchain {
  abi_version: "local"
  abi_libc_version: "local"
  builtin_sysroot: ""
  compiler: "compiler"
  host_system_name: "local"
  needsPic: true
  supports_gold_linker: false
  supports_incremental_linker: false
  supports_fission: false
  supports_interface_shared_objects: false
  supports_normalizing_ar: false
  supports_start_end_lib: false
  supports_thin_archives: false
  target_libc: "local"
  target_cpu: "local"
  target_system_name: "local"
  toolchain_identifier: "local_linux"

  tool_path { name: "ar" path: "/appl/opt/binutils/2.25/bin/ar" }
  tool_path { name: "compat-ld" path: "/appl/opt/binutils/2.25/bin/ld" }
  tool_path { name: "cpp" path: "/appl/opt/gcc/4.9.3/bin/cpp" }
  tool_path { name: "dwp" path: "/usr/bin/dwp" }
  tool_path { name: "gcc" path: "/appl/opt/gcc/4.9.3/bin/gcc" }
  cxx_flag: "-std=c++0x"
  linker_flag: "-lstdc++"
  linker_flag: "-B/appl/opt/gcc/4.9.3/bin/"

  # TODO(bazel-team): In theory, the path here ought to exactly match the path
  # used by gcc. That works because bazel currently doesn't track files at
  # absolute locations and has no remote execution, yet. However, this will need
  # to be fixed, maybe with auto-detection?
  cxx_builtin_include_directory: "/appl/opt/gcc/4.9.3/lib/gcc/"
  cxx_builtin_include_directory: "/usr/local/include"
  cxx_builtin_include_directory: "/appl/opt/gcc/4.9.3/include"
  tool_path { name: "gcov" path: "/appl/opt/gcc/4.9.3/bin/gcov" }

  # C(++) compiles invoke the compiler (as that is the one knowing where
  # to find libraries), but we provide LD so other rules can invoke the linker.
  tool_path { name: "ld" path: "/appl/opt/binutils/2.25/bin/ld" }

  tool_path { name: "nm" path: "/appl/opt/binutils/2.25/bin/nm" }
  tool_path { name: "objcopy" path: "/appl/opt/binutils/2.25/bin/objcopy" }
  objcopy_embed_flag: "-I"
  objcopy_embed_flag: "binary"
  tool_path { name: "objdump" path: "/appl/opt/binutils/2.25/bin/objdump" }
  tool_path { name: "strip" path: "/appl/opt/binutils/2.25/bin/strip" }

  # Anticipated future default.
  unfiltered_cxx_flag: "-no-canonical-prefixes"

  # Make C++ compilation deterministic. Use linkstamping instead of these
  # compiler symbols.
  unfiltered_cxx_flag: "-Wno-builtin-macro-redefined"
  unfiltered_cxx_flag: "-D__DATE__=\"redacted\""
  unfiltered_cxx_flag: "-D__TIMESTAMP__=\"redacted\""
  unfiltered_cxx_flag: "-D__TIME__=\"redacted\""

  # Security hardening on by default.
  # Conservative choice; -D_FORTIFY_SOURCE=2 may be unsafe in some cases.
  # We need to undef it before redefining it as some distributions now have
  # it enabled by default.
  compiler_flag: "-U_FORTIFY_SOURCE"
  compiler_flag: "-D_FORTIFY_SOURCE=1"
  compiler_flag: "-fstack-protector"
  linker_flag: "-Wl,-z,relro,-z,now"

  # Enable coloring even if there's no attached terminal. Bazel removes the
  # escape sequences if --nocolor is specified. This isn't supported by gcc
  # on Ubuntu 14.04.
  # compiler_flag: "-fcolor-diagnostics"

  # All warnings are enabled. Maybe enable -Werror as well?
  compiler_flag: "-Wall"
  # Enable a few more warnings that aren't part of -Wall.
  compiler_flag: "-Wunused-but-set-parameter"
  # But disable some that are problematic.
  compiler_flag: "-Wno-free-nonheap-object" # has false positives

  # Keep stack frames for debugging, even in opt mode.
  compiler_flag: "-fno-omit-frame-pointer"

  # Anticipated future default.
  linker_flag: "-no-canonical-prefixes"
  # Have gcc return the exit code from ld.
  linker_flag: "-pass-exit-codes"
  # Stamp the binary with a unique identifier.
  linker_flag: "-Wl,--build-id=md5"
  linker_flag: "-Wl,--hash-style=gnu"
  # Gold linker only? Can we enable this by default?
  # linker_flag: "-Wl,--warn-execstack"
  # linker_flag: "-Wl,--detect-odr-violations"

  compilation_mode_flags {
    mode: DBG
    # Enable debug symbols.
    compiler_flag: "-g"
  }
  compilation_mode_flags {
    mode: OPT

    # No debug symbols.
    # Maybe we should enable https://gcc.gnu.org/wiki/DebugFission for opt or
    # even generally? However, that can't happen here, as it requires special
    # handling in Bazel.
    compiler_flag: "-g0"

    # Conservative choice for -O
    # -O3 can increase binary size and even slow down the resulting binaries.
    # Profile first and / or use FDO if you need better performance than this.
    compiler_flag: "-O2"

    # Disable assertions
    compiler_flag: "-DNDEBUG"

    # Removal of unused code and data at link time (can this increase binary size in some cases?).
    compiler_flag: "-ffunction-sections"
    compiler_flag: "-fdata-sections"
    linker_flag: "-Wl,--gc-sections"
  }
}

[damienmg]

export CC and CXX and maybe LD_FLAGS too.

[trungnt13]

I tried, the same errors happened:

INFO: You can skip this first step by providing a path to the bazel binary as second argument:
INFO:    ./compile.sh build /path/to/bazel
�  Building Bazel from scratch............
�  Building Bazel with Bazel.
./homeappl/home/trungnt/appl_taito/libs/bazel/output/bazel: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.14' not found (required by /homeappl/home/trungnt/appl_taito/libs/bazel/output/bazel)
/homeappl/home/trungnt/appl_taito/libs/bazel/output/bazel: /usr/lib64/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by /homeappl/home/trungnt/appl_taito/libs/bazel/output/bazel)
/homeappl/home/trungnt/appl_taito/libs/bazel/output/bazel: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by /homeappl/home/trungnt/appl_taito/libs/bazel/output/bazel)

[damienmg]

Sorry this has fell off my radar, did you found a solution?

[trungnt13]

I tried to install newest bazel 0.1.2 but it is hopeless also.
It always search for default libstdc++ in /usr/lib64, even how many paths I add to the build process.

[damienmg]

The responsible code for building that binary is at https://github.com/bazelbuild/bazel/blob/master/scripts/bootstrap/compile.sh#L270 and at https://github.com/bazelbuild/bazel/blob/master/scripts/bootstrap/compile.sh#L281

So settings CXX and LDFLAGS + LD_LIBRARY_PATH should be enough. Am at lost to what more to do. bringing in @ulfjack that should have better ideas.

How would you compile a simple C++ program usually?

[damienmg]

@trungnt13 @ulfjack ping?

[ulfjack]

Is there a VM image somewhere that we could use to reproduce?

[damienmg]

@trungnt13 Friendly ping

[damienmg]

Closing this issue as there is no answer.

[y2kenny]

I just ran into this same issue (GLIBCXX_3.4.18 and .19 not found) on a ubuntu 12 system using apt-get install.