cc_import mangles shared library name on Linux but not on MacOS

[Arun Rao]

I have a cc_import rule that looks like this, on both platforms:

cc_import(
    name = "usd_ar",
    hdrs = glob(["include/pxr/usd/ar/*.h"]),
    includes = ["external/OpenUSD_Ubuntu/include"],
    shared_library = "lib/libusd_ar.so",
    deps = [
        ":usd_arch",
        ":usd_gf",
        ":usd_js",
        ":usd_plug",
        ":usd_tf",
        ":usd_trace",
        ":usd_vt",
        ":usd_work",
    ],
)

except that they are dylibs instead of so's on MacOS.

I see that the library my code actually links against is

<long temp path>/external/OpenUSD_MacOS/lib/libusd_plug.dylib

on MacOS and

<long temp path>/bazel-out/k8-fastbuild/bin/_solib_k8/_U@@OpenUSD_UUbuntu_S_S_Cusd_Uplug___Ulib/libusd_plug.so

on Linux.

In other words, the file is copied into a special location on Linux but is left alone on the Mac.  For complicated reasons, I would very much prefer the MacOS behavior.  Is there any way to do this?

Thanks in advance.

[Filip Filmar]

Probably has to do with sandboxing differences?

But, and I think this needs to be said, if you need to care about the exact output path of a build artifact, I would offer that whatever it is you are trying to do, should be done differently.

F

--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/008a21b9-ffe8-4402-b596-364b16c9924an%40googlegroups.com.

[Arun Rao]

Yeah, I don't disagree.  The culprit in this case is OpenUSD, whose plugin discovery mechanism depends on knowing the path to the shared object in order to determine the relative locations of plugin publication manifests.

I worked around the problem by rebuilding the OpenUSD distribution with a CPP symbol definition that tells the distribution where it is installed (rather than built).

Still, it's a bit mysterious that bazel does different things on MacOS and Linux.

[Filip Filmar]

On Mon, Aug 26, 2024 at 1:34 PM Arun Rao <arun....@gmail.com> wrote:

Yeah, I don't disagree.  The culprit in this case is OpenUSD, whose plugin discovery mechanism depends on knowing the path to the shared object in order to determine the relative locations of plugin publication manifests.

I worked around the problem by rebuilding the OpenUSD distribution with a CPP symbol definition that tells the distribution where it is installed (rather than built).

If you need a predictable artifact location, perhaps you should use `pkg` or something to build a distribution of the artifact in the form that is needed for you, instead of trying to guess.

I have been somewhat successful with a simplistic approach of passing `$(location :artifact)` as a flag when running an binary. Not sure if that is an option for you.

F
 

[Arun Rao]

You can kinda do that (passing in the location to the binary) via an environment variable.  But I really didn’t want users of every binary compiled against OpenUSD to have to do that.

If I could build OpenUSD from source within bazel, that would solve most problems, but that’s a bear of a project …

-Arun

[Jiawen Chen]

Agreed. I'm curious what your use case is such that you care about the output path and that they need to match between platforms.

-Jiawen

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/CAKaOXiho_T8xHm_7PPxs1wz4tz8R4bV0DATjAqq-D0_%3DzxzNuQ%40mail.gmail.com.