Calling Bazel 0.4.3 on Windows yields no output #2431

abergmeier-dsfishlabs · 2017-01-26T10:30:53Z

Description of the problem / feature request / question:

On a fairly clean Windows installation I now try to get Bazel to work. When calling Bazel though, I get no output whatsoever.

If possible, provide a minimal example to reproduce the problem:

Environment is:

BAZEL_SH = C:/msys64/usr/bin/bash.exe
PATH = C:\msys64\usr\bin
JAVA_HOME = C:\jre

On the environment I execute:

 C:\bazel\bazel.exe info

Environment info

Operating System: Windows 10
Bazel version (output of bazel info release): 0.4.3

Have you found anything relevant by searching the web? (e.g. GitHub issues, email threads in the bazel-discuss@googlegroups.com archive)

Nope

The text was updated successfully, but these errors were encountered:

laszlocsomor · 2017-01-26T10:45:31Z

What immediately stands out to me is, I believe bazel still needs MSYS to be installed under c:\tools\msys64. Can you try that?

laszlocsomor · 2017-01-26T10:47:49Z

You could just create a junction: c:\tools\msys64 => c:\msys64, that should work.

abergmeier-dsfishlabs · 2017-01-26T10:52:38Z

What immediately stands out to me is, I believe bazel still needs MSYS to be installed under c:\tools\msys64.

Can you be a little more specific?
I DO have msys64 installed in c:\tools\msys64. I copied it to C:\msys64 to see whether I can use alternate paths.

abergmeier-dsfishlabs · 2017-01-26T10:56:01Z

Changed Environment to:

PATH = C:\tools\msys64\usr\bin;
BAZEL_SH = C:/tools/msys64/usr/bin/bash.exe

still no change in behavior.

abergmeier-dsfishlabs · 2017-01-26T11:05:43Z

Exit code is 3221225785 if that helps any.

laszlocsomor · 2017-01-26T12:22:08Z

Thanks! Are you running this from under msys shell or cmd.exe?

That exit code is 0xc0000139. A shot in the dark: maybe something (msys?) mangles the exit code, indicated by the high-order word 0xc000, and the low-order word 0x0139 is the actual exit code? If that's the case, then it'd be error 313, aka ERROR_NOT_ALLOWED_ON_SYSTEM_FILE:

ERROR_NOT_ALLOWED_ON_SYSTEM_FILE
313 (0x139)
Operation is not allowed on a file system internal file.

(Source https://msdn.microsoft.com/en-us/library/windows/desktop/ms681382(v=vs.85).aspx)

Hm... maybe bazel is trying to write in the default temp directory, which is %windir%\temp. Strangely on my machine (Windows 10) that directory is inaccessible [1]. Try running bazel with --output_user_root=/c/tmp1 and let me know if it helps!

[1] well, I can create a file there, but cannot access it, nor can I list the directory's contents

abergmeier-dsfishlabs · 2017-01-26T13:00:31Z

Try running bazel with --output_user_root=/c/tmp1 and let me know if it helps!

No change in behavior.

I execute Bazel via python subprocess. Looking into ntstatus.h, 0xc0000139 should be STATUS_ENTRYPOINT_NOT_FOUND.
When I directly run inside a bat file it returns the exit code -1073741511/3221225785/0xc0000139.
When I forget the msys in PATH the exit code is -1073741515. Which when converted to unsigned would be 3221225781. Which seems to be STATUS_DLL_NOT_FOUND.

Which leads me to believe that somewhere in the loading of dependencies there is some botched error handling perhaps?

laszlocsomor · 2017-01-26T13:06:24Z

Maybe msys is not your path?

abergmeier-dsfishlabs · 2017-01-26T13:08:28Z

Maybe msys is not your path?

That was indeed the problem for my bat test. Now I have the same exit code in both :)

laszlocsomor · 2017-01-26T13:23:30Z

The 0.4.3 exe on https://github.com/bazelbuild/bazel/releases/download/0.4.3/bazel-0.4.3-windows-x86_64.exe should definitely be good.

To rule out all problems (my cwd is /c/tempdir/cleanbazel):

open msys
clone the bazel repo

