Thanks. Please see https://trac.macports.org/ticket/64442.
> On Jan 14, 2022, at 08:30, Christopher Jones <jon...@hep.phy.cam.ac.uk> wrote:
>
>
>
> please open a trac ticket and we will discuss there. better than a mailing
> list.
>
>> On 14 Jan 2022, at 11:55 am, Steven Smith <steve.t.sm...@gmail.com> wrote:
>>
>> Chris, Thanks, and concur on the wonderfulness of bazel.
>>
>> To be clear, I am not building bazel-3.7 here. I am building
>> py38-tensorflow-metadata, which uses bazel-3.7. I’ve attached the log file.
>> It was produced with a build (please see attached Portfile) that adds
>> `bazel.build_opts-append --sandbox_debug`, not that I see that helping a
>> diagnosis.
>>
>> FWIW, I looked in the binary /opt/local/libexec/bazel-3.7/bin/bazel for the
>> string “_opt_bblocal_var_buildworker_ports_build_ports_devel_bazel” but it’s
>> not there, at least not in plain text. I have no idea how this path is being
>> introduced at the build stage.
>>
>>
>> Attachments:
>> <main.log.xz>
>> <Portfile>
>>
>>
>>
>>>> On Jan 14, 2022, at 2:52 AM, Christopher Jones <jon...@hep.phy.cam.ac.uk>
>>>> wrote:
>>>>
>>>>
>>>
>>>> On 14 Jan 2022, at 3:14 am, Steven Smith <steve.t.sm...@gmail.com> wrote:
>>>>
>>>> I’m trying to build/update py-tensforflow-metadat and am hitting this
>>>> (bizarre) bazel issue.
>>>>
>>>> First, the build fails with the error:
>>>>
>>>>> :info:build Execution platform: @local_config_platform//:host
>>>>> :info:build Use --sandbox_debug to see verbose messages from the sandbox
>>>>> :info:build xcrun: error: can't exec
>>>>> '/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_devel_bazel/bazel-3.7/work/bazelwrap/cc'
>>>>> (errno=No such file or directory)
>>>>
>>>>
>>>> Weird that bazel wants to look in a MacPorts build directory.
>>>>
>>>> Searching for this string in ${worksrcpath}, it appears in the file
>>>> created during the build stage:
>>>>
>>>> ${worksrcpath}/bazel_build/install/<hash>/embedded_tools/tools/osx/crosstool/wrapped_clang.cc:
>>>>
>>>>> if (binary_name == "wrapped_clang_pp") {
>>>>> tool_name =
>>>>> "/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_devel_bazel/bazel-3.7/work/bazelwrap/cxx";
>>>>> } else if (binary_name == "wrapped_clang") {
>>>>> tool_name =
>>>>> "/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_devel_bazel/bazel-3.7/work/bazelwrap/cc";
>>>>
>>>> This is not the file from
>>>> https://github.com/bazelbuild/bazel/blob/master/tools/osx/crosstool/wrapped_clang.cc
>>>>
>>>> I’m stumped. Does anyone have insight on what’s causing this weird bazel
>>>> build issue?
>>>>
>>>
>>> The above is intentional, and performed by the bazel build to (attempt) to
>>> work around issues with the bazel build on older systems, which is
>>> spectacularly difficult to work with . Specifically see
>>>
>>> https://github.com/macports/macports-ports/blob/6569ac3bcc84a00f72513d0f8ceebb6b6cec1576/devel/bazel/Portfile#L259
>>>
>>> why you see the above I cannot say. Please also post a complete log, not
>>> just snippets like above.
>>>
>>> is there a specific reason you are building bazel-3.7 from source ? binary
>>> tarballs are availing for 10.11 and newer
>>>
>>> https://ports.macports.org/port/bazel-3.7/details/
>>>
>>> Chris
>>>
>>>
>>
>
