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

221–230 of 249 posts

Re: Dynamic linking

#221

Post by ChristianBundy »

zenhack wrote: post #156
cookiecaper wrote: post #115

Earlier quoted context omitted.

It's not Gentoo, but in practice, many frequently-used packages remain in the AUR and an AUR helper to make that transparent is standard kit for anyone using the box as a workstation. It's much more "source-based" than it may appear at first glance. I have ~15G of self-built packages sitting in my PKGDEST right now, if that counts for anything.

> an AUR helper to make that transparent is standard kit for anyone using the box as a workstation Fwiw, I've been using arch as my daily driver continuously for 14 years and haven't ever really felt the strong need for an AUR helper.

How do you ensure that all of your AUR packages are up-to-date? The makepkg workflow makes installation easy but I didn't update my AUR packages very consistently until I used a helper.

Re: Dynamic linking

#222

Post by 08-15 »

pjmlp wrote: post #208
tannhaeuser wrote: post #192

Earlier quoted context omitted.

Don't forget that the principles of the LGPL (originally the "library GPL") were/are pretty much tied to the technical concept of a shared library object that an end-user can change, etc; IANAL so I can't say anything about the legal soundness of this interpretation. Moreover, in a recent discussion about this topic on HN, someone said the introduction of shared libs into the Linux user space was mainly in support of…

Without shared libraries, the only way to do plugins is via IPC. Sure it is more secure and probably preferable in modern times, but it also slower and requires more hardware resources, specially when one scales it with desktop software running hundreds of processes, each for their own plugin sets. There is no free lunch as they say.

> Without shared libraries, the only way to do plugins is via IPC.

That's primitive superstition:

- dlopen() works in statically linked programs too.

- Even without dlopen(), you can load code dynamically. It's not magic, especially if the plugin is linked statically.

- Besides, how is IPC bad? I take fcgi over Apache's modules any day.

Re: Dynamic linking

#223

Post by saagarjha »

spacechild1 wrote: post #217
kick wrote: post #140

Earlier quoted context omitted.

The point of the first half of his comment was very obviously pointing out that "form is less important than content" is wrong; Saagar wasn't doing it for no reason, and wasn't doing it in bad faith. That's why it was in an entirely different tone than the rest of the comment, and just about every other comment he's ever made on this site.

Oh, I see. Sarcasm on the internet can be tricky. (There are many people who actually write like that, or much worse.)

I tried my best to make it really over-the-top, but sadly there are people who write that way unironically on the Internet and so Poe's law applied :(

Re: Dynamic linking

#224

Post by loeg »

toast0 wrote: post #180
loeg wrote: post #127

Earlier quoted context omitted.

FreeBSD statically links LLVM into Clang faster build times (2020). (The difference is pretty marginal, but it's at least a percent or two faster.) So my /usr/bin/clang is a 70 megabyte file. The vast majority of the contents are r-x text (code) and r-- read-only data. I don't know if the kernel is capable of sharing read-only paged memory references or not.

> I don't know if the kernel is capable of sharing read-only paged memory references or not. Any pages mapped from disk should be shared, as a consequence of the FreeBSD unified buffer cache; this is why if you write to a binary in-place with cp instead of unlinking first (like install), currently executing copies are changed, and usually crash :). Read-write program sections will be mapped so their changes are priva…

> this is why if you write to a binary in-place with cp instead of unlinking first (like install), currently executing copies are changed, and usually crash

This is not true, or no longer true: opening a running program's backing file with O_RDWR or O_WRONLY is prevented via the "writecount" mechanism (and vice versa: files being written cannot be executed).

Re: Dynamic linking

#225

Post by pjmlp »

08-15 wrote: post #222
pjmlp wrote: post #208

Earlier quoted context omitted.

Without shared libraries, the only way to do plugins is via IPC. Sure it is more secure and probably preferable in modern times, but it also slower and requires more hardware resources, specially when one scales it with desktop software running hundreds of processes, each for their own plugin sets. There is no free lunch as they say.

> Without shared libraries, the only way to do plugins is via IPC. That's primitive superstition: - dlopen() works in statically linked programs too. - Even without dlopen(), you can load code dynamically. It's not magic, especially if the plugin is linked statically. - Besides, how is IPC bad? I take fcgi over Apache's modules any day.

dlopen is useless in static linked programs when the idea is to provide plugins after the fact.

The idea of using plugins is exactly that various parts are able to ship them at various times during the lifetime of the applications.

Patching files compiled statically is obviously not what one wants from plugins.

Incidently plugins support is exactly why Go added support for dynamic linking into their toolchain.

Re: Dynamic linking

#226

Post by toast0 »

loeg wrote: post #224
toast0 wrote: post #180

Earlier quoted context omitted.

> I don't know if the kernel is capable of sharing read-only paged memory references or not. Any pages mapped from disk should be shared, as a consequence of the FreeBSD unified buffer cache; this is why if you write to a binary in-place with cp instead of unlinking first (like install), currently executing copies are changed, and usually crash :). Read-write program sections will be mapped so their changes are priva…

> this is why if you write to a binary in-place with cp instead of unlinking first (like install), currently executing copies are changed, and usually crash This is not true, or no longer true: opening a running program's backing file with O_RDWR or O_WRONLY is prevented via the "writecount" mechanism (and vice versa: files being written cannot be executed).

Hmmm does that also apply to dynamic libraries? Now that I'm thinking about the fateful day, I pushed an updated library, not an executable. I'm guessing it was on FreeBSD 8.x, but it could have been 9.x.

Re: Dynamic linking

#227

Post by steveklabnik »

btilly wrote: post #219
steveklabnik wrote: post #144

Earlier quoted context omitted.

This is talking about very different issues than the ones identified in that paper. Most of that paper, if not all, does not directly apply to Cargo.

Thank you for the insight. I know you know Rust very well. Do you have an explanation for why compile times would be an issue for Rust?

There’s a lot of factors. https://endler.dev/2020/rust-compile-times/ talks about some of them.

Re: Dynamic linking

#228

Post by comex »

saagarjha wrote: post #179
comex wrote: post #177

Earlier quoted context omitted.

Nitpick: macOS has used dyld shared caches for over a decade. The recent change is just to remove the original copies of the libraries on disk.

Ah, you're right. Forgot that they were being used already :) I'm curious what would happen though if you modified a system library and didn't update the cache, though…

dyld would check the modification time and inode and avoid using the shared cache version if there’s a mismatch. (So I gleaned from the documentation of the DYLD_SHARED_CACHE_DONT_VALIDATE environment variable, which tells it not to do that.)

Re: Dynamic linking

#229

Post by bscphil »

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…

> 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: the software available on Linux distributions vs. the Windows freeware market.

> I like having a direct relationship with the developer of the software I use.

And what if that developer isn't trustworthy in some way? (See the Arch Linux dev's post that I linked.)

> If they update their software with a feature or bug fix I need, I want the update right now

Just one example, but I've sometimes gotten updates for Firefox on Arch Linux before the official binaries got released. The maintainers seem to be on top of their game. And never mind the fact that if you're counting on automatic updates, you're assuming that they roll out to everyone simultaneously (often not true) and that automatic updating is always desirable anyway. (Plus a lot of Windows software doesn't update itself at all, so...)

Post reply on HN