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

Re: Rpaths



Hi Olek & Wookey,

Sorry for the late reply here, I'm also pretty occupied by other things.

> $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.
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?).

Hope this helps!

On Thu, May 20, 2021 at 10:45 PM Olek Wojnar <olek@debian.org> wrote:
Hi Wookey,

Sorry for the slow reply, it's been a week. Actually, it's been a few of them... :/

On Mon, May 17, 2021 at 11:32 PM Wookey <wookey@wookware.org> wrote:
It's policy not to set rpaths set in debian libraries, but (at least
for tensorflow) the libraries are built with the -rpath option so one
end up set:
(the .params file shows
-Wl,-rpath,$ORIGIN
)

$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/

Not sure why those are different, but neither is what we want.

Indeed, not good!
 
So is there a bazel config option for 'don't set rpath please'? Or
will I have to chrpath -d it afterwards? (which is awkward, because
the libraries or built with mode -r-xr-xr-x so chrpath -d doesn't work
without some faffing.

I see that you've subsequently added a chrpath commit. Is that working? Even if it is, I agree that it's not the best option.

Perhaps Yun has some insight on an option like that. I don't know of it off the top of my head and a search through Bazel's documentation didn't reveal anything that looked promising.

There seems to be logic in tensorflow.bzl to only set rpaths for test
binaries and ios/macos/windows, but clearly it is still getting set.

Yes, I spent some time looking through the TF source and I saw that. I also saw two other places where that may be set. It looks like [1] sets RPATH specifically for two libraries and conditionally for a third. However, it looks like [2] sets it for everything. That might be the issue. Please take with appropriate salt since I'm not that familiar with the TF source and unfortunately didn't have time to go through it carefully.

Clues welcome.

I hope those two clues help. If not, please let me know and I can take a closer look! Or maybe Yun will have some additional insights. 

-Olek

[1] https://salsa.debian.org/deeplearning-team/tensorflow/-/blob/master/tensorflow/core/platform/default/build_config/BUILD#L203-229
[2]  https://salsa.debian.org/deeplearning-team/tensorflow/-/blob/master/third_party/gpus/crosstool/cc_toolchain_config.bzl.tpl#L524-526

Reply to: