Bazel fails to compile itself from the directory that has non-ASCII characters in its name

[frp]

Description of the problem / feature request / question:

I've unpacked bazel-0.4.4-dist.zip into /mnt/debhome/roman/roman/Завантаження/Розробка (Cyrillic characters in the path), and run ./compile.sh from there. Output:

[roman@localhost Розробка]$ ./compile.sh 
INFO: You can skip this first step by providing a path to the bazel binary as second argument:
INFO:    ./compile.sh compile /path/to/bazel
🍃  Building Bazel from scratch.......
🍃  Building Bazel with Bazel.
.WARNING: /tmp/bazel_gfUg55vB/out/external/bazel_tools/WORKSPACE:1: Workspace name in /tmp/bazel_gfUg55vB/out/external/bazel_tools/WORKSPACE (@io_bazel) does not match the name given in the repository's definition (@bazel_tools); this will cause a build error in future versions.
INFO: Found 1 target...
ERROR: /mnt/debhome/roman/roman/????????????/????????/src/BUILD:92:5: Executing genrule //src:dummy_darwin_tool_src_tools_xcode_libtool_make_hashed_objlist.py failed: bash failed: error executing command 
  (cd '/tmp/bazel_gfUg55vB/out/execroot/????????' && \
  exec env - \
    PATH=/home/roman/.nix-profile/bin:/home/roman/.nix-profile/sbin:/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/home/roman/opt/rust/bin:/home/roman/go/bin:/home/roman/.local/bin:/home/roman/bin:/home/roman/opt/cross/bin:/home/roman/opt/rust/bin:/home/roman/go/bin \
  /bin/bash -c 'source external/bazel_tools/tools/genrule/genrule-setup.sh; touch bazel-out/local-opt/genfiles/src/dummy_darwin_tools/src/tools/xcode/libtool/make_hashed_objlist.py'): java.io.IOException: Cannot run program "/tmp/bazel_gfUg55vB/out/execroot/????????/_bin/process-wrapper" (in directory "/tmp/bazel_gfUg55vB/out/execroot/????????"): error=2, No such file or directory.
Target //src:bazel failed to build
INFO: Elapsed time: 27,744s, Critical Path: 1,88s

ERROR: Could not build Bazel

Works fine when I run it from the location that only has ASCII characters in name.

Environment info

• Operating System:

Fedora 25

• Bazel version (output of bazel info release):

0.4.4

[iirina]

This is a known issue under investigation.

@damienmg, @philwo do you know anything about the progress status on this?

[damienmg]

Encoding issue :) passing the potato to @philwo :)

[philwo]

@frp Thanks for your report! I would love to debug / fix this problem. I need some more information about this to make sure that the fix will work in your environment.

• Could you please send the output of "locale"? It should print some information about the LANG= and LC_*= env vars on your system.
• Do the paths with non-ASCII characters when printed by Bazel really show as "??????"? Or are they shown correctly and readable? (Just making sure that this is a Bazel issue and wasn't lost on the way from your terminal to GitHub.)
• When you view those paths with "ls", are they shown correctly and readable? Or also as "??????"?

[frp]

locale:

LANG=uk_UA.UTF-8
LC_CTYPE="uk_UA.UTF-8"
LC_NUMERIC="uk_UA.UTF-8"
LC_TIME="uk_UA.UTF-8"
LC_COLLATE="uk_UA.UTF-8"
LC_MONETARY="uk_UA.UTF-8"
LC_MESSAGES="uk_UA.UTF-8"
LC_PAPER="uk_UA.UTF-8"
LC_NAME="uk_UA.UTF-8"
LC_ADDRESS="uk_UA.UTF-8"
LC_TELEPHONE="uk_UA.UTF-8"
LC_MEASUREMENT="uk_UA.UTF-8"
LC_IDENTIFICATION="uk_UA.UTF-8"
LC_ALL=

Bazel prints the paths as ???????, you can see that terminal displays the same characters in $PS1 just fine.

ls, just like all other tools, displays the paths correctly.

[davispuh]

This is still present and bazel doesn't work at all when current working directory contains non-ASCII characters.

On ArchLinux with OpenJDK 10 and LANG=lv_LV.UTF-8

$ pwd
/tmp/Viesis
$ bazel --client_debug version
[bazel INFO src/main/cpp/option_processor.cc:359] Looking for the following rc files: /etc/bazel.bazelrc,/tmp/Viesis/.bazelrc
[bazel INFO src/main/cpp/blaze.cc:1552] Debug logging requested, sending all client log statements to stderr
[bazel INFO src/main/cpp/blaze.cc:1572] Acquired the client lock, waited 0 milliseconds
[bazel INFO src/main/cpp/blaze.cc:727] Starting Bazel in batch mode.
[bazel INFO src/main/cpp/blaze_util_posix.cc:226] Invoking binary /usr/lib/jvm/java-10-openjdk/bin/java in /tmp/Viesis
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.google.protobuf.UnsafeUtil (file:/tmp/Viesis/.cache/bazel/_bazel_Viesis/install/90846db665bd444d85cd9a305cffe931/_embedded_binaries/A-server.jar) to field java.nio.Buffer.address
WARNING: Please consider reporting this to the maintainers of com.google.protobuf.UnsafeUtil
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
WARNING: --batch mode is deprecated. Please instead explicitly shut down your Bazel server using the command "bazel shutdown".
INFO: Invocation ID: 02647db7-824c-456e-bf8a-e742d73208ca
Build label: 0.21.0- (@non-git)
Build target: bazel-out/k8-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Thu Dec 20 19:15:52 2018 (1545333352)
Build timestamp: 1545333352
Build timestamp as int: 1545333352
$ mkdir tēst
$ cd tēst/
bazel --client_debug version
[bazel INFO src/main/cpp/option_processor.cc:359] Looking for the following rc files: /etc/bazel.bazelrc,/tmp/Viesis/.bazelrc
[bazel INFO src/main/cpp/blaze.cc:1552] Debug logging requested, sending all client log statements to stderr
[bazel INFO src/main/cpp/blaze.cc:1572] Acquired the client lock, waited 0 milliseconds
[bazel INFO src/main/cpp/blaze.cc:727] Starting Bazel in batch mode.
[bazel INFO src/main/cpp/blaze_util_posix.cc:226] Invoking binary /usr/lib/jvm/java-10-openjdk/bin/java in /tmp/Viesis/tēst
Error: LinkageError occurred while loading main class com.google.devtools.build.lib.bazel.Bazel
        java.lang.ExceptionInInitializerError: null

[sgowroji]

Hi there! We're doing a clean up of old issues and will be closing this one. Please reopen if you’d like to discuss anything further. We’ll respond as soon as we have the bandwidth/resources to do so.