Bad LC_ID_DYLIB in libpython3.11.dylib?

[rao94583]

We have an externally imported package (OpenUSD) which I build independently with python 3.11, and whose libraries depend on libpython3.11.dylib. But when I run otool -l on libpython3.11.dylib that I get (from here, I found) , I get, in part:

Load command 4
          cmd LC_ID_DYLIB
      cmdsize 64
         name /install/lib/libpython3.11.dylib (offset 24)
   time stamp 1 Wed Dec 31 16:00:01 1969
      current version 3.11.0
compatibility version 3.11.0

Eventually, this causes a runtime crash, because that path doesn't exist. Seems to me that a library that is part of a standalone distribution ought to be relocatable (and thus I'd expect @rpath/libpython3.11.dylib for LC_ID_DYLIB). Unless I'm going down the entirely wrong path.

Thanks in advance.

[nicholasjng]

Hey! Not sure if you're still stuck on this, but I sent a patch that got merged back in August to reset the LC_ID_DYLIB field using install_name_tool in #2089. (NB: Since install_name_tool is part of the Mac toolchain, this will not work when cross-compiling for MacOS on non-Macs, which I'm not even sure is possible.)

This patch turned out to be buggy, since it just replaced the absolute path you are seeing with the absolute path to libpython3.X.dylib on the build host. As you mention, setting it to @rpath/libpython3.X.dylib is the right fix, which got merged in #2256.

I don't think that has made it into a release yet, but using rules_python from main should fix the issue.

[rao94583]

Thanks for the fix. It turned out that I didn't have to do any of these install_name_tool shenanigans for OpenUSD, where the following extra flag to the build script made everything work OK (posting in case someone else goes down the exact same rabbit hole):
--cmake-build-args="-DPXR_PY_UNDEFINED_DYNAMIC_LOOKUP=ON"