Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cross-compiling binaries for Windows is easier than building natively

gist.github.com

Post reply on HN
Print view View original

261–270 of 349 posts

Re: Cross-compiling binaries for Windows is easier than building natively

#261

Post by anonymoushn »

SergeAx wrote: post #245
thrdbndndn wrote: post #19

Earlier quoted context omitted.

My counterpoint is simpler: I use some of these tools (like VS Code) because they're better, not because they're open source. Also I don't think Pylance or whatever core extensions being closed source contradicts with the fact majority of VS Code (or vscodium) is open-source. And I don't see anything morally wrong that they want to close source some of their competitive products.

It may be not intuitive, but tools tend to be better because they are open source. My personal problem with Pylance or ssh tools is that they are not working with VS Code based forks. That means that VS Code is not that open source as it trying to look like. And this is suspicious for me.

The ssh tool is incredibly slow and resource intensive and defaults to losing unsaved work on disconnect. An open source version would open up the possibility of a user fixing some of these issues.

Re: Cross-compiling binaries for Windows is easier than building natively

#262

Post by anonymoushn »

dataflow wrote: post #71

Now try building a "portable" binary that runs on a version of Linux older than yours.

ok: `zig build -Dtarget=native-native-musl -Drelease-fast=true`

This is portable to CPUs with the same features running older linuxes. To be portable to CPUs with fewer features you should specify the CPU family with `-Dcpu=foo_bar` which seems to be the equivalent of `-march=foo-bar`.

Re: Cross-compiling binaries for Windows is easier than building natively

#264

Post by forgotpwd16 »

pjmlp wrote: post #38
fragmede wrote: post #26

Earlier quoted context omitted.

How are they not related? If NTFS didn't have symlinks we wouldn't be having this discussion. Critically, the modern standard for removable drives, exFAT does not support symlinks, so you can't count on Windows' support for symlinks if the user is git cloning on a drive that's using exFAT.

https://docs.microsoft.com/en-us/windows-server/administrati...

Pointing to this page is meaningless. `mklink /d` only works on NTFS but errors out ("The device does not support symbolic links.") on exFAT. GP acknowledges NTFS has symlinks and remarks that exFAT doesn't.

Re: Cross-compiling binaries for Windows is easier than building natively

#265

Post by exDM69 »

Animats wrote: post #14

It is. I generate the Windows executables for a program by cross-compiling Rust on Linux. Then test with Wine. The Rust crates are cross-platform enough that I don't have to special case platforms. This is easier than having a Windows machine. The only current headache is that there's no pure Rust bundler, to make ".msi" or ".msix" installer files. If you dump the legacy OS stuff, it gets easier.

I also cross compile and remote debug windows software on Linux (C and Rust programs). Using gdbserver --multi (extended remote mode) is quite comfortable.

The biggest advantage is not having to use different tools for different target platforms.

Unfortunately MacOS is more difficult target than Windows. If anyone has tips for compiling and debugging software of MacOS from a Linux host, please do share.

Re: Cross-compiling binaries for Windows is easier than building natively

#266

Post by ghusbands »

userbinator wrote: post #72

Only if you want to be trendchasing rather than letting backwards compatibility take care of itself... I'm a native Win32 developer, have been one for a few decades, and know quite a few others still using MSVC6 because it's fast and enough for what they do. Takes Long file paths: Azure, OpenSearch, and ~90 other open source projects have to document how to enable long file paths on Windows because the default is a ~…

> Only if you want to be trendchasing [...] > still using MSVC6

That's some strange logic - you expect someone wanting to compile things for windows to somehow discover a 24-year-old compiler using some older version of C/C++ and to conclude that, despite modern norms, it still works, is still legally available and still produces working binaries.

And if they don't somehow glean all of the above, you say they're trendchasing, rather than just not knowing and using something two-decades obscure and possibly illegal.

Re: Cross-compiling binaries for Windows is easier than building natively

#267

Post by samus »

ygra wrote: post #212
adzm wrote: post #157

Earlier quoted context omitted.

It links dynamically to msvcrt.dll which is updated as part of the os. I believe it still gets updates as long as it doesn't break the ABI. Modern vc++ links with the universal CRT which is an independently updated msvcrt distribution.

Note: https://devblogs.microsoft.com/oldnewthing/20140411-00/?p=12...

Similar problem to Java applications directly accessing internal JDK packages, and then breaking once access was restricted.

Re: Cross-compiling binaries for Windows is easier than building natively

#268

Post by int_19h »

naikrovek wrote: post #180
userbinator wrote: post #82

Earlier quoted context omitted.

That's Microsoft being (the new, not the old) Microsoft... they seriously fucked up the MSDN documentation when it was migrated to docs.microsoft.com, so I'm not surprised that a similar thing happened to the blogs: https://news.ycombinator.com/item?id=20351358

they knew they would and they advertised that fact, and made blog and content owners migrate their stuff if they wanted it kept. many chose not to. those are the people you should be angry with.

Many of the people were no longer at Microsoft when the migration happened, but their blogs were no less useful for that.

And some weren't even alive. Michael Kaplan and his amazing blog about internationalization and Unicode comes to mind - thankfully, other people have archived it: http://archives.miloush.net/michkap/archive/

Re: Cross-compiling binaries for Windows is easier than building natively

#269

Post by int_19h »

jeroenhd wrote: post #224
hacker_homie wrote: post #83

Earlier quoted context omitted.

Easy static link everything. I think you meant a GUI application that runs on a version of Linux older than yours.

I tried that with Rust, actually. My Manjaro was running a much newer version of Glibc than my server so I had to deal with that. First I tried to get it to link to a different system library but no package manager is happy with multiple major versions of glibc. Then I tried MUSL but it turns out the moment you enable MUSL several OpenSSL packages used in very common dependencies don't compile anymore. There was some…

"Statically link or bundle everything" is how most Windows apps deal with this tho. So if we're comparing Windows and Linux, and saying that Linux packaging is worse, this method can't just be dismissed on security grounds.
Post reply on HN