Add Cygwin support#500
Conversation
Things are like with Windows+gnu, except the "meson-paths" logic is always used, and shared libs are prefixed with "cyg".
|
For reference: $ rustc --print cfg --target x86_64-pc-cygwin
debug_assertions
panic="unwind"
target_abi=""
target_arch="x86_64"
target_endian="little"
target_env=""
target_family="unix"
target_feature="fxsr"
target_feature="sse"
target_feature="sse2"
target_has_atomic="16"
target_has_atomic="32"
target_has_atomic="64"
target_has_atomic="8"
target_has_atomic="ptr"
target_os="cygwin"
target_pointer_width="64"
target_vendor="pc"
unix$ cargo cinstall --destdir dest
$ tree dest
dest
└── usr
└── local
├── bin
│ └── cygmylib.dll
├── include
│ └── mylib
│ └── mylib.h
└── lib
├── libmylib.a
├── libmylib.dll.a
├── mylib.def
└── pkgconfig
└── mylib.pc
$ c++ main.c -Idest/usr/local/include/mylib -Ldest/usr/local/lib -lmylib
$ PATH=dest/usr/local/bin:$PATH ./a.exe
hello world from rust! |
| LibType::Windows => { | ||
| if self.shared_lib.is_some() | ||
| if self.target.os == "cygwin" { | ||
| Some(format!("cyg{}.dll", self.name).into()) |
There was a problem hiding this comment.
Yes, this is correct. Cygwin has a different ABI, you cannot mix cygwin DLLs with any other runtime.
There was a problem hiding this comment.
Here as an example: https://cygwin.com/packages/x86_64/libglib2.0_0/libglib2.0_0-2.86.0-1
|
|
||
| let expected = FileNames { | ||
| static_lib: PathBuf::from("/foo/bar/libferris.a"), | ||
| shared_lib: PathBuf::from("/foo/bar/ferris.dll"), |
There was a problem hiding this comment.
| shared_lib: PathBuf::from("/foo/bar/ferris.dll"), | |
| shared_lib: PathBuf::from("/foo/bar/cygferris.dll"), |
No?
There was a problem hiding this comment.
As far as I understood it that's the filename that rustc creates, before it gets copied to the right name via cinstall (and the import lib gets re-created then), and I don't know where I could change that (??). Same as with mingw currently.
There was a problem hiding this comment.
I've reverted this for now. If shared_lib is supposed to be the final DLL name, and not the one rustc produces, then I think it should also be changed for windows+mingw.
There was a problem hiding this comment.
If the test confirms then we are set (and probably we should document more the struct to not be confused in the future :)
|
@lazka is it difficult to add a CI item to test it? |
|
@lazka also can you reset the PR with the fix folded in? |
|
I'll have a look later today. |
Upstream Cygwin doesn't have a rust build yet (WIP) so use MSYS2 which ships rust for the Cygwin target. For the example project don't run tests as those depend on inline-c which depends on target-lexicon v0.11, while 0.13.3 is needed for Cygwin support. /usr/local is not in the default pkgconf search path, so add it. Add separate jobs to avoid complicating the conditions of the existing matrix setup even more.
|
I added some basic tests (see commit for details). I went for separate jobs as mixing in even more conditions seemed hard to follow, but I'd be happy to give it a try though if wanted. |
|
I guess we need an integration test that will check the names of the on-disk files after installation. |
|
Thanks! |
4 participants
Things are like with Windows+gnu, except the "meson-paths" logic is always used, and shared libs are prefixed with "cyg".