cygwin support

[corngood]

I had a look at making zig target cygwin, and got most of the way there: cygwin target definition, stdlib changes, etc. but I got stuck on the linker.

The lld COFF linker doesn't support linker scripts, but the cygwin linker script is needed to set up __data_start__ etc.

Any thoughts on where to go from here? Is it a waste of time?

[andrewrk]

I think you might have better luck in the llvm6 branch, but there are some zig additions needed. LLD added a MinGW driver API which is probably what we should use for cygwin.

[andrewrk]

LLVM 6 rc2 just came out today. It's scheduled to be released at the end of February. Zig will release 0.2.0 1 week after that, at which point master branch will depend on LLD 6 and we can focus on cygwin support.

[corngood]

Interesting. I was looking for COFF diffs in llvm6 today, but I didn't notice the MinGW driver.

It looks like in it's current state it's just doing some simple argument translation, so I'm doubtful it'll help too much since zig already deals with msvc-style linker args.

I'll take a look at the llvm6 branch.

[andrewrk]

we could also ask a question on the llvm mailing list. The LLD maintainers are pretty responsive when it comes to COFF. I believe there should be a lot of interest in getting this working since it benefits the entire LLVM community and not just zig.

[andrewrk]

maybe we are supposed to use the ELF linker interface from LLD for cygwin? and the target triple would be x86_64-windows-gnu ?

[corngood]

I think windows-gnu is mingw, and I'm pretty sure lld/ELF is only for elf format objects, but I could be wrong.

https://llvm.org/doxygen/Triple_8h_source.html#l00542

I'll do a bit more digging.

[andrewrk]

