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

311–320 of 349 posts

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

#311

Post by giancarlostoro »

Animats wrote: post #202
giancarlostoro wrote: post #146

Earlier quoted context omitted.

I wonder if InnoSetup could be a good point of reference for anyone interested. It is in Delphi though, but there is also this guide I found whilst trying to figure out if you could run Inno Setup on Linux: https://gist.github.com/amake/3e7194e5e61d0e1850bba144797fd7... Inno Setup was the best and easiest thing for me to ever use but when I was building Windows installers for use from a Windows OS. Update: Found this…

> Found this Cargo package rust-msi. I looked at that crate. That lets you read and write .msi files, but those are just containers. It doesn't help you set up the rather complicated contents required. Someone who's into the Windows ecosystem could probably use it to do the limited things cargo-bundler does. The neat thing about cargo-bundle is that it only needs the info from the Cargo.toml file to drive the bundlin…

Ah I see. Honestly if I knew Rust better I wouldnt mind taking a stab at the project but I am cozy with dotnet currently. I love building systems tools but very little work I apply for does just that. It is a shame companies dont invest more into R&D.

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

#312

Post by seba_dos1 »

nickelpro wrote: post #310
seba_dos1 wrote: post #309

Earlier quoted context omitted.

Not that hard. Since it's not a use case that most GNU/Linux software needs to be concerned about it's easy to make mistakes and resources are scarce, but once you know what you're doing it's usually not a big deal (maybe except of some specific edge cases). There's lots of old games on Steam that still work on modern distros and new games that work on older ones (and, of course, there's a lot of them that's broken t…

It's very hard. Incompatible glibc ABIs make this nigh impossible, there's a reason Steam installs a vcredistributable.dll for pretty much every game on Windows. On Linux Steam distributes an entire runtime environment based on an ancient Ubuntu release exactly to circumvent this problem. Look no further than the hoops you need jump through to distribute a Linux binary on PyPI [1]. Despite tons of engineering effort,…

Steam distributes an entire runtime environment because it's a platform that's being targeted by 3rd party developers, who often make mistakes that Steam Runtime tries quite hard to reconcile. When all you care about it's your own app, you're in power to compile things however you want and bundle whatever you want with it, at which point it's honestly not that hard. Building in a container is a breeze, tooling is top notch, images with old distros are one command away, testing is easy; in practice I had much more trouble compiling stuff for Windows than for old GNU/Linux distros.

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

#313

Post by nickelpro »

seba_dos1 wrote: post #312
nickelpro wrote: post #310

Earlier quoted context omitted.

It's very hard. Incompatible glibc ABIs make this nigh impossible, there's a reason Steam installs a vcredistributable.dll for pretty much every game on Windows. On Linux Steam distributes an entire runtime environment based on an ancient Ubuntu release exactly to circumvent this problem. Look no further than the hoops you need jump through to distribute a Linux binary on PyPI [1]. Despite tons of engineering effort,…

Steam distributes an entire runtime environment because it's a platform that's being targeted by 3rd party developers, who often make mistakes that Steam Runtime tries quite hard to reconcile. When all you care about it's your own app, you're in power to compile things however you want and bundle whatever you want with it, at which point it's honestly not that hard. Building in a container is a breeze, tooling is top…

It's easy to compile an entirely new binary for every platform/distro, and it's easy to bundle an entire execution environment along with a single binary using docker, what's hard is compiling a single binary and have it run across all distros and execution environments.

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

#314

Post by seba_dos1 »

nickelpro wrote: post #313
seba_dos1 wrote: post #312

Earlier quoted context omitted.

Steam distributes an entire runtime environment because it's a platform that's being targeted by 3rd party developers, who often make mistakes that Steam Runtime tries quite hard to reconcile. When all you care about it's your own app, you're in power to compile things however you want and bundle whatever you want with it, at which point it's honestly not that hard. Building in a container is a breeze, tooling is top…

It's easy to compile an entirely new binary for every platform/distro, and it's easy to bundle an entire execution environment along with a single binary using docker, what's hard is compiling a single binary and have it run across all distros and execution environments.

"Across all distros" - sure, that's outright impossible, and for a good reason. "Across all distros that matter" - no, it's not. How do you think Electron apps distributed in binary form work fine across various distributions?

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

#315

Post by pjmlp »

Dylan16807 wrote: post #306
pjmlp wrote: post #247

Earlier quoted context omitted.

We moved from Windows doesn't do it, it does but isn't available to non admins, it is but non admins can't do files,.... Yep.

We started at "not supported", talking about making symlinks inside projects. We backed off to "not supported on normal systems", which is a reasonable change to me. You mentioning junctions is not even close to a solution, and I am not moving the goalposts. If junctions worked, the complaint wouldn't have been needed from the start. No, this is about actual symlinks, not a similar feature that can do 5% of what syml…

UNIX, no one complains about using sudo all the time.

Windows, oh bummer you need special permissions to be able to call it.

The feature is there and supported.

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

#316

Post by andrewmcwatters »

Spivak wrote: post #108
andrewmcwatters wrote: post #97

Earlier quoted context omitted.

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.

I actually haven’t heard of this approach. Could you explain more or point me to some further reading if you read this and have a moment?

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

#317

Post by Dylan16807 »

pjmlp wrote: post #315
Dylan16807 wrote: post #306

Earlier quoted context omitted.

We started at "not supported", talking about making symlinks inside projects. We backed off to "not supported on normal systems", which is a reasonable change to me. You mentioning junctions is not even close to a solution, and I am not moving the goalposts. If junctions worked, the complaint wouldn't have been needed from the start. No, this is about actual symlinks, not a similar feature that can do 5% of what syml…

UNIX, no one complains about using sudo all the time. Windows, oh bummer you need special permissions to be able to call it. The feature is there and supported.

People would absolutely complain if you needed sudo to check out a repo.

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

#318

Post by pjmlp »

Dylan16807 wrote: post #317
pjmlp wrote: post #315

Earlier quoted context omitted.

UNIX, no one complains about using sudo all the time. Windows, oh bummer you need special permissions to be able to call it. The feature is there and supported.

People would absolutely complain if you needed sudo to check out a repo.

curl | sudo sh is very fashionable nowadays

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

#319

Post by indymike »

pjmlp wrote: post #292
indymike wrote: post #276

Earlier quoted context omitted.

Mobile is almost all IOS and Android... and mostly but not all devs use Macs due to xcode. The only places that Windows seems to persist are developer markets where tooling choices are limited to Windows (games, medical, embedded) or corporate standards dictate tooling.

> Mobile is almost all IOS and Android... and mostly but not all devs use Macs due to xcode. Indeed and trying to use UNIX for mobile apps won't bring you far. > The only places that Windows seems to persist are developer markets where tooling choices are limited to Windows (games, medical, embedded) or corporate standards dictate tooling. The remaining 99% of the market where UNIX GUIs don't matter.

I use macos to make mobile apps every day. Last I looked its bsd unix.

Also ios and android are unixes too.

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

#320

Post by delta_p_delta_x »

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.

> tools tend to be better because they are open source

This is not true in general. It isn't even true for programming tools. Paid/non-OSS IDEs (JetBrains suite, Visual Studio) are often better in many ways than their FOSS equivalents (Eclipse, Qt Creator, etc).

Other examples: office programs (MS Office vs LibreOffice), digital AV workstations (Adobe suite, Da Vinci Resolve vs Kdenlive, ShotCut, etc), 3D editors (Blender is the one exception here, but Maya is still damn good)...

Post reply on HN