mkidr -p /c/tempdir/cleanbazel
cd /c/tempdir/cleanbazel
git clone https://github.com/bazelbuild/bazel.git

download the exe

wget https://github.com/bazelbuild/bazel/releases/download/0.4.3/bazel-0.4.3-windows-x86_64.exe

set the BAZEL_SH and JAVA_HOME envvars as you did before
create an empty file that'll be our bazelrc (--bazelrc=/dev/null was buggy for a while):

touch /c/tempdir/cleanbazel/empty.txt

create an empty directory for the output root

mkdir -p /c/tempdir/cleanbazel/outputroot

run bazel like so:

 /c/tempdir/cleanbazel/bazel-0.4.3-windows-x86_64.exe --nomaster_bazelrc --bazelrc=/c/tempdir/cleanbazel/empty.txt --output_user_root=/c/tempdir/cleanbazel/outputroot build src:bazel

laszlocsomor · 2017-01-26T13:29:58Z

My previous comment is a reply to your IRC question:

[14:02] <abergmeier> laszlocsomor, do you have a "working" Bazel windows build that you could send me?
[14:05] <@laszlocsomor> regarding #2431?
[14:05] <abergmeier> For example
[14:07] <@laszlocsomor> i don't know yet what's wrong there.. by working windows build, do you mean a bazel command that should work, or my env info, or something else?
[14:09] <abergmeier> A bazel binary that works for you. dmarting, said it should "work fine" by now. For one 0.4.3 is a bit old but then again dmarting seems overly optimistic ;)

abergmeier-dsfishlabs · 2017-01-26T13:44:27Z

Usually I open cmd/call the bat from mingw. Now running in a "pure" cmd gives an actual error dialog:

---------------------------
bazel.exe - Entry Point Not Found
---------------------------
The procedure entry point __locale_ctype_ptr could not be located in the dynamic link library C:\Projects\tools\third_party\bazel\win_x86_64\bazel.exe. 
---------------------------
OK   
---------------------------

For some reason seems like the dialog gets surpressed by mingw 😕 .
Even following your steps to 7. I still get the error dialog (with the location of bazel.exe changing of course).

laszlocsomor · 2017-01-26T14:12:01Z