Ah right, of course, the cygnus environment. So we can use that to detect that we should link for cygwin. (I'm guessing you are already doing that in your branch.)

I sent an email to the mailing list: http://lists.llvm.org/pipermail/llvm-dev/2018-February/121066.html

[andrewrk]

If you have some specific need, please explain. We may be able to help.

It looks like the LLD team is willing to work with us to support cygwin.

[corngood]

But I don't think that you actually need all the features of the linker script.

I was thinking that this probably is the case, I just need to figure out what's needed. __begin_data__ etc are probably pretty simple to implement. I wasn't sure about interpreting the linker script vs. just implementing this stuff directly in the linker, but it sounds like the latter would be the way to go.

In my branch I added OsCygwin / Os.cygwin, selected for -windows-cygnus. I did that so I wouldn't have to deal with is_windows / OsWindows, since the fallbacks are usually posix friendly. I consider that a hack though, and I think it would be better to use the llvm triple values as-is. We could add some helpers, and then most of the current is_windows stuff would be covered by something like:

   /// Is this a "Windows" OS targeting a "MSVCRT.dll" environment.
   bool isOSMSVCRT() const {
     return isWindowsMSVCEnvironment() || isWindowsGNUEnvironment() ||
            isWindowsItaniumEnvironment();
  }

But even that's not entirely accurate, because we can target:

• win32
• msvcrt -> win32
• libcygwin -> win32

So it would be odd to call the first one MSVC when it doesn't have anything to do with MSVC.

Another source of inspiration is how nixpkgs handles them:
https://github.com/NixOS/nixpkgs/blob/master/lib/systems/parse.nix

[andrewrk]

Thanks, this all makes sense.

Can you show me the linker script that you would want to use, and maybe I can look at it and suggest how we can achieve it in a different way?

[corngood]

Sure, what I have now:

lld: warning: ./zig-cache/hello.o: undefined symbol: __stack_chk_guard
lld: warning: ./zig-cache/hello.o: undefined symbol: __stack_chk_fail
lld: warning: ./zig-cache/hello.o: undefined symbol: __error
lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: __data_start__
lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: __data_end__
lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: __bss_start__
lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: __bss_end__
lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: __RUNTIME_PSEUDO_RELOC_LIST__
lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: __RUNTIME_PSEUDO_RELOC_LIST_END__
lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: __image_base__

The hello.o ones are probably just a missing library. The libcywin ones seem to be from the linker script. It's built into ld, so I dumped it with -verbose:

GNU ld (GNU Binutils) 2.29.1.20171006
  Supported emulations:
   i386pep
   i386pe
using internal linker script:
==================================================
/* Default linker script, for normal executables */
/* Copyright (C) 2014-2017 Free Software Foundation, Inc.
   Copying and distribution of this script, with or without modification,
   are permitted in any medium without royalty provided the copyright
   notice and this notice are preserved.  */
OUTPUT_FORMAT(pei-x86-64)
SEARCH_DIR("/usr/x86_64-pc-cygwin/lib"); SEARCH_DIR("/usr/lib"); SEARCH_DIR("/usr/lib/w32api");
SECTIONS
{
  /* Make the virtual address and file offset synced if the alignment is
     lower than the target page size. */
  . = SIZEOF_HEADERS;
  . = ALIGN(__section_alignment__);
  .text  __image_base__ + ( __section_alignment__ < 0x1000 ? . : __section_alignment__ ) :
  {
     KEEP(*(.init))
    *(.text)
    *(SORT(.text$*))
     *(.text.*)
     *(.gnu.linkonce.t.*)
    *(.glue_7t)
    *(.glue_7)
    . = ALIGN(8);
     ___CTOR_LIST__ = .; __CTOR_LIST__ = . ;
			LONG (-1); LONG (-1);
			KEEP (*(.ctors));
			KEEP (*(.ctor));
			KEEP (*(SORT(.ctors.*)));
			LONG (0); LONG (0);
     ___DTOR_LIST__ = .; __DTOR_LIST__ = . ;
			LONG (-1); LONG (-1);
			KEEP (*(.dtors));
			KEEP (*(.dtor));
			KEEP (*(SORT(.dtors.*)));
			LONG (0); LONG (0);
     KEEP (*(.fini))
    /* ??? Why is .gcc_exc here?  */
     *(.gcc_exc)
    PROVIDE (etext = .);
     KEEP (*(.gcc_except_table))
  }
  /* The Cygwin32 library uses a section to avoid copying certain data
     on fork.  This used to be named ".data".  The linker used
     to include this between __data_start__ and __data_end__, but that
     breaks building the cygwin32 dll.  Instead, we name the section
     ".data_cygwin_nocopy" and explicitly include it after __data_end__. */
  .data BLOCK(__section_alignment__) :
  {
    __data_start__ = . ;
    *(.data)
    *(.data2)
    *(SORT(.data$*))
    KEEP(*(.jcr))
    __data_end__ = . ;
    *(.data_cygwin_nocopy)
  }
  .rdata BLOCK(__section_alignment__) :
  {
    *(.rdata)
             *(SORT(.rdata$*))
    __rt_psrelocs_start = .;
    KEEP(*(.rdata_runtime_pseudo_reloc))
    __rt_psrelocs_end = .;
  }
  __rt_psrelocs_size = __rt_psrelocs_end - __rt_psrelocs_start;
  ___RUNTIME_PSEUDO_RELOC_LIST_END__ = .;
  __RUNTIME_PSEUDO_RELOC_LIST_END__ = .;
  ___RUNTIME_PSEUDO_RELOC_LIST__ = . - __rt_psrelocs_size;
  __RUNTIME_PSEUDO_RELOC_LIST__ = . - __rt_psrelocs_size;
  .eh_frame BLOCK(__section_alignment__) :
  {
    KEEP (*(.eh_frame*))
  }
  .pdata BLOCK(__section_alignment__) :
  {
    KEEP(*(.pdata*))
  }
  .xdata BLOCK(__section_alignment__) :
  {
    KEEP(*(.xdata*))
  }
  .bss BLOCK(__section_alignment__) :
  {
    __bss_start__ = . ;
    *(.bss)
    *(COMMON)
    __bss_end__ = . ;
  }
  .edata BLOCK(__section_alignment__) :
  {
    *(.edata)
  }
  /DISCARD/ :
  {
    *(.debug$S)
    *(.debug$T)
    *(.debug$F)
    *(.drectve)
     *(.note.GNU-stack)
     *(.gnu.lto_*)
  }
  .idata BLOCK(__section_alignment__) :
  {
    /* This cannot currently be handled with grouped sections.
	See pep.em:sort_sections.  */
    KEEP (SORT(*)(.idata$2))
    KEEP (SORT(*)(.idata$3))
    /* These zeroes mark the end of the import list.  */
    LONG (0); LONG (0); LONG (0); LONG (0); LONG (0);
    KEEP (SORT(*)(.idata$4))
    __IAT_start__ = .;
    SORT(*)(.idata$5)
    __IAT_end__ = .;
    KEEP (SORT(*)(.idata$6))
    KEEP (SORT(*)(.idata$7))
  }
  .CRT BLOCK(__section_alignment__) :
  {
    ___crt_xc_start__ = . ;
    KEEP (*(SORT(.CRT$XC*)))  /* C initialization */
    ___crt_xc_end__ = . ;
    ___crt_xi_start__ = . ;
    KEEP (*(SORT(.CRT$XI*)))  /* C++ initialization */
    ___crt_xi_end__ = . ;
    ___crt_xl_start__ = . ;
    KEEP (*(SORT(.CRT$XL*)))  /* TLS callbacks */
    /* ___crt_xl_end__ is defined in the TLS Directory support code */
    ___crt_xp_start__ = . ;
    KEEP (*(SORT(.CRT$XP*)))  /* Pre-termination */
    ___crt_xp_end__ = . ;
    ___crt_xt_start__ = . ;
    KEEP (*(SORT(.CRT$XT*)))  /* Termination */
    ___crt_xt_end__ = . ;
  }
  /* Windows TLS expects .tls$AAA to be at the start and .tls$ZZZ to be
     at the end of the .tls section.  This is important because _tls_start MUST
     be at the beginning of the section to enable SECREL32 relocations with TLS
     data.  */
  .tls BLOCK(__section_alignment__) :
  {
    ___tls_start__ = . ;
    KEEP (*(.tls$AAA))
    KEEP (*(.tls))
    KEEP (*(.tls$))
    KEEP (*(SORT(.tls$*)))
    KEEP (*(.tls$ZZZ))
    ___tls_end__ = . ;
  }
  .endjunk BLOCK(__section_alignment__) :
  {
    /* end is deprecated, don't use it */
    PROVIDE (end = .);
    PROVIDE ( _end = .);
     __end__ = .;
  }
  .rsrc BLOCK(__section_alignment__) : SUBALIGN(4)
  {
    KEEP (*(.rsrc))
    KEEP (*(.rsrc$*))
  }
  .reloc BLOCK(__section_alignment__) :
  {
    *(.reloc)
  }
  .stab BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.stab)
  }
  .stabstr BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.stabstr)
  }
  /* DWARF debug sections.
     Symbols in the DWARF debugging sections are relative to the beginning
     of the section.  Unlike other targets that fake this by putting the
     section VMA at 0, the PE format will not allow it.  */
  /* DWARF 1.1 and DWARF 2.  */
  .debug_aranges BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.debug_aranges)
  }
  .zdebug_aranges BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.zdebug_aranges)
  }
  .debug_pubnames BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.debug_pubnames)
  }
  .zdebug_pubnames BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.zdebug_pubnames)
  }
  .debug_pubtypes BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.debug_pubtypes)
  }
  .zdebug_pubtypes BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.zdebug_pubtypes)
  }
  /* DWARF 2.  */
  .debug_info BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.debug_info .gnu.linkonce.wi.*)
  }
  .zdebug_info BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.zdebug_info .zdebug.gnu.linkonce.wi.*)
  }
  .debug_abbrev BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.debug_abbrev)
  }
  .zdebug_abbrev BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.zdebug_abbrev)
  }
  .debug_line BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.debug_line)
  }
  .zdebug_line BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.zdebug_line)
  }
  .debug_frame BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.debug_frame)
  }
  .zdebug_frame BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.zdebug_frame)
  }
  .debug_str BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.debug_str)
  }
  .zdebug_str BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.zdebug_str)
  }
  .debug_loc BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.debug_loc)
  }
  .zdebug_loc BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.zdebug_loc)
  }
  .debug_macinfo BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.debug_macinfo)
  }
  .zdebug_macinfo BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.zdebug_macinfo)
  }
  /* SGI/MIPS DWARF 2 extensions.  */
  .debug_weaknames BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.debug_weaknames)
  }
  .zdebug_weaknames BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.zdebug_weaknames)
  }
  .debug_funcnames BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.debug_funcnames)
  }
  .zdebug_funcnames BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.zdebug_funcnames)
  }
  .debug_typenames BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.debug_typenames)
  }
  .zdebug_typenames BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.zdebug_typenames)
  }
  .debug_varnames BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.debug_varnames)
  }
  .zdebug_varnames BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.zdebug_varnames)
  }
  .debug_macro BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.debug_macro)
  }
  .zdebug_macro BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.zdebug_macro)
  }
  /* DWARF 3.  */
  .debug_ranges BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.debug_ranges)
  }
  .zdebug_ranges BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.zdebug_ranges)
  }
  /* DWARF 4.  */
  .debug_types BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.debug_types .gnu.linkonce.wt.*)
  }
  .zdebug_types BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.zdebug_types .zdebug.gnu.linkonce.wt.*)
  }
  /* For Go and Rust.  */
  .debug_gdb_scripts BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.debug_gdb_scripts)
  }
  .zdebug_gdb_scripts BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.zdebug_gdb_scripts)
  }
}

