Hacker News Reader

Comment by SwellJoe | Hacker News Reader

It's unfortunate on Linux, but on Windows and Mac, as you note, you're already shipping your users a copy of Qt with the application.

And, in the modern world of big computers (desktops and laptops), it is not all that big of a deal (I don't actually know, but I would guess it's on the order of a few MB, maybe in the tens of MBs), and from what I can tell a lot of applications are already built statically for distribution to Windows and Mac OS X.

View on HN

UPX might be an option, if binary size is a concern.

I agree with you on "big computers" to an extent. I just bought a temporary [1] laptop. It's beefy enough, but only has 2GB of RAM and 32GB of relatively slow flash storage [2].

Mobile broadband prices have been falling in Australia but it's still at the point where I have to thing before downloading anything >5MB.

[1]: http://www.pendo.com.au/pendopad/pendopads-windows-8/pendo11... (I didn't pay RRP)

[2]: Okay, okay, it's still eMMC, but it feels slow.

In fact, Qt’s – or even Java’s – program sizes, if you bundle the runtime and all libs, are still smaller than what is currently distributed as node-webkit apps.

I personally think it's a complexity management problem and a version management problem. Shared libraries make sense for "timeless" stuff like math or very core system stuff, but beyond that there is too much variation both in version and in approach. Unless your target is a platform as rigidly managed as Apple, you must ship it all or you will get missing shared library errors.

I do think changes in how shared libraries are shipped or managed may help. I've had ideas for ages around using cryptographic hashes but have no time to experiment with such things.

Thw thing about Apple is they give no fucks about backwards compatibility for developers anyway. You're a developer and you're working with Apple tech, so naturally you were waiting in line in the cold to get their latest hw and sw, weren't you?

This bit me on the ass when Apple forced a libstdc++ update on OS X 10.3 with a new ABI, permanently breaking all C++ compilation on my Mac. Compiling C++ programs for 10.3 was still possible, but you needed a 10.4 machine, the latest Xcode, and compatibility libraries to do it.

That wasn't just Apple. The reason that happened was because gcc went from 3 to 4 in that time frame. gcc and C++ never guaranteed binary compatibility, especially between major versions.

I had similar problems on Linux and Solaris because of that transition. My own fault (actually my employer's) for assuming binary compatibility when it was never promised.

GCC transition from 3 to 4 didn't break the ABI. The last required ABI break was 3.0 to 3.1.

I'm not being pedantic. libstdc++ was mentioned. That always can break.

The ABI between g++ transitions is also platform and architecture dependent. Mac was PowerPC back then. Sun used Sparc. Not everything is always x86, even on Linux.

You are right, I had forgot that GCC broke the libstdc++ ABI between 3.3 and 3.4 (not 3.x to 4.x though). That was 12 years ago, though, the ABI has been stable ever since [1].

I still would characterize it a fairly stable ABI, not something that "can always break", especially compared with other vendors that break the library ABI every release.

[1] A new libstdc++ C++11 ABI was added in GCC 5.x but it is optional even in C++11 mode.

Indeed, but most Linux distros of the era did not force a new-ABI libstdc++ upgrade on you, breaking C++ compilation with a mandatory security update. Apple did. Therefore I bite my thumb at them.

Reply on news.ycombinator.com