6 ms·

> As a development machine it will be all but useless as you find things that won't compile or work correctly on the new CPU arch. I'm not a developer so forgi

> As a development machine it will be all but useless as you find things that won't compile or work correctly on the new CPU arch. I'm not a developer so forgive my ignorance, but isn't this what cross-compiling is for? I get that compiling natively can increase performance and find obscure hardware issues, but it's my understanding that, for example, ARM builds of GNU/Linux binaries are just cross-compiled by server farms that are also natively compiling the AMD64 builds. Also, fat binaries and JIT emulation have been a thing forever, especially for Apple who has dealt with these changes twice now (68k -> PPC -> x86-64). I just don't see this being any different than current multi-platform efforts like Debian, NetBSD, etc., except it's a for-profit company with billions of dollars and thousands of expert employees behind it.

bluedino 6y ago
There are bugs that will show up on certain x86 that won't show up on ARM. Plus you've got things like code that is already built that you'll have to emulate in some way or another.
ryanong 6y ago
pro audio tends to be a lot more low level to prevent any kind of stuttering or delay, so it may not always be compatible across stacks. It also tends to not get updated very often. You create 1 plugin for ableton, then the creator has moved on to the next project.
dx034 6y ago
Cross compiling is more for supporting more platforms with minimal or no code changes. If you develop applications that will always just run on x86, developing and testing them on another platform doesn't make much sense in my opinion. You might have to compromise just because of your development environment and errors could be caught too late.
drewg123 6y ago
There can be subtle bugs, especially if you have code which has to adhere to a strict on-disk or on-network format. I recently committed a change to FreeBSD's kernel (written in C) which I'd tested on amd64 and x86. Much to my surprise, when I did the cross-build for all platforms, I had a compile-time assert fail on 32-bit arm because the size of a struct was too large. It turns out that 32-bit arm (at least on FreeBSD) naturally aligns 8 byte data types to 8 byte boundaries, whereas x86 packs them and allows them to straddle the 8 byte boundary. This left a 4-byte hole in my struct, and caused it to be 4 byte too large. These are the sorts of things that bite you when moving from x86/x86_64 to a risc platform, even when its the same endian.
- saagarjha 6y ago
  If you care about the packing of your struct, then you should probably be using compiler-specific packing attributes.
DeathArrow 6y ago
Here is Linus Torvalds explaining why cross-development isn't great: https://www.realworldtech.com/forum/?threadid=183440&curpostid=183486 https://www.realworldtech.com/forum/?threadid=183440&curpost...

bluedino 6y ago

There are bugs that will show up on certain x86 that won't show up on ARM. Plus you've got things like code that is already built that you'll have to emulate in some way or another.

ryanong 6y ago

pro audio tends to be a lot more low level to prevent any kind of stuttering or delay, so it may not always be compatible across stacks. It also tends to not get updated very often. You create 1 plugin for ableton, then the creator has moved on to the next project.

dx034 6y ago

Cross compiling is more for supporting more platforms with minimal or no code changes. If you develop applications that will always just run on x86, developing and testing them on another platform doesn't make much sense in my opinion. You might have to compromise just because of your development environment and errors could be caught too late.

drewg123 6y ago

There can be subtle bugs, especially if you have code which has to adhere to a strict on-disk or on-network format. I recently committed a change to FreeBSD's kernel (written in C) which I'd tested on amd64 and x86. Much to my surprise, when I did the cross-build for all platforms, I had a compile-time assert fail on 32-bit arm because the size of a struct was too large. It turns out that 32-bit arm (at least on FreeBSD) naturally aligns 8 byte data types to 8 byte boundaries, whereas x86 packs them and allows them to straddle the 8 byte boundary. This left a 4-byte hole in my struct, and caused it to be 4 byte too large. These are the sorts of things that bite you when moving from x86/x86_64 to a risc platform, even when its the same endian.

saagarjha 6y ago
If you care about the packing of your struct, then you should probably be using compiler-specific packing attributes.

DeathArrow 6y ago

Here is Linus Torvalds explaining why cross-development isn't great: https://www.realworldtech.com/forum/?threadid=183440&curpostid=183486 https://www.realworldtech.com/forum/?threadid=183440&curpost...