[andrewrk]

As you mentioned, the hello.o errors can be fixed by implementing the named functions in std/special/builtin.zig.

I'll send an email to LLVM developers for the others.

[corngood]

Thanks. There are a few examples of synthetic symbols in the COFF linker, so I'll see if I can get something working myself.

[corngood]

I actually found a library that defines those symbols from hello.o. Linking then completed once I added:

      Symtab.addSynthetic("__data_start__", nullptr);
      Symtab.addSynthetic("__data_end__", nullptr);
      Symtab.addSynthetic("__bss_start__", nullptr);
      Symtab.addSynthetic("__bss_end__", nullptr);
      Symtab.addSynthetic("__RUNTIME_PSEUDO_RELOC_LIST__", nullptr);
      Symtab.addSynthetic("__RUNTIME_PSEUDO_RELOC_LIST_END__", nullptr);
      Symtab.addSynthetic("__image_base__", nullptr);

Unsuprisingly the executable crashed immediately, but I think I've got an idea of how to hook up those symbols.

[andrewrk]

Rui says:

Is that the only problem to use lld to link cygwin programs?

[corngood]

That's a good question. My gut feeling is that there's a lot of subtleties about the cygwin linker script that will need to be carefully handled for e.g. tls, forking, C/C++ stuff.

If I manage to get a working hello.exe from zig, I'll probably build a standalone lld and test some C/C++ stuff.

[corngood]

Looks like it's going to need a fair amount of work to link .idata properly. That seems to be the source of my current crashes. I think the best course of action is to work on getting standalone lld to link C executables on cygwin before doing anything in zig. I'll try to find some time to do that.

What are your thoughts on certain platforms using an external linker (e.g. GNU ld)?

[andrewrk]

What are your thoughts on certain platforms using an external linker (e.g. GNU ld)?

I think it's really important that we do not depend on an external linker - it's one of the major design decisions that defines the Zig project. I think it's worth it to work through the problem by contributing to LLD, even if we have to delay proper cygwin support. I think the LLD team will be pretty helpful when working through this particular problem.

[corngood]

Fair enough. At least it's probably something the LLD team will want, since the target is already working with clang/ld.

[corngood]

FYI I'm still working on this here and there in my spare time, but I still haven't got the .idata stuff linking properly.

On top of the linker script, there's a bunch of custom stuff in binutils, e.g.

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=ld/emultempl/pep.em;h=ad48426ae226aeb17eee0aec96a0ed5e13708eaf;hb=HEAD#l1520

Next step is to read the COFF docs and figure out why the .idata inputs aren't linking to a valid import table.

[andrewrk]

I want to re-evaluate this issue. What's the use case for cygwin anymore? Windows has a subsystem for linux. Zig can target Windows directly. At this point I don't think cygwin is worth supporting.

[corngood]

Sorry for not updating. I got pretty stuck and haven't had a chance to go back to it.

WSL has enough serious problems that IMO it's not a worthy replacement for cygwin, at least not yet, and they aren't making progress particularly quickly. We'll see about the WSL2 thing they just announced, but that just sounds like them giving up and going back to a traditional VM.

Using windows apps from cygwin is possible, you just have issues with filesystem path conversion, signalling, forking doesn't work, etc.

That being said, I'm probably not going to have time to finish this myself, and it's very niche, so I'll understand if you close it.

[daurnimator]

I want to re-evaluate this issue. What's the use case for cygwin anymore? Windows has a subsystem for linux. Zig can target Windows directly. At this point I don't think cygwin is worth supporting.

Many open source libraries only work on windows in a cygwin environment. WSL feels like a totally different machine, and doesn't work well with GUI applications. Zig might be used to write a library to be used by other applications, or your zig application may want to link against other libraries that only work on windows via cygwin.

I would keep the door open to support, but I don't think it's a priority.

[andrewrk]

As it currently stands, there is no plan to support cygwin.

[sskras]

@andrewrk commented on May 9, 2019:

I want to re-evaluate this issue. What's the use case for cygwin anymore? Windows has a subsystem for linux. Zig can target Windows directly. At this point I don't think cygwin is worth supporting.

These days Cygwin could be used at least to bootstrap Zig without LLVM, #17892.

Now if I add the recognition into bootstrap.c..:

--- a/bootstrap.c
+++ b/bootstrap.c
@@ -60,6 +60,12 @@ static const char *get_host_os(void) {
     return "macos";
 #elif defined(__linux__)
     return "linux";
+#elif defined(__midipix__)
+    return "midipix";
+#elif defined(__MSYS__)
+    return "msys2";
+#elif defined(__CYGWIN__)
+    return "cygwin";
 #else
 #error TODO implement get_host_os in this build script for this target
 #endif

... it fails with error: UnknownOperatingSystem:

saukrs@DESKTOP-O7JE7JE /cygdrive/D/_BACKUPS/src/github.com/ziglang/zig
$ make
cc -o bootstrap bootstrap.c
./bootstrap build
cc -o zig-wasm2c stage1/wasm2c.c -O2 -std=c99
./zig-wasm2c stage1/zig1.wasm zig1.c
cc -o zig1 zig1.c stage1/wasi.c -std=c99 -Os -lm
        ./zig1 lib build-exe src/main.zig -ofmt=c -lc -OReleaseSmall --name zig2 -femit-bin=zig2.c --mod build_options::config.zig --mod aro_options::src/stubs/aro_options.zig --mod Builtins/Builtin.def::src/stubs/aro_builtins.zig --mod Attribute/names.def::src/stubs/aro_names.zig --mod Diagnostics/messages.def::src/stubs/aro_messages.zig --mod aro_backend:build_options=aro_options:deps/aro/backend.zig --mod aro:Builtins/Builtin.def,Attribute/names.def,Diagnostics/messages.def,build_options=aro_options,backend=aro_backend:deps/aro/aro.zig --deps build_options,aro -target x86_64-cygwin
error: UnknownOperatingSystem
child process failed
make: *** [GNUmakefile:3: all] Aborted (core dumped)

Other implementations of POSIX environments for Windows (like MSYS2, Midipix) would be nice to have supported too.

Using MinGW64 doesn't work either:

saukrs@DESKTOP-O7JE7JE MINGW64 /D/_BACKUPS/src/github.com/ziglang/zig
$ make
cc -o bootstrap bootstrap.c
bootstrap.c:17:2: error: #error TODO write the functionality for executing child process into this build script
   17 | #error TODO write the functionality for executing child process into this build script
      |  ^~~~~
bootstrap.c: In function 'print_and_run':
bootstrap.c:53:5: warning: implicit declaration of function 'run' [-Wimplicit-function-declaration]
   53 |     run((char **)argv);
      |     ^~~
make: *** [GNUmakefile:2: all] Error 1