Building tetris on Windows -> zig-cache\build crashes

[haferburg]

D:\coding\src\tetris>zig build -Drelease-safe=true --verbose
zig build-exe D:\coding\src\tetris\src\main.zig --release-safe --cache-dir D:\coding\src\tetris\zig-
cache --output D:\coding\src\tetris\zig-cache\tetris.exe --name tetris --library c --library epoxy -
-library m --library png --library glfw --library z
reached unreachable code
(stack trace unavailable for COFF object format)

I can't debug the zig-cache\build file, because there is no source attached. Is there any way for me to tell zig to embed source debugging info?

[haferburg]

Alright, I got a bit further by not using the build.zig. Now it complains

D:\coding\src\tetris\src\main.zig:141:26: error: no member named 'GL_FALSE' in 'D:\coding\src\tetris
\src\c.zig'
    if (c.glfwInit() == c.GL_FALSE) {

If I look at --verbose-cimport, I don't see any of the GL_... defines from epoxy/gl_generated.h. I do see other declarations from this file:

pub extern var epoxy_glGetnUniformivEXT: ?extern fn(GLuint, GLint, GLsizei, ?&GLint);
pub extern var epoxy_glGetnUniformivKHR: ?extern fn(GLuint, GLint, GLsizei, ?&GLint);
pub extern var epoxy_glGetnUniformui64vARB: ?extern fn(GLuint, GLint, GLsizei, ?&GLuint64);

And defines do work for GLFW:

pub const GLFW_CURSOR = 208897;
pub const GLFW_OPENGL_DEBUG_CONTEXT = 139271;
pub const GLFW_KEY_E = 69;
pub const GLFW_JOYSTICK_6 = 5;

Any idea why it doesn't pick up the defines from epoxy?

[haferburg]

D:\coding\src\tetris\src\main.zig:110:10: error: no member named 'printf' in 'D:\coding\src\tetris\s
rc\c.zig'
    _ = c.printf(c"Error: %s\n", description);

It doesn't pick up printf from stdio.h either.

[andrewrk]

Note that I haven't yet gotten tetris building natively on windows. These error reports are helpful though.

I can't debug the zig-cache\build file, because there is no source attached. Is there any way for me to tell zig to embed source debugging info?

This is #516 which will be fixed with the next LLVM release.

If I look at --verbose-cimport, I don't see any of the GL_... defines from epoxy/gl_generated.h. I do see other declarations from this file:

--verbose-cimport doesn't explain why when macros cannot be translated, but I can add that.

It doesn't pick up printf from stdio.h either.

This can be fixed with the workaround in example/hello_world/hello_libc.zig:

https://github.com/zig-lang/zig/blob/b35689b70de2da0c28d4d6ab56e2987cddf80e77/example/hello_world/hello_libc.zig#L1-L6

when our c-to-zig translation powers improve this workaround can be removed.

[haferburg]

Re #516: Does that mean that you link the build file with lld? Can I make it link with link.exe instead and get source debugging?

Anything I can do for gl.h?

I'll try the workaround for printf later, thanks!

[andrewrk]

Can I make it link with link.exe instead and get source debugging?

You can - I tested this and it works - but you're going into unsupported-land so you'll have to maintain your own fork that does this. (I'm happy to provide guidance, just not going to merge the code into zig repo). You'll want to change the call from ZigLLDLink to calling os_exec_process.

Anything I can do for gl.h?

Workaround:
Look for the GL_FALSE macro in gl.h and create a constant that has the correct value in zig. You are manually doing the c-to-zig translation that did not work for GL_FALSE. If you find the #define, show it to me here, I want to see it so I can figure out why it didn't get translated.

[haferburg]

Thank you for the pointers.

I downloaded epoxy from here: https://github.com/anholt/libepoxy/releases
https://github.com/anholt/libepoxy/releases/download/1.4.3/libepoxy-shared-x64.zip

The code is very basic, which is why I found it surprising that it would get all the GLFW macros, but not the GL ones.

#define GL_NEXT_BUFFER_NV                                                          -2
#define GL_SKIP_COMPONENTS4_NV                                                     -3
#define GL_SKIP_COMPONENTS3_NV                                                     -4
#define GL_SKIP_COMPONENTS2_NV                                                     -5
#define GL_SKIP_COMPONENTS1_NV                                                     -6
#define GL_FALSE                                                                   0
#define GL_LAYOUT_DEFAULT_INTEL                                                    0
#define GL_NONE                                                                    0
#define GL_NONE_OES                                                                0
#define GL_NO_ERROR                                                                0
#define GL_ZERO                                                                    0
#define GL_CLOSE_PATH_NV                                                           0x00
#define GL_POINTS                                                                  0x0000
#define GL_TERMINATE_SEQUENCE_COMMAND_NV                                           0x0000
#define GL_PERFQUERY_SINGLE_CONTEXT_INTEL                                          0x00000000
#define GL_2X_BIT_ATI                                                              0x00000001
#define GL_CLIENT_PIXEL_STORE_BIT                                                  0x00000001
#define GL_COLOR_BUFFER_BIT0_QCOM                                                  0x00000001
#define GL_CONTEXT_CORE_PROFILE_BIT                                                0x00000001
#define GL_CONTEXT_FLAG_FORWARD_COMPATIBLE_BIT                                     0x00000001
#define GL_CURRENT_BIT                                                             0x00000001
#define GL_PERFQUERY_GLOBAL_CONTEXT_INTEL                                          0x00000001

[haferburg]

http://blog.llvm.org/2017/08/llvm-on-windows-now-supports-pdb-debug.html

I liked this quote:

And last but not least, tools such as WinDbg are already great for post-mortem debugging, and frankly many (perhaps even most) Windows developers will only give up the Visual Studio debugger when it is pried from their cold dead hands.

[andrewrk]

The code is very basic, which is why I found it surprising that it would get all the GLFW macros, but not the GL ones.

It should for sure understand these macros, which makes me think that somehow the C files didn't end up including that code.

On linux the build is working, and it's correctly translating those macros. So something else is going wrong.

[haferburg]

The c.zig file includes GLFW/glfw3.h. If I copy and paste the entire file to another file tetris\src\glfw\gltest.h, replace the include in c.zig accordingly, and add the tetris\src folder as an include path, the compiler no longer parses the file correctly, and is missing GLFW_ defines.

D:\coding\src\tetris\src\main.zig:142:26: error: no member named 'GLFW_FALSE' in 'D:\coding\src\tetris\src\c.zig'

[haferburg]

Please let me know if you need anything in order to reproduce this.

[haferburg]

main.zig:

const c = @import("c.zig");
pub fn main() -> %void {
    const ok = c.GLFW_TRUE;
}

c.zig:

pub use @cImport({
    @cInclude("glfw/gltest.h");
});

glfw/gltest.h:

#define GLFW_TRUE                   1

build.bat:

set bat_path=%~dp0
zig build-exe %bat_path%src\main.zig --release-safe^
 --cache-dir %bat_path%zig-cache^
 --output %bat_path%zig-cache\tetris.exe^
 --name tetris^
 -isystem %bat_path%include^
 --verbose-cimport 2> build.txt

build.txt:

D:\coding\src\tetrisBug\src\main.zig:4:17: error: no member named 'GLFW_TRUE' in 'D:\coding\src\tetrisBug\src\c.zig'

tetrisBug.zip

[dimenus]

awesome example @haferburg, I'm going to look into this today.

[dimenus]

@haferburg @andrewrk

This a line ending issue. While Zig may detect '\r' in its own code, it does not detect it in c_imports.

You should be able to get it work by setting your line endings to unix in your text editor.

[haferburg]

@dimenus Thank you very much! It does work indeed with unix line endings.

Now the only thing missing is libpng, which I'll try to build tomorrow. Thanks everyone! :)

[andrewrk]

Just a note: we will support windows line endings in C imports. I'll do that before closing this issue.

[andrewrk]

Ah nice thanks both of you for submitting pull requests

[haferburg]

So after resolving the line ending issue, I got it to compile, but the compiler crashed, without any error message. I built LLVM, Clang, and zig in Debug mode, and got the following stack trace. Unfortunately the Clang and LLVM people don't install .pdb files with the INSTALL scripts. I don't know if this is helpful.

  ucrtbased.dll!000007fee20f1a05()  Unknown
  ucrtbased.dll!000007fee20f1ba3()  Unknown
  ucrtbased.dll!000007fee2112b7d()  Unknown
  ucrtbased.dll!000007fee2118765()  Unknown
  ucrtbased.dll!000007fee2118287()  Unknown
  ucrtbased.dll!000007fee2116318()  Unknown
  ucrtbased.dll!000007fee2118cef()  Unknown
  zig.exe!llvm::isa_impl_cl<class llvm::Instruction,class llvm::Value const *>::doit(class llvm::Value const *) Unknown
  zig.exe!llvm::isa_impl_wrap<class llvm::Instruction,class llvm::Value const *,class llvm::Value const *>::doit(class llvm::Value const * const &) Unknown
  zig.exe!llvm::isa_impl_wrap<class llvm::Instruction,class llvm::Value const * const,class llvm::Value const *>::doit(class llvm::Value const * const &) Unknown
  zig.exe!llvm::isa<class llvm::Instruction,class llvm::Value const *>(class llvm::Value const * const &) Unknown
  zig.exe!TarjanSCC::FindSCC(class llvm::Instruction const *) Unknown
  zig.exe!std::tie<int const ,class llvm::Value * const,class llvm::Value * const,class llvm::MemoryAccess const * const>(int const &,class llvm::Value * const &,class llvm::Value * const &,class llvm::MemoryAccess const * const &) Unknown
  zig.exe!llvm::GVNExpression::PHIExpression::~PHIExpression(void)  Unknown
  zig.exe!llvm::GVNExpression::PHIExpression::~PHIExpression(void)  Unknown
  zig.exe!llvm::GVNExpression::PHIExpression::~PHIExpression(void)  Unknown
  zig.exe!llvm::GVNExpression::PHIExpression::~PHIExpression(void)  Unknown
  zig.exe!llvm::GVNExpression::PHIExpression::~PHIExpression(void)  Unknown
  zig.exe!llvm::GVNExpression::PHIExpression::~PHIExpression(void)  Unknown
  zig.exe!llvm::FPPassManager::runOnFunction(class llvm::Function &)  Unknown
  zig.exe!llvm::initializeDummyCGSCCPassPass(class llvm::PassRegistry &)  Unknown
  zig.exe!llvm::initializeDummyCGSCCPassPass(class llvm::PassRegistry &)  Unknown
  zig.exe!llvm::initializeDummyCGSCCPassPass(class llvm::PassRegistry &)  Unknown
  zig.exe!llvm::legacy::FunctionPassManagerImpl::doFinalization(class llvm::Module &) Unknown
  zig.exe!llvm::legacy::PassManagerImpl::run(class llvm::Module &)  Unknown
  zig.exe!llvm::legacy::PassManager::run(class llvm::Module &)  Unknown
> zig.exe!ZigLLVMTargetMachineEmitToFile(LLVMOpaqueTargetMachine * targ_machine_ref, LLVMOpaqueModule * module_ref, const char * filename, LLVMCodeGenFileType file_type, char * * error_message, bool is_debug) Line 161 C++
  zig.exe!do_code_gen(CodeGen * g) Line 4512  C++
  zig.exe!codegen_build(CodeGen * g) Line 5646  C++
  zig.exe!main(int argc, char * * argv) Line 830  C++
  [External Code] 

[dimenus]

@haferburg did you compile master llvm or release_50?

[haferburg]

@dimenus release_50

The LLVMConfig.cmake says:

set(LLVM_VERSION_MAJOR 5)
set(LLVM_VERSION_MINOR 0)
set(LLVM_VERSION_PATCH 0)
set(LLVM_PACKAGE_VERSION 5.0.0svn-r317015)

[nm-remarkable]

Can this issue be closed now?