Hacker News Reader

Comment by kryptiskt | Hacker News Reader

> Think about it: If you were to force absolutely everything to be statically linked, your KDE app would have to include the ENTIRE KDE library suite, as well as the QT libraries it's based on, as well as the X window libraries those are based on, etc etc. You'd quickly end up with a calculator app that's hundreds of megabytes.

That is false. Static linking only links in the the parts that are actually used, which would be a small fraction of the total.

View on HN

Almost all parts end up being used though - for the vast majority it's not possible to prove that it's never used.

KCalc would for instance pull in HTML rendering for the Help dialog, which would also add all available picture format plugins and also PDF writing support etc.

Reads like a case for passing that off to whichever program responds to a request to open some help HTML.

And as you begin to flesh out some kind of calling convention, you pretty quickly end up with what could very easily be called dynamic linkage of sorts, even if it's not strictly the linking of object files, etc.

Yeah, I figured that'd be a response, but if you're gonna call mime type handlers dynamic linking we may as well give up on using the term at all.

I just don't think "I need to let the user open an HTML document, though not as any core part of my program's functionality" is a strong case for "well I guess I'll have to embed an entire HTML rendering engine if I statically link my deps".

It feels like your missing his point. OP is pointing out that static linking everything is necessarily unworkable. You're arguing that static linking isn't unworkable because you can just dynamic link. It doesn't respond meaningfully to the OP.

No, I'm arguing that including a manpage doesn't mean your program is now dynamically linked to the man command, or that receiving a .doc attachment in my email client doesn't mean my email client is now dynamically linked to a word processor. If you're going to call that dynamic linking then we've officially reductio'd this out of the realm of usefulness.

I may be totally misunderstanding asark, but the model I thought they were suggesting was something like how COM works in Windows. You can, for example, talk to other COM components and pass data back and forth using an efficient binary message passing protocol while still letting them live in their own process space.

It allowed some interesting things. For example, you could write applications that could read, display and modify the contents of Excel files, except they didn't do it directly; they delegated all the actual work of opening, reading, and modifying the *.xls file to Excel itself.

I wouldn't personally consider consuming a COM interface like that to be a form of linking.

That said, getting back to the broader context, I've no idea how you'd make something like that work for a GUI toolkit. But WinRT is supposedly based on COM, so maybe they got something figured out?

Maybe. But for an application opening html documentation, the convention already exists.

    xdg-open [URL]

Opens the URL in the user's default browser, which is a wholly reasonable and expected way for a program to behave. Moreso I'd say than using shared libraries to pull up some sort of kludgy KHTMLPart thing.

No, by default, everything is included, at least in GCC. Go ahead and statically link against some unused .a of your choice and run objdump if you don't believe me. There are some special compiler flags that can be used to prune unused functions, to some extent, but they aren't on by default.

gnu sucks. Only the used functions should get linked.

I mean static linking is not on by default either so you have to flip a flag as well. Adding -ffunction-sections -fdata-sections to the compiler and --gc-sections to the linker is not hugely difficult, although of course you have to make sure that the static libraries were built that way as well.

That being said I agree that even with that you'd still end up with a massive binary because of all the code that's actually used in one way or an other and all of the code that the compiler and linker can't statically mark as dead. In particular anything being called indirectly through a function pointer is almost certainly going to end up in the final binary regardless of whether it's used or not.

And even if a lot of the code gets removed it's a bit silly not to reuse the shared code in RAM instead of allocating pages containing the same thing over and over again. It's wasteful and cache-unfriendly.

Strictly speaking this is decided by the linker, not the compiler.

Reply on news.ycombinator.com