Hmmm, can you download the distribution archive (https://github.com/bazelbuild/bazel/releases/download/0.4.3/bazel-0.4.3-dist.zip) and run ./compile.sh? Does that yield a working binary?

abergmeier-dsfishlabs · 2017-01-26T14:47:00Z

Hmmm, can you download the distribution archive (https://github.com/bazelbuild/bazel/releases/download/0.4.3/bazel-0.4.3-dist.zip) and run ./compile.sh
Yes

Does that yield a working binary?

No.
But Bazel itself runs fine. Later compilation fails with some static import error in *.java.
So seems like ./compile.sh is doing some magic that I don't.

laszlocsomor · 2017-01-26T14:53:28Z

I'm confused, so does compile.sh finish and the resulting binary is broken, or does it fail while "compiling bazel with bazel"?

abergmeier-dsfishlabs · 2017-01-26T14:56:38Z

I'm confused, so does compile.sh finish and the resulting binary is broken, or does it fail while "compiling bazel with bazel"?

The latter.

laszlocsomor · 2017-01-26T14:57:06Z

Can you paste the output?

abergmeier-dsfishlabs · 2017-01-26T15:39:34Z

Can you paste the output?

Error output of the second run: http://pastebin.com/Tu9v07N7

laszlocsomor · 2017-01-26T15:48:47Z

@aehlig : we're seeing errors like this in compile.sh:

C:\Users\a.bergmeier\AppData\Local\Temp\bazel_wflAyq4F\src\com\google\devtools\build\lib\remote\CasServiceGrpc.java:4: error: package io.grpc.stub does not exist
import static io.grpc.stub.ClientCalls.asyncServerStreamingCall;

Do you have an idea what could be going on? I remember we had a similar problem once.

dslomov · 2017-01-26T16:30:05Z

I think your PATH contains some incompatible msys-2.0.dll, like in #1919

abergmeier-dsfishlabs · 2017-01-26T16:44:40Z

I think your PATH contains some incompatible msys-2.0.dll

You are probably right. I did clean PATH for the frontend - but the server will probably be using the System-PATH 😢.
So 2 things:

when are you getting rid of msys dependency?
if not soonish perhaps make an option to force (re-)starting the Server with the same environment as the frontend.

laszlocsomor · 2017-01-26T16:47:11Z

when are you getting rid of msys dependency?

SoooOOOoooon! ^{if only ^{i didn't have to sheriff}}

But really, end of February is a realistic goal.

abergmeier-dsfishlabs · 2017-01-26T16:55:22Z

@dslomov I now double-checked. There is a second msys-2.0.dll in C:\Program Files\Git\usr\bin but it is not in any PATH! So while I would not rule out that you are right - I am wondering where it gets the reference to this one?

And according to the version info msys64 has a 2.4.1 vs 2.6.1 in git.

abergmeier-dsfishlabs · 2017-01-27T09:15:20Z

Executing

echo $(where msys-2.0.dll)

in MinGW Win64 Shell gives me:

C:\tools\msys64\usr\bin\msys-2.0.dll

So I seriously have no idea where a potential DLL problem may come from.

abergmeier-dsfishlabs · 2017-01-27T12:13:19Z

Looking at bazel.exe in DependencyWalker, in msys-2.0.dll there is __locale_ctype_ptr shown as Unresolved C function. Are you sure that the msys version linked on the page can actually run 0.4.3 on Windows?

abergmeier-dsfishlabs · 2017-01-27T12:21:39Z

Looking at the msys-2.0.dll which comes with git it seems to contain all imported symbols. It does however not have a MSYS-STDC++-6.dll.

laszlocsomor · 2017-01-27T12:23:49Z

Yes, I have MSYS2 20160205 installed on Windows 10 (version 1511, build 10586.753) on a 64-bit machine, and https://github.com/bazelbuild/bazel/releases/download/0.4.3/bazel-0.4.3-windows-x86_64.exe works fine.

abergmeier-dsfishlabs · 2017-01-27T12:25:32Z

@laszlocsomor Can you open bazel-0.4.3-windows-x86_64.exe in DependencyWalker please and check whether all PI are resolved.

laszlocsomor · 2017-01-27T12:28:13Z

It says:

Error: At least one required implicit or forwarded dependency was not found.
Warning: At least one delay-load dependency module was not found.

What is "PI"? What should I be looking for exactly?

laszlocsomor · 2017-01-27T12:29:32Z

When you open bazel-0.4.3-windows-x86_64.exe in DependencyWalker and toggle "View > Full paths", what path does msys-2.0.dll appear under?

abergmeier-dsfishlabs · 2017-01-27T15:19:24Z

When you open bazel-0.4.3-windows-x86_64.exe in DependencyWalker and toggle "View > Full paths", what path does msys-2.0.dll appear under?

See .

abergmeier-dsfishlabs · 2017-01-27T15:20:40Z

What is "PI"? What should I be looking for exactly?

PI are the Parent Imports - symbols that Bazel is expecting in this case.

laszlocsomor · 2017-01-27T15:23:20Z

Ok, sanity check:

$ du -b /usr/bin/msys-2.0.dll
3293824 /usr/bin/msys-2.0.dll

$ md5sum /usr/bin/msys-2.0.dll
01d681a3e4f1cfa48c3982a4ac807dda */usr/bin/msys-2.0.dll

laszlocsomor · 2017-01-27T15:23:53Z

laszlocsomor · 2017-01-27T15:25:58Z

And of course

$ md5sum $(which md5sum)
e599828a5d886626340f72c4cde77d5b */usr/bin/md5sum

abergmeier-dsfishlabs · 2017-01-27T15:57:17Z

Just reinstalled msys2-x86_64-20160205.exe and the values are:

$ md5sum msys2-x86_64-20160205.exe
1aedabc07d0a7d7b9fd006e6631bfbed *msys2-x86_64-20160205.exe

$ du -b /usr/bin/msys-2.0.dll
3427279 /usr/bin/msys-2.0.dll

$ md5sum /usr/bin/msys-2.0.dll
73f4b3f705c09376237264246f7b50f9 */usr/bin/msys-2.0.dll

$ md5sum $(which md5sum)
c55279011836d31cd269c91a2f6b1c12 */usr/bin/md5sum

@laszlocsomor I imagine your installation was pacmanified?

Doing pacman -Syuu gcc git curl zip unzip zlib-devel (answer all to Y), I get tons of scary cygwin dll errors! I do not like this. Afterwards the values are:

$ du -b /usr/bin/msys-2.0.dll
3293934 /usr/bin/msys-2.0.dll

$ md5sum /usr/bin/msys-2.0.dll
8204f1e60a6babeeeebb48a830e223de */usr/bin/msys-2.0.dll

$ md5sum $(which md5sum)
e599828a5d886626340f72c4cde77d5b */usr/bin/md5sum

So doing pacman without specific version is a bad idea ™️, because we cannot validate anything.
After that all PI in DependencyWalker are shown as found!
And Bazel writes to stdout and stderr like it should 🙌 .

So takeaway from this:

https://bazel.build/versions/master/docs/windows.html is wrong. You cannot run Bazel with the linked minimal msys2 version! Please link a newer one and test it with 0.4.4 (hint - could not install latest msys2 distribution).
I was running pacman on my previous installation. No idea what went wrong there. Probably too late to find out.
TODO: Currently have C:\tools\msys64\usr\bin in user-PATH. Will try whether it still works without that.
TODO: Will try whether it still works when moving msys to another directory.

abergmeier-dsfishlabs · 2017-01-27T16:18:07Z

If I crop the starting-process' PATH to

PATH = C:\tools\msys64\usr\bin

I get

Error: couldn't connect to server after 120 seconds.

So I assume it cannot start the server anymore.
Would be good to have actual errors reported of why the server cannot be started (probably some Windows binary not executing).

abergmeier-dsfishlabs · 2017-01-27T17:03:06Z

So I built now Bazel on Windows including our patches.

laszlocsomor · 2017-01-30T08:46:31Z

Wow, that's awesome, thank you for figuring it out and sharing your solution!

@laszlocsomor I imagine your installation was pacmanified?

I followed the instructions on https://bazel.build/versions/master/docs/windows.html#requirements when I set up my machine. That was in September 2016, I don't think I've updated the pacman packages since then. And I suppose whenever we reimage our release machine, it has the machine state from about a year ago, give or take. So it's possible that we happen to have a particular package version configuration that is no longer possible to repro. Whatever the reason, we need to update add a package update step to the release machine reimage process and update our own machines too.

So doing pacman without specific version is a bad idea ™️, because we cannot validate anything.

Yep, that's a pretty good observation.

https://bazel.build/versions/master/docs/windows.html is wrong. You cannot run Bazel with the linked minimal msys2 version!

So to clarify -- we need to move the pacman command from the compile requirements to the run requirements, correct?

Please link a newer one and test it with 0.4.4 (hint - could not install latest msys2 distribution).

"hint - could not install latest msys2 distribution" -- what do you mean?

I was running pacman on my previous installation. No idea what went wrong there. Probably too late to find out.

TODO: Currently have C:\tools\msys64\usr\bin in user-PATH. Will try whether it still works without that.

TODO: Will try whether it still works when moving msys to another directory.

I doubt it will; tools/msys64 is still hardcoded in some locations: https://github.com/bazelbuild/bazel/search?utf8=%E2%9C%93&q=tools.msys64&type=Code

abergmeier-dsfishlabs · 2017-01-30T08:53:07Z

So to clarify -- we need to move the pacman command from the compile requirements to the run requirements, correct?

Well either that or perhaps it also might work with a later msys2 version. Like I said - the cygwin errors when executing pacman are scaring the living hell out of me ;)

"hint - could not install latest msys2 distribution" -- what do you mean?

I tried to use the latest msys2 from sourceforge but could not install it. Might have been an in use dll, though so perhaps just a problem for me...

I doubt it will; tools/msys64 is still hardcoded in some locations:

That's bad. Is there an issue for this yet?

laszlocsomor · 2017-01-30T09:04:40Z

So to clarify -- we need to move the pacman command from the compile requirements to the run requirements, correct?

Well either that or just choose a later msys2 version. Like I said - the cygwin errors when executing pacman are scaring the living hell out of me ;)

Ouch.. noone should ever have to go through that :) OK, it'll be best if I reinstall MSYS and go through the pain myself; will update the installation guide accordingly.

"hint - could not install latest msys2 distribution" -- what do you mean?

I tried to use the latest msys2 from sourceforge but could not install it. Might have been an in use dll, though so perhaps just a problem for me...

Ack.

I doubt it will; tools/msys64 is still hardcoded in some locations:

That's bad. Is there an issue for this yet?

Now there is: #2447

laszlocsomor · 2017-01-30T10:41:09Z

OK, I did the following:

removed msys
Attempted this several times. The uninstaller always went to 100% quickly and just sat there. Turns out it was trying to delete about 20G of data that was my /tmp and /var/tmp directory. I terminated the uninstaller, deleted these by hand, then the uninstaller could successfully finish.
downloaded the latest version (20161025), installed it (no issues seen)
ran pacman (bazel doesn't require vim, but I do):
```
pacman -Syuu gcc git curl zip unzip zlib-devel vim
```
On the first try it printed something like "warning: close this windows, reopen msys, try running pacman again", didn't look scary. I did so, and now pacman succeeded without any errors.

I could successfully start the prebuilt bazel-0.4.3 binary, the auto-config found Python and VS, but it couldn't build bazel from source because it failed while trying to load the windows_jni.dll. There was also a "Visual Studio not found" error.

INFO: Found 1 target...
ERROR: C:/tempdir/cleanbazel/bazel/src/main/native/BUILD:75:1: Executing genrule //src/main/native:windows_jni failed: bash.exe failed: error executing command C:/tools/msys64/usr/bin/bash.exe -c ... (remaining 1 argument(s) skipped): com.google.devtools.build.lib.shell.BadExitStatusException: Process exited with status 1.
Visual Studio not found
--version-sortThe system cannot find the file specified.
ERROR: C:/tempdir/cleanbazel/bazel/src/BUILD:92:5: declared output 'src/dummy_darwin_tools/src/tools/xcode/momcwrapper/momcwrapper' was not created by genrule. This is probably because the genrule actually didn't create this output, or because the output was a directory and the genrule was run remotely (note that only the contents of declared file outputs are copied from genrules run remotely).
ERROR: C:/tempdir/cleanbazel/bazel/src/BUILD:92:5: declared output 'src/dummy_darwin_tools/src/tools/xcode/swiftstdlibtoolwrapper/swiftstdlibtoolwrapper' was not created by genrule. This is probably because the genrule actually didn't create this output, or because the output was a directory and the genrule was run remotely (note that only the contents of declared file outputs are copied from genrules run remotely).
Target //src:bazel failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 25.441s, Critical Path: 2.28s

I tried running a bazel version I built a few days ago. On the first try it failed with the following message:

$ /c/work/bazel/bazel-dev build src:bazel
Extracting Bazel installation...

Failed to write zipped file "/c/Users/LASZLO~1/AppData/Local/Temp/_bazel_laszlocsomor/install/2b15357e4568f22bb12b81a18c87b79f.tmp.5684/_embedded_binaries/embedded_tools/third_party/checker_framework_dataflow/java/org/checkerframework/dataflow/cfg/node/StringConcatenateAssignmentNode.java": Invalid or incomplete multibyte or wide character

That's actually the wrong error message (because of Bazel client: confusing error messages on Windows #2411), the actual reason is error 3, i.e. the path is too long:

$ echo -n '/c/Users/LASZLO~1/AppData/Local/Temp/_bazel_laszlocsomor/install/2b15357e4568f22bb12b81a18c87b79f.tmp.5684/_embedded_binaries/embedded_tools/third_party/checker_framework_dataflow/java/org/checkerframework/dataflow/cfg/node/StringConcatenateAssignmentNode.java' | wc -c
260

I tried again with that dev version, now with a shorter --output_user_root. Failed again while trying to load the JNI dll ~~(I suspect it's linked against a different msys dll, causing trouble)~~ [EDIT: that's wrong, the JNI DLL isn't linked against MSYS] and there's the VS not found error again.

INFO: Found 1 target...
ERROR: C:/tempdir/cleanbazel/bazel/src/main/native/BUILD:75:1: Executing genrule //src/main/native:windows_jni failed: bash.exe failed: error executing command C:/tools/msys64/usr/bin/bash.exe -c ... (remaining 1 argument(s) skipped): com.google.devtools.build.lib.shell.BadExitStatusException: Process exited with status 1.
Visual Studio not found
--version-sortThe system cannot find the file specified.
ERROR: C:/tempdir/cleanbazel/bazel/src/BUILD:92:5: declared output 'src/dummy_darwin_tools/src/objc_tools/plmerge/plmerge_deploy.jar' was not created by genrule. This is probably because the genrule actually didn't create this output, or because the output was a directory and the genrule was run remotely (note that only the contents of declared file outputs are copied from genrules run remotely).
ERROR: C:/tempdir/cleanbazel/bazel/src/BUILD:92:5: declared output 'src/dummy_darwin_tools/src/objc_tools/bundlemerge/bundlemerge_deploy.jar' was not created by genrule. This is probably because the genrule actually didn't create this output, or because the output was a directory and the genrule was run remotely (note that only the contents of declared file outputs are copied from genrules run remotely).
ERROR: C:/tempdir/cleanbazel/bazel/src/BUILD:92:5: declared output 'src/dummy_darwin_tools/src/tools/xcode/stdredirect/StdRedirect.dylib' was not created by genrule. This is probably because the genrule actually didn't create this output, or because the output was a directory and the genrule was run remotely (note that only the contents of declared file outputs are copied from genrules run remotely).
ERROR: C:/tempdir/cleanbazel/bazel/src/BUILD:92:5: declared output 'src/dummy_darwin_tools/src/tools/xcode/xcrunwrapper/xcrunwrapper' was not created by genrule. This is probably because the genrule actually didn't create this output, or because the output was a directory and the genrule was run remotely (note that only the contents of declared file outputs are copied from genrules run remotely).
ERROR: C:/tempdir/cleanbazel/bazel/src/BUILD:92:5: declared output 'src/dummy_darwin_tools/src/tools/xcode/swiftstdlibtoolwrapper/swiftstdlibtoolwrapper' was not created by genrule. This is probably because the genrule actually didn't create this output, or because the output was a directory and the genrule was run remotely (note that only the contents of declared file outputs are copied from genrules run remotely).
ERROR: C:/tempdir/cleanbazel/bazel/src/main/cpp/util/BUILD:74:1: output 'src/main/cpp/util/_objs/port/src/main/cpp/util/port.o' was not created.
Target //src:bazel failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 2.037s, Critical Path: 0.87s

Downloaded the distribution archive to build bazel from source.
That failed with an error I haven't seen before.

$ ./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 scratchFile not found - *.jar
File not found - *.jar
no error prone jar

I'll come back with more updates when I have them.

laszlocsomor · 2017-01-30T10:46:42Z

Let's continue there. (#2449)

In this change: (1) add a sanity check to verify that GNU bintools are on the PATH (2) correct the PATH on Windows if (1) failed (3) use "<user>/My Documents/Temp" as the default temp directory instead of "%windir%/Temp", because the latter is non-writable Motivated by: #2431 #2449 -- PiperOrigin-RevId: 146006796 MOS_MIGRATED_REVID=146006796

Add a list of known issues (currently only on Windows) when trying to build from source. Also update the Windows run/compile requirements. Motivated by: #2431 #2449 -- PiperOrigin-RevId: 146091804 MOS_MIGRATED_REVID=146091804

Add a list of known issues (currently only on Windows) when trying to build from source. Also update the Windows run/compile requirements. Motivated by: bazelbuild/bazel#2431 bazelbuild/bazel#2449 -- PiperOrigin-RevId: 146091804 MOS_MIGRATED_REVID=146091804

laszlocsomor self-assigned this Jan 26, 2017

laszlocsomor added the under investigation label Jan 26, 2017

laszlocsomor mentioned this issue Jan 27, 2017

Bazel installation failed "package io.grpc.stub does not exist" #2436

Closed

abergmeier-dsfishlabs closed this as completed Jan 27, 2017

laszlocsomor mentioned this issue Jan 30, 2017

Windows: cannot bootstrap / run prebuilt 0.4.3 with latest MSYS and pacman packages #2449

Closed

YanYas mentioned this issue Mar 29, 2017

bazel.exe Entry Point Not Found #2756

Closed

Calling Bazel 0.4.3 on Windows yields no output #2431

Calling Bazel 0.4.3 on Windows yields no output #2431

Comments

abergmeier-dsfishlabs commented Jan 26, 2017

Description of the problem / feature request / question:

If possible, provide a minimal example to reproduce the problem:

Environment info

Have you found anything relevant by searching the web? (e.g. GitHub issues, email threads in the bazel-discuss@googlegroups.com archive)

laszlocsomor commented Jan 26, 2017

laszlocsomor commented Jan 26, 2017

abergmeier-dsfishlabs commented Jan 26, 2017

abergmeier-dsfishlabs commented Jan 26, 2017

abergmeier-dsfishlabs commented Jan 26, 2017

laszlocsomor commented Jan 26, 2017 • edited Loading

abergmeier-dsfishlabs commented Jan 26, 2017 • edited Loading

laszlocsomor commented Jan 26, 2017

abergmeier-dsfishlabs commented Jan 26, 2017

laszlocsomor commented Jan 26, 2017

laszlocsomor commented Jan 26, 2017

abergmeier-dsfishlabs commented Jan 26, 2017

laszlocsomor commented Jan 26, 2017

abergmeier-dsfishlabs commented Jan 26, 2017 • edited Loading

laszlocsomor commented Jan 26, 2017

abergmeier-dsfishlabs commented Jan 26, 2017

laszlocsomor commented Jan 26, 2017

abergmeier-dsfishlabs commented Jan 26, 2017

laszlocsomor commented Jan 26, 2017

dslomov commented Jan 26, 2017

abergmeier-dsfishlabs commented Jan 26, 2017 • edited Loading

laszlocsomor commented Jan 26, 2017

abergmeier-dsfishlabs commented Jan 26, 2017 • edited Loading

abergmeier-dsfishlabs commented Jan 27, 2017

abergmeier-dsfishlabs commented Jan 27, 2017

abergmeier-dsfishlabs commented Jan 27, 2017

laszlocsomor commented Jan 27, 2017 • edited Loading

abergmeier-dsfishlabs commented Jan 27, 2017

laszlocsomor commented Jan 27, 2017

laszlocsomor commented Jan 27, 2017 • edited Loading

abergmeier-dsfishlabs commented Jan 27, 2017

abergmeier-dsfishlabs commented Jan 27, 2017

laszlocsomor commented Jan 27, 2017

laszlocsomor commented Jan 27, 2017

laszlocsomor commented Jan 27, 2017

abergmeier-dsfishlabs commented Jan 27, 2017 • edited Loading

abergmeier-dsfishlabs commented Jan 27, 2017

abergmeier-dsfishlabs commented Jan 27, 2017

laszlocsomor commented Jan 30, 2017

abergmeier-dsfishlabs commented Jan 30, 2017 • edited Loading

laszlocsomor commented Jan 30, 2017

laszlocsomor commented Jan 30, 2017 • edited Loading

laszlocsomor commented Jan 30, 2017 • edited Loading

laszlocsomor commented Jan 26, 2017 •

edited

Loading

abergmeier-dsfishlabs commented Jan 26, 2017 •

edited

Loading

abergmeier-dsfishlabs commented Jan 26, 2017 •

edited

Loading

abergmeier-dsfishlabs commented Jan 26, 2017 •

edited

Loading

abergmeier-dsfishlabs commented Jan 26, 2017 •

edited

Loading

laszlocsomor commented Jan 27, 2017 •

edited

Loading

laszlocsomor commented Jan 27, 2017 •

edited

Loading

abergmeier-dsfishlabs commented Jan 27, 2017 •

edited

Loading

abergmeier-dsfishlabs commented Jan 30, 2017 •

edited

Loading

laszlocsomor commented Jan 30, 2017 •

edited

Loading

laszlocsomor commented Jan 30, 2017 •

edited

Loading