[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Rpaths



> I did look into the _rpath_linkopts definition too, but my lack of
> familiarity with bazel is hindering understanding. Is all this
> .bzl stuff essentially written in python or is it a bazel-specific language?

Yes! It's Bazel's configuration language called Starlark: https://docs.bazel.build/versions/master/skylark/language.html
It is a Python dialect, but without many features considered in-hermetic as a configuration language.

> Presumably there are debug modes so I can get more logging detail and
> interrogate, for example, what the whole 'linkopts' string finally gets
> set to, and/or the actual compiler lines the build spits out?

Looks like we have a debugger for Starlark, but I haven't tried that before
https://github.com/laurentlb/stardbg
You can also use the print function to inspect the variable value.

> Currently my build log shows all the warnings, but no compile commands.

If you want to see the compile commands, you can use the "-s" option, see https://docs.bazel.build/versions/master/user-manual.html#flag--subcommands


On Wed, May 26, 2021 at 5:46 PM Wookey <wookey@wookware.org> wrote:
On 2021-05-21 16:41 +0200, Yun Peng wrote:

>    > $chrpath libtensorflow_cc.so.2.3.1
>    > libtensorflow_cc.so.2.3.1:
>    RUNPATH=$ORIGIN/../_solib_k8/_U_S_Stensorflow_Clibtensorflow_Ucc.so.2.3.1___Utensorflow:$ORIGIN/
>    > $ chrpath libtensorflow_framework.so.2.3.1
>    > libtensorflow_framework.so.2.3.1: RUNPATH=$ORIGIN/

>    I think those rpaths are introduced here in tf_cc_shared_object through
>    _rpath_linkopts, which is used to define both tensorflow_cc and
>    tensorflow_framework.

OK. That's really helpful. Thanks. I see it now.

So running chrpath -d on the built libraries does indeed work, but
using the build machinery to do it right i the first place would
be better. So I tried this patch:

--- a/tensorflow/tensorflow.bzl
+++ b/tensorflow/tensorflow.bzl
@@ -620,7 +620,7 @@ def tf_cc_shared_object(
             deps = deps,
             linkshared = 1,
             data = "" + data_extra,
-            linkopts = linkopts + _rpath_linkopts(name_os_full) + select({
+            linkopts = linkopts + select({
                 clean_dep("//tensorflow:ios"): [
                     "-Wl,-install_name,@rpath/" + soname,
                 ],

But that's not sufficient to prevent the rpaths.

I did look into the _rpath_linkopts definition too, but my lack of
familiarity with bazel is hindering understanding. Is all this
.bzl stuff essentially written in python or is it a bazel-specific language?

Presumably there are debug modes so I can get more logging detail and
interrogate, for example, what the whole 'linkopts' string finally gets
set to, and/or the actual compiler lines the build spits out? Currently my
build log shows all the warnings, but no compile commands.

>    I haven't been able to fully understand why TF needs it, but it looks like
>    TF needs it to make the shared libraries work when deployed, eg. in the TF
>    pip package.
>    There is currently no way to turn off this. And I think we should verify
>    if the TF pip package still works without those rpaths, if so we should be
>    able to implement a way to opt out them in the bzl file (or even removing
>    them?).

OK. Once I get to building the python bindings we can check that
that's working. The debian build will of course not be building a
pip. In general rpaths are only actually needed (in debian) when a
package has loadable modules in a sub-path of the normal
library/exectuable search paths.

Wookey
--
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/

Reply to: