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

101–110 of 349 posts

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

#101

Post by trinovantes »

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 ~…

The 260 path limit is a pain for organizing media. It's not surprising most applications/games store their media in giant blobs instead of just individual files. This makes software updates a pain since it requires users to download the entire blob if you can't diff the blobs or if the diff corrupts the blob due to mismatched implementation versions.

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

#102

Post by giantrobot »

slimsag wrote: post #8
colejohnson66 wrote: post #4

Earlier quoted context omitted.

I agree that Windows could do more to support the developers on other platforms. Symlinks just seem like a petty thing to complain about IMHO. Didn’t realize how common they were though. NTFS does support them, however. Is Git just not supporting them properly?

Well, it feels 'petty' and simple until: 1. You run into it, go "AH, wow, okay, I'll enable Developer Mode" 2. It still doesn't work, you're confused, you Google around a bit more and find out actually you also need to use a Git config option 3. You retry, now the symlinks work, but your compiler fails because "Destination Path Too Long", huh, that's weird 4. You google a bit more, and discover you need to set a regi…

Yak shaving.

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

#104

Post by kibibu »

e4m2 wrote: post #20

> Are derived community works, like say the D-language, Dart, or Zig bindings to the win32 API which are generated from those files open source - if Microsoft did not release them as such? Certainly. The source for these bindings is the WinMD file, which is MIT licensed. While it is true that its contents are generated wholly from non-FOSS sources, it doesn't impact end users of the metadata. Microsoft owns the origi…

If you read further down the issue comments, it's explained that the generated files don't contain all the info in the idl files.

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

#105

Post by coder543 »

nicoburns wrote: post #84
nshm wrote: post #34

Earlier quoted context omitted.

Not when you are on Macbook. Don't suggest external drives please ;)

True historically, but this has actually been solved on the latest macs. Base spec for the MacBook Pro is 1TB disk.

> Base spec for the MacBook Pro is 1TB disk.

I believe you mean 256GB.[0] Unless you meant to say 14" or 16" MacBook Pro, in which case the base spec is still only 512GB for either of them, not 1TB.[1][2]

For the prices Apple is charging, I wish they would make 1TB the base spec... but Apple Silicon is so good that the machines sell like hotcakes anyways.

[0]: https://www.apple.com/shop/buy-mac/macbook-pro/13-inch

[1]: https://www.apple.com/shop/buy-mac/macbook-pro/14-inch

[2]: https://www.apple.com/shop/buy-mac/macbook-pro/16-inch

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

#106

Post by nicoburns »

coder543 wrote: post #105
nicoburns wrote: post #84

Earlier quoted context omitted.

True historically, but this has actually been solved on the latest macs. Base spec for the MacBook Pro is 1TB disk.

> Base spec for the MacBook Pro is 1TB disk. I believe you mean 256GB.[0] Unless you meant to say 14" or 16" MacBook Pro, in which case the base spec is still only 512GB for either of them, not 1TB.[1][2] For the prices Apple is charging, I wish they would make 1TB the base spec... but Apple Silicon is so good that the machines sell like hotcakes anyways. [0]: https://www.apple.com/shop/buy-mac/macbook-pro/13-inch [1…

Hum, I think it’s reasonable to only consider the 14” and 16” variants latest generation models. But I guess I misremembered the base spec. Looking at the link, it’s because you get 1TB if you get the model with the full 8 performance cores. But that model is quite a bit more expensive than the base model.

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

#107

Post by melissalobos »

dataflow wrote: post #85
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.

Statically link everything ? Including glibc?

> Including glibc?

Any reasonable person doing this would use Musl of course.

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

#108

Post by Spivak »

andrewmcwatters wrote: post #97
dataflow wrote: post #88

Earlier quoted context omitted.

Yes, "simply". It's a very fun process. Around 100 times more fun than the onerous git config --global core.symlinks true

Anyone who talks nonchalantly about glibc hasn't had their time eaten up by glibc.

Like it’s absolutely a nightmare but you can eliminate a lot of problems by building on an ancient version of RHEL.

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

#110

Post by ajvs »

dataflow wrote: post #85
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.

Statically link everything ? Including glibc?

AppImage is sufficient.
Post reply on HN