Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dynamic linking

drewdevault.com

Post reply on HN
Print view View original

241–249 of 249 posts

Re: Dynamic linking

#241

Post by AnIdiotOnTheNet »

bscphil wrote: post #229
AnIdiotOnTheNet wrote: post #214

Earlier quoted context omitted.

> If everything is a static blob, you have an environment that is much more friendly to every dev shipping their app as a binary download on their website, like Windows "freeware". Or worse still, they only support AppImage or some other "modern" method of distribution. This cuts maintainers out of the loop. I want to continue using a distribution with maintainers. So because that's what you want, let's make what oth…

> So because that's what you want, let's make what other people want harder. No? I haven't said it should be harder to statically link software. I just said I want to discourage it. I want to advocate that my Linux community resist these kind of ecosystem changes that would, in my opinion, harm the free software community. > Shit like this is why I stick to Windows. Seems like telling on yourself. Compare the results…

> Seems like telling on yourself. Compare the results: the software available on Linux distributions vs. the Windows freeware market.

Obvious choice? WINE wasn't invented because Linux had a great software library.

> And what if that developer isn't trustworthy in some way?

Then you probably shouldn't use their software at all. But that isn't necessarily realistic, which is why I also advocate for sandboxed applications by default, something mobile got right.

> Just one example, but I've sometimes gotten updates for Firefox on Arch Linux before the official binaries got released.

Sure, maybe that happens sometimes for big and popular projects, but there are a lot of more niche projects where what is in the repo is years out of date. Hell, I have to get qbittorrent-nox from a PPA to be up to date and that isn't even very niche.

Re: Dynamic linking

#242

Post by account42 »

pengaru wrote: post #69

Static linking has been such a nuisance for the libSDL folks that they implemented dynamic loading of itself [0], controlled via an environment variable, as an escape hatch from executables w/libSDL linked statically. It's understandable that games, especially proprietary ones, distribute statically-linked binaries ensuring any third-party dependencies will be present and be a compatible version. But the value of tha…

It's really a decision you have to do per-library.

For something like SDL that has a stable ABI while providing user-visible improvements in newer versions, dynamic linking makes sense. SDL's solution isn't only for static linking but also for bundled dynamically loaded SDL copies. I am not really convinced that SDL's approach is perfect though as anyone statically linking SDL can just disable this functionality and this feature has already caused problems requiring you to manually substitute the loaded libSDL.

For libs that don't interact with the system, dynamic linking does not really provide an advantage for binaries that are distributed on their own.

Re: Dynamic linking

#243

Post by account42 »

spc476 wrote: post #195
saagarjha wrote: post #154

Earlier quoted context omitted.

