If I were you, and I was determined to do what you want to do, I would probably start by patching TensorFlow to eliminate its default WORKSPACE file. So the solution is to put the stuff built by Spack into the build graph, using plain old BUILD code. It's basically the Gentoo of build systems. So you could potentially have a very long road ahead of you.īlaze was designed to be hermetically sealed and not take anything into consideration anything that isn't defined in its own build graph. defined in workspace.bzl and WORKSPACE? TensorFlow's Bazel configuration is actually doing a deceptively large amount of work. $ bazel build -experimental_cc_shared_library //.Examples? Like eigen, png, gif, jpeg, nasm, highwayhash, farmhash, pcre, swig, curl, proto, grpc, boringssl, etc. In order to get a bit closer to our ideal solution, Bazel has currently (version 5.3.2) experimental support for shared libraries, which is enabled with a flag, that exposes the cc_shared_library rule. According to Bazel's documentation, the linkshared option is only useful to create shared libraries which can be then loaded in runtime. Second problem is, the cc_binary in deps of another binary is simply ignored. First problem is that, the libraries still don't depend on each other. Unfortunately, this approach will not work at all. We need to separately specify header libraries to expose the headers. Here, we try to exploit the possibility of setting the linkshared attribute of cc_binary to true, which will create a shared library. This is not exactly what we want to achieve so let's take a look at another approach: cc_library( Setting the linkstatic attribute of cc_binary to false, will force the executable to be linked dynamically. Setting it to false on a cc_library does not change the default behavior, so still both static and dynamic versions are created. will disable the creation of shared libraries completely. Setting the linkstatic attribute of cc_library to true. Linking cc_binary statically is the default behavior, contrary to cc_test, which is linked dynamically. The shared objects themselves do not specify their dependencies. The executable does not link against shared objects. $ readelf -a bazel-bin/libf2.so | grep -e NEEDED -e RUNPATH $ readelf -a bazel-bin/libf1.so | grep -e NEEDED -e RUNPATH $ readelf -a bazel-bin/main_test | grep -e NEEDED -e RUNPATH However, if we look closely we will see that few things are missing $ readelf -a bazel-bin/main | grep -e NEEDED -e RUNPATH The above setup can be replicated with a simple BUILD file using Bazel: cc_library(Īs a result we will see both static and shared libraries created: $ tree -L 1 bazel-bin/ The result is similar to what can be achived with manual steps: $ tree -L 1 build-cmake/ Using public will result in the executable having both f1 and f2 specified in NEEDED tags.Īdditionally the VERSION and SOVERSION properties are set for the library targets, so that they have a proper shared object name and symlinks are automatically created.ĬMake by default does not build shared libraries and needs to be instructed to do so: $ cmake -B build-cmake. This will prevent CMake from transitively forwarding the dependencies of f1 to all targets that depend on f1. Notice the usage of PRIVATE keyword for f1 dependencies. Additionally by using target_link_libraries, the dependency chain is created. Standard command add_library and add_executable are needed. The manual process above can be reproduced using CMake: cmake_minimum_required(VERSION 3.22) $ readelf -d build/f1/libf1.so.0.1 | grep -e NEEDED -e RUNPATHĠx000000000000001d (RUNPATH) Library runpath: Building shared libraries with CMake However, looking at dynamic tags, it is clear that the f2 dependency comes directly form f1. So both libraries, f1 and f2 are correctly found. Linking an executable, to library f1 will result in the following output from ldd: $ ldd build/main In both cases the SONAME of the dependency will be embedded into the resulting library's DT_NEEDED tag. First, the object files need to be created: "$/build/f2" -lf2 \ A shared library is a collection of object files that contain usable symbols, which are loaded by the dynamic linker when running an executable.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |