cygwin support #751

corngood · 2018-02-07T20:55:34Z

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?

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

andrewrk · 2018-02-07T21:07:54Z

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 · 2018-02-07T21:08:32Z

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 · 2018-02-07T22:13:51Z

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 · 2018-02-07T22:17:07Z

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 · 2018-02-07T22:43:32Z

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 · 2018-02-07T23:03:50Z

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 · 2018-02-07T23:12:57Z

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 · 2018-02-07T23:26:50Z

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 · 2018-02-08T00:56:59Z

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 · 2018-02-08T01:10:12Z

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 · 2018-02-08T16:07:25Z

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 · 2018-02-08T16:18:47Z

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 · 2018-02-08T18:14:54Z

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 · 2018-02-08T20:53:14Z

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 · 2018-02-09T04:30:33Z

Rui says:

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

corngood · 2018-02-09T13:22:39Z

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 · 2018-02-12T19:02:05Z

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 · 2018-02-12T19:05:29Z

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 · 2018-02-12T19:21:03Z

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

corngood · 2018-02-22T19:28:19Z

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 · 2019-05-09T17:47:06Z

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 · 2019-05-09T17:54:24Z

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 · 2019-05-10T00:44:31Z

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 · 2020-04-15T20:50:04Z

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

sskras · 2023-12-05T10:35:56Z

@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

fithisux · 2024-06-12T16:38:41Z

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

Fingers crossed. I am on Windows and I am not interested in WSL2. I prefer cygwin. Lots of software can be more maintainable if they move to Zig.

e.g. libtecra, this is stuck in 2014. A classical C/autotools software.

andrewrk · 2024-06-12T17:45:03Z

You don't need msys2, cygin, wsl, wsl2, nor midipix to use zig. Zig has native Windows support.

GalaxySnail · 2024-06-12T18:29:37Z

Using zig with cygwin/msys2 has some advantages compared to native Windows support. For example:

cygwin supports posix pty
a cygwin process can directly execute a script with shebang line
cygwin supports /proc/<pid>/fd, so we can use process substitution, which is a very useful feature
cygwin supports SIGSTOP/SIGCONT, so we can use CTRL-Z to suspend a cygwin process and go back to the shell

andrewrk · 2024-06-12T18:39:58Z

Zig is not going to support Cygwin. Personally, I think the project should retire, because it's too much of a hack - fundamentally broken and too buggy for serious usage. A cute party trick that was taken too far. I'm going to lock the thread because the matter is settled and I want to have the last word be this criticism of Cygwin.

andrewrk added this to the 0.3.0 milestone Feb 7, 2018

andrewrk added the enhancement Solving this issue will likely involve adding new logic or components to the codebase. label Feb 7, 2018

andrewrk modified the milestones: 0.3.0, 0.4.0 Feb 28, 2018

andrewrk modified the milestones: 0.4.0, 0.5.0 Sep 28, 2018

andrewrk added proposal This issue suggests modifications. If it also has the "accepted" label then it is planned. and removed enhancement Solving this issue will likely involve adding new logic or components to the codebase. labels May 9, 2019

andrewrk removed this from the 0.5.0 milestone May 9, 2019

andrewrk added this to the 0.6.0 milestone May 9, 2019

andrewrk mentioned this issue Jun 7, 2019

mingw support #2633

Closed

andrewrk modified the milestones: 0.6.0, 0.7.0 Oct 17, 2019

andrewrk closed this as completed Apr 15, 2020

ivmai mentioned this issue Apr 26, 2024

Zig-build improvements: MSVC & C++ ivmai/bdwgc#636

Closed

andrewrk closed this as not planned Won't fix, can't repro, duplicate, stale Jun 12, 2024

ziglang locked as resolved and limited conversation to collaborators Jun 12, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

cygwin support #751

cygwin support #751

corngood commented Feb 7, 2018

andrewrk commented Feb 7, 2018

andrewrk commented Feb 7, 2018

corngood commented Feb 7, 2018

andrewrk commented Feb 7, 2018

andrewrk commented Feb 7, 2018

corngood commented Feb 7, 2018

andrewrk commented Feb 7, 2018

andrewrk commented Feb 7, 2018 •

edited

Loading

corngood commented Feb 8, 2018

andrewrk commented Feb 8, 2018

corngood commented Feb 8, 2018

andrewrk commented Feb 8, 2018

corngood commented Feb 8, 2018

corngood commented Feb 8, 2018

andrewrk commented Feb 9, 2018

corngood commented Feb 9, 2018

corngood commented Feb 12, 2018

andrewrk commented Feb 12, 2018

corngood commented Feb 12, 2018

corngood commented Feb 22, 2018

andrewrk commented May 9, 2019

corngood commented May 9, 2019

daurnimator commented May 10, 2019

andrewrk commented Apr 15, 2020

sskras commented Dec 5, 2023

fithisux commented Jun 12, 2024

andrewrk commented Jun 12, 2024

GalaxySnail commented Jun 12, 2024

andrewrk commented Jun 12, 2024

cygwin support #751

cygwin support #751

Comments

corngood commented Feb 7, 2018

andrewrk commented Feb 7, 2018

andrewrk commented Feb 7, 2018

corngood commented Feb 7, 2018

andrewrk commented Feb 7, 2018

andrewrk commented Feb 7, 2018

corngood commented Feb 7, 2018

andrewrk commented Feb 7, 2018

andrewrk commented Feb 7, 2018 • edited Loading

corngood commented Feb 8, 2018

andrewrk commented Feb 8, 2018

corngood commented Feb 8, 2018

andrewrk commented Feb 8, 2018

corngood commented Feb 8, 2018

corngood commented Feb 8, 2018

andrewrk commented Feb 9, 2018

corngood commented Feb 9, 2018

corngood commented Feb 12, 2018

andrewrk commented Feb 12, 2018

corngood commented Feb 12, 2018

corngood commented Feb 22, 2018

andrewrk commented May 9, 2019

corngood commented May 9, 2019

daurnimator commented May 10, 2019

andrewrk commented Apr 15, 2020

sskras commented Dec 5, 2023

fithisux commented Jun 12, 2024

andrewrk commented Jun 12, 2024

GalaxySnail commented Jun 12, 2024

andrewrk commented Jun 12, 2024

andrewrk commented Feb 7, 2018 •

edited

Loading