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