bazel @0.18.0: error: no type named 'unique_ptr' in namespace 'std'

[ryandesign (Ryan Carsten Schmidt)]

​bazel fails to build on 10.8 and earlier:

In file included from src/main/cpp/util/strings.cc:14:
./src/main/cpp/util/strings.h:117:6: error: no type named 'unique_ptr' in namespace 'std'
std::unique_ptr<char[]> WstringToCstring(const wchar_t *input);
~~~~~^

Sounds like it may need the cxx11 1.1 portgroup at least.

[cjones051073 (Chris Jones)]

It already uses the cxx11 portgroup. Please check the portfile. Getting bazel to use Macports own compiler was enough of a headache ;)

The issue is the use of the flag -std=c++0x

external/local_config_cc/cc_wrapper.sh -U_FORTIFY_SOURCE -fstack-protector -Wall -Wthread-safety -Wself-assign -fcolor-diagnostics -fno-omit-frame-pointer -g0 -O2 '-D_FORTIFY_SOURCE=1' -DNDEBUG -ffunction-sections -fdata-sections '-std=c++0x' -MD -MF bazel-out/darwin-opt/bin/src/main/cpp/util/_objs/strings/strings.d '-frandom-seed=bazel-out/darwin-opt/bin/src/main/cpp/util/_objs/strings/strings.o' -DBLAZE_OPENSOURCE -iquote . -iquote bazel-out/darwin-opt/genfiles -iquote bazel-out/darwin-opt/bin -iquote external/bazel_tools -iquote bazel-out/darwin-opt/genfiles/external/bazel_tools -iquote bazel-out/darwin-opt/bin/external/bazel_tools -no-canonical-prefixes -Wno-builtin-macro-redefined '-D__DATE__="redacted"' '-D__TIMESTAMP__="redacted"' '-D__TIME__="redacted"' -c src/main/cpp/util/strings.cc -o bazel-out/darwin-opt/bin/src/main/cpp/util/_objs/strings/strings.o)

that needs to be at least c++11 for unique_ptr.

I have no idea why this only happens on 10.8, whereas 10.9 which is also using Macports clang 5.0 seems OK.

[ryandesign (Ryan Carsten Schmidt)]

Sorry, you're right, I didn't look at the portfile, only at the error message.

The cxx11 1.1 portgroup can only work if the portfile uses the compiler and cxxflags that MacPorts tells it to. Looks like bazel might not be passing configure.cxxflags on to the build—that's where the -stdlib flag that tells it what C++ library to use would be found. The default C++ library on 10.9 and later supports C++11 while the one on 10.8 and earlier doesn't.

I haven't found there to be any particular difference between specifying c++0x or c++11, but maybe in some cases there is.

[cjones051073 (Chris Jones)]

bazel probably does everything differently to any other build system you might have looked at.

It *really* wants to control everything itself, including the compiler selection, build options and dependencies. Its very very tough to get it to change its mind on these things.

One thing I did try is I pushed an update to to forcibly (via a reinplace) change all c++0x in the source to c++11. That got things a little further on 10.8 bit it still fails.

To be frank, it was enough of an effort to get things build down to 10.9. I'm happy with that, and if someone else comes along who has an interest in fixing bazel in older systems, they are more than welcome to try. My interest in bazel only stems from the fact I needed it to provide a py-tensorflow port that builds from source itself.

[ryandesign (Ryan Carsten Schmidt)]

If bazel gives you no other place to specify the cxxflags, you could easily put them after the -std=c++11 flag in that reinplace.

[cjones051073 (Chris Jones)]

Just to illustrate how hard it is to deal with bazel, just read the discussion at

​https://github.com/bazelbuild/bazel/issues/5198

[cjones051073 (Chris Jones)]

I suspect the reinplace does not change things for every build target. Just those that happen to use some default values in a few places. I can try it, but I am betting it will not work.

[kencu (Ken)]

The last bazel I built easily on 10.6.8 was 0.9.0, so I did this in my SnowLeopardPorts repo of pegged ports:

# peg bazel at 0.9.0 for older systems
if { ${os.platform} eq "darwin" && ${os.major} < 11 } {
    github.setup              bazelbuild bazel 0.9.0
    checksums                 rmd160  5cb89e5598a2c27c8ce6c30bad9107f67d7547ee \
                              sha256  efb28fed4ffcfaee653e0657f6500fc4cbac61e32104f4208da385676e76312a
}

I haven't looked at it recently to see if I can get some newer system to build it. You're right, bazel is a total bear to sort out.

[cjones051073 (Chris Jones)]

Comparing bazel to a bear is frankly impolite to the bear ;)

Just out of curiosity, what lead you to need to use bazel on 10.6 in the first place ? Until I updated py-tensorflow to use it, nothing else in MacPorts did (thankfully).

[kencu (Ken)]

tensorflow, indeed.

I have this broken bone about keeping old systems working smoothly. Did I mention I have both a Mac SE/30 and MacII si on my desk, working perfectly?

[ryandesign (Ryan Carsten Schmidt)]

Replying to cjones051073:

Just out of curiosity, what lead you to need to use bazel on 10.6 in the first place ? Until I updated py-tensorflow to use it, nothing else in MacPorts did (thankfully).

I was monitoring build failures on the Buildbot. I saw this one and wanted to report it to you.

[chrstphrchvz (Christopher Chavez)]

This ticket was reported for a relatively ancient version of bazel (0.18.0); the bazel port is now at 4.1.0, and the oldest version in MacPorts is in the bazel-0.25 port. I’m not aware of there even being a version of bazel in MacPorts which supports building on anything earlier than macOS 10.10. Can this ticket be closed (or is the purpose of this ticket for requesting a bazel that builds on older macOS)?

[cjones051073 (Chris Jones)]

yes, it can be closed.