I know how ASLR/ROP/PLT/GOT/RELRO work, but I'm still not understanding what's going on here. When you statically link a binary, you get…one file. And that gets loaded into memory together, and to make it PIE you have all the jumps be pc-relative. Like, a straight up jump instruction to a fixed offset. So where the the room for a table like this? (Unrelated, but since you brought it up: kbind is IMO not a very good m…

When I participated in NaNoGenMo 2015 [1], I ended up having to emulate a very small subset of MS-DOS [2]. That meant loading in an MS-DOS `.EXE` file into memory and running it. I had a 32-bit Linux system, so I was able to use the `vm86()` system call to run the 16-bit code natively. The `.EXE` file had basically two sections---the first the actual binary code (and data and what have you). This was followed by anot…

Relocation by patching code means you no can no longer share code sections between programs.

Re: Dynamic linking

#244

Post by account42 »

Vogtinator wrote: post #4

> On average, dynamically linked executables use only 4.6% of the symbols on offer from their dependencies. That's correct, but also very misleading and leads to the wrong conclusion. The dynamically linked library has references to itself, externally visible or not. It would be wrong to claim that Application.run(); only uses a single symbol of a library. > A good linker will remove unused symbols. With LTO or -f{fu…

> > A good linker will remove unused symbols.

Additionally, a linker not be able to remove symbols that are unused at runtime but are still (transtively) referenced statically. For memory mapped dynamic libaries those code pages will not be loaded unless needed.

For example, statically linking libstdc++ for any C++ program which uses iostreams (or anything else infected with std::locale) will mean including code to format and parse e.g. monetary amounts even if your program never uses this functionality.

Re: Dynamic linking

#245

Post by yencabulator »

gok wrote: post #67

Why stop there? Package every binary in its own container, too! Most programs only use a few system calls, so you're not really getting anything by sharing a single kernel for the entire system.

All containers on a single host very much share the same kernel. You're confused about virtualization vs containers.

Re: Dynamic linking

#246

Post by pjmlp »

08-15 wrote: post #238
pjmlp wrote: post #234

Earlier quoted context omitted.

Your solution requires compiling everything from scratch in a single executable, that is not how plugins are supposed to be designed. We have been there before with solutions like graphics drivers for Borland's BGI library for their MS-DOS compilers. Where a driver interface is provided, and then each "plugin" registers themselves on application startup. Adding new plugins to an existing application in this scenario…

> then you are already using dynamic linking by definition "Well, technically..." I proposed using the dlopen() mechanism (or a custom linker) from a program that is itself statically linked. Because that's what the argument is about: statically linking the stuff you always need. Now, technically , that's dynamic linking. And because I'm linking the plugins dynamically, I might as well link everything dynamically, ri…

Actually that was just how UNIX dynamic linking started out, by using models that patched a.out, and I still have the Slackware CD with the first Linux kernel that was capable of loading proper ELF files instead.

So my knowledge how these things work goes quite back in time.

Re: Dynamic linking

#247

Post by pjmlp »

tannhaeuser wrote: post #235
pjmlp wrote: post #234

Earlier quoted context omitted.

Your solution requires compiling everything from scratch in a single executable, that is not how plugins are supposed to be designed. We have been there before with solutions like graphics drivers for Borland's BGI library for their MS-DOS compilers. Where a driver interface is provided, and then each "plugin" registers themselves on application startup. Adding new plugins to an existing application in this scenario…

That may all be true, but I guess GP was asking what that has to do with statically linking your main binary (or not), which of course you can do, yet still use shared libs as plugin loading mechanism. For example, ODBC drivers (with or without the various unixODBC/iODBC proxies) can be dlopen()ed from otherwise statically compiled main binaries just fine, can't they (even though for ODBC the typical use case is usin…

Sure, but that raises the question why bother with static linking if dlopen if being used anyway.

With dlopen the application can crash in very interesting ways, if it doesn't handle loading the errors in a proper way.

And there is no way to use something like dumpbin or ldd to actually find out what it is looking for, even something like strings might not help, because the path to the file being dynamically loaded in an explicit way might itself be dynamically constructed at runtime.

Re: Dynamic linking

#248

Post by msla »

AnIdiotOnTheNet wrote: post #214
bscphil wrote: post #161

Earlier quoted context omitted.

> Dynamic linking, in the context of an OS which offers a curated list of packages in the form of an official package repository, means that a specialized third party is able to maintain a subcomponent of your system. You nailed it, in my opinion. The biggest reason I favor dynamic linking is not because of any inherent advantage that I'm determined to believe in (in the face of purported evidence to the contrary, li…

> If everything is a static blob, you have an environment that is much more friendly to every dev shipping their app as a binary download on their website, like Windows "freeware". Or worse still, they only support AppImage or some other "modern" method of distribution. This cuts maintainers out of the loop. I want to continue using a distribution with maintainers. So because that's what you want, let's make what oth…

> Shit like this is why I stick to Windows.

So you can only use software in the Microsoft Store?

Re: Dynamic linking

#249

Post by Shorel »

eeereerews wrote: post #193
Shorel wrote: post #148

I think the elephant in the room here is things like Flatpack and Snap, which are basically ugly bastardized versions of static linking.

Ugly maybe, but they're do kinda combine the advantages of both. They have the portability and reproducibility advantages of static linking, while still letting you take them apart and change the dependencies like with dynamic linking if you really want to.

And the disadvantages of both. These being the huge loading times (even for a calculator!) and the disk space required.
Post reply on HN