Compile error in checkComputeCppIsSupported() function

[mirh]

If I comment the thing in def main(), everything works properly.

---

System information

• OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Manjaro 17.1
• TensorFlow installed from (source or binary): this very dev/amd_gpu branch
• Python version: 3.6.3
• Bazel version (if compiling from source): 0.7
• GCC/Compiler version (if compiling from source): 7.2.0
• GPU model and memory: radeon 6310 (yes opencl 1.2 is properly configured 😉)
• Exact error:

  ERROR: /home/user/.cache/bazel/_bazel_user/bfa925de178436ba85f27964c552631c/external/nasm/BUILD.bazel:8:1: C++ compilation of rule '@nasm//:nasm' failed (Exit 1): computecpp failed: error executing command 
  (cd /home/user/.cache/bazel/_bazel_user/bfa925de178436ba85f27964c552631c/execroot/org_tensorflow && \
  exec env - \
  PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl \
  PWD=/proc/self/cwd \
  external/local_config_sycl/crosstool/computecpp -fPIE -fno-omit-frame-pointer -Wall -g0 -O2 -DNDEBUG -ffunction-sections -fdata-sections -g0 -DGEMMLOWP_ALLOW_SLOW_SCALAR_FALLBACK -MD -MF bazel-out/host/bin/external/nasm/_objs/nasm/external/nasm/output/outdbg.d -DHAVE_SNPRINTF -iquote external/nasm -iquote bazel-out/host/genfiles/external/nasm -iquote external/bazel_tools -iquote bazel-out/host/genfiles/external/bazel_tools -isystem external/bazel_tools/tools/cpp/gcc3 -w '-std=c99' -Wno-builtin-macro-redefined '-D__DATE__="redacted"' '-D__TIMESTAMP__="redacted"' '-D__TIME__="redacted"' -c external/nasm/output/outdbg.c -o bazel-out/host/bin/external/nasm/_objs/nasm/external/nasm/output/outdbg.o).
  /opt/ComputeCpp-CE-0.5.0-Ubuntu-16.04-64bit/bin/compute++: /usr/lib/libtinfo.so.5: no version information available (required by /opt/ComputeCpp-CE-0.5.0-Ubuntu-16.04-64bit/bin/compute++)
  Traceback (most recent call last):
  File "external/local_config_sycl/crosstool/computecpp", line 122, in <module>
  sys.exit(main())
  File "external/local_config_sycl/crosstool/computecpp", line 118, in main
  checkComputeCppIsSupported()
  File "external/local_config_sycl/crosstool/computecpp", line 70, in checkComputeCppIsSupported
  outputList = check_output([COMPUTECPP_DRIVER, '--version']).split(" ")
  TypeError: a bytes-like object is required, not 'str'
  Target //tensorflow/tools/pip_package:build_pip_package failed to build

[lukeiwanski]

Hey @mirh thanks for the report!

It seems like python 3.6.3 picks on subprocess not decoding the output before split: https://stackoverflow.com/questions/45983589/typeerror-a-bytes-like-object-is-required-not-str-in-subprocess-check-output

Can you give this commit a spin: https://github.com/lukeiwanski/tensorflow/commit/6631d9c054c9b0531e8f9fd89031bb7f0c4612e1

[DuncanMcBain]

Hi @mirh, Are you running on Arch by any chance? Looking just now, I see I should read more closely - you're using Manjaro. Arch-like systems have historically had two problems with our stuff, which are both on display here. Firstly, the hard error is that Arch and its derivatives default to Python 3, not Python 2 (which is probably a good idea). I see Luke has a possible fix for that.

Otherwise, the thing about libtinfo.so is that Arch and friends have a newer version by default than most other distributions, if you find the legacy libtinfo-5 package in pacman I think that should make the error go away, IIRC (I've used Arch in the past and had to fix similar problems, but it was a decent while ago).

[mirh]

Don't worry, computecpp package maintainer has been smart enough to add ncurses5-compat-libs as a dependency. (a pity you have to manually download ccpp tarball though :\)

Anyway, will try that commit - as soon as my potato has ended current compilation (yes, it's still running since before I reported this)

[mirh]

Yup, fixed. (also, still compiling the other)

[mirh]

The no version information available warning information is still there though. Not sure if anything could be done for it.

EDIT: solved by compiling ncurses with --with-versioned-syms configure switch

[lukeiwanski]

can you paste /opt/ComputeCpp-CE-0.5.0-Ubuntu-16.04-64bit/bin/compute++ --version output ?

[mirh]

/opt/ComputeCpp-CE-0.5.0-Ubuntu-16.04-64bit/bin/compute++: /usr/lib/libtinfo.so.5: no version information available (required by /opt/ComputeCpp-CE-0.5.0-Ubuntu-16.04-64bit/bin/compute++)
Codeplay ComputeCpp - CE 0.5.0 Device Compiler - clang version 3.9.0 (git@git.office.codeplay.com:sycl/clang.git cd9ced1d65233773a97089ca434f0369b8371cce) (git@git.office.codeplay.com:sycl/llvm.git d84be3e43470fcd53a94857c5c7344fb49ac0991) (based on LLVM 3.9.0svn)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /opt/ComputeCpp-CE-0.5.0-Ubuntu-16.04-64bit/bin

[lukeiwanski]

Ok, are you up for some remote debugging? :) ( I cannot reproduce locally )

Could you add print(cpp_version) after https://github.com/lukeiwanski/tensorflow/blob/dev/amd_gpu/third_party/sycl/crosstool/computecpp.tpl#L72 ?

That should print 0.5.0 but I do wonder if the decode('utf-8') is doing what it suppose

[mirh]

My teapot is always up for hard screwing.

Anyway - I'm not sure why looking into TF, when "no version information available" string was also returned by 'standalone' compute++ ?

[lukeiwanski]

Ah, I misunderstood the no version information available post, sorry! @DuncanMcBain did you guys ever encounter this? /opt/ComputeCpp-CE-0.5.0-Ubuntu-16.04-64bit/bin/compute++: /usr/lib/libtinfo.so.5: no version information available (required by /opt/ComputeCpp-CE-0.5.0-Ubuntu-16.04-64bit/bin/compute++)

[DuncanMcBain]

I've seen it before, but it's probably harmless. Unless actual crashes are happening and can be traced to this, I don't think there's anything we need to do about it (it would involve compiling and linking with the same or higher version of libtinfo on your machine, but we don't really have the resources or desire to set that up right now).

[mirh]

Cool. Speaking of crashes - where should I report one happening somewhere between libComputeCpp.so and libamdocl64.so ?

[DuncanMcBain]

To me, basically. You can either use the ComputeCpp SDK tracker or the Jira we have accessible through our website, but I'll look at either.