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

An alternative to shared libraries (2008)

kix.in

Post reply on HN
Print view View original

1–10 of 18 posts

Re: An alternative to shared libraries (2008)

#2

Post by _bxg1 »

I've done mercifully-little C(++) programming in my life, but the very idea of dll's has always seemed extremely fragile to me. Depending that deeply on the system configuration for basic functioning... ylech.

I also can't help but wonder if they're obsolete these days, given how incredibly cheap disk storage is? Can anyone who works in that sector speak more to that?

Re: An alternative to shared libraries (2008)

#3

Post by _bxg1 »

_bxg1 wrote: post #2

I've done mercifully-little C(++) programming in my life, but the very idea of dll's has always seemed extremely fragile to me. Depending that deeply on the system configuration for basic functioning... ylech. I also can't help but wonder if they're obsolete these days, given how incredibly cheap disk storage is? Can anyone who works in that sector speak more to that?

These days I mostly work in JavaScript, and say what you will about NPM, at least it provides a consistent, reliable, central strategy for retrieving and organizing external dependencies (assuming you haven't just built them into your bundle). The same is true of Maven for Java, to some extent. It seems like at least in Linux, the package manager will get your DLL's for you and coordinate all that, but as far as I can tell there's nothing similar for Windows? Do Windows programs that rely on DLL's just have to manually check what's already there, whether it matches their needs, and copy files over during the installation process if necessary?

Re: An alternative to shared libraries (2008)

#4

Post by dagenix »

> I like static linking. But code these days is getting extremely complex and bloated, so people needed an alternative. Instead of focusing on making their code more cleaner and lean, they started thinking about they can share this huge piece of complex and bloated code across several applications. If you think about it, if your code is small and clean, you wouldn’t feel the need for shared libraries.

One person's "bloat" is another person's "critical feature". When I see this word thrown around, I'm always left worried about what is going to come next. And then the author proposes avoiding shared libraries in favor of what sounds like a single-system microservices model. Such a model doesn't resolve any of the versioning issues of shared libraries but does add in all of the issues faced by a distributed systems combined with dramatically higher invocation overhead.

The stuff about plan 9 is interesting - but I'm left wondering why exactly this is being reposted now.

Re: An alternative to shared libraries (2008)

#5

Post by stagger87 »

_bxg1 wrote: post #3
_bxg1 wrote: post #2

I've done mercifully-little C(++) programming in my life, but the very idea of dll's has always seemed extremely fragile to me. Depending that deeply on the system configuration for basic functioning... ylech. I also can't help but wonder if they're obsolete these days, given how incredibly cheap disk storage is? Can anyone who works in that sector speak more to that?

These days I mostly work in JavaScript, and say what you will about NPM, at least it provides a consistent, reliable, central strategy for retrieving and organizing external dependencies (assuming you haven't just built them into your bundle). The same is true of Maven for Java, to some extent. It seems like at least in Linux, the package manager will get your DLL's for you and coordinate all that, but as far as I ca…

I develop small to medium size Windows applications. It's much easier for me to simply put all the DLLs I need in the installer. Just copy everything into the installation directory. Since Windows looks in the immediate directory first, that eliminates most potential conflicts. There are some things you might install onto the system like C++ redistributables, but even recently I have just started copying those DLLs into the installation directory too. Most people like this because the application directory is fully standalone and can be copied around from PC to PC.

Re: An alternative to shared libraries (2008)

#6

Post by drwells »

_bxg1 wrote: post #2

I've done mercifully-little C(++) programming in my life, but the very idea of dll's has always seemed extremely fragile to me. Depending that deeply on the system configuration for basic functioning... ylech. I also can't help but wonder if they're obsolete these days, given how incredibly cheap disk storage is? Can anyone who works in that sector speak more to that?

At least one C++ library that I rely on (that produces an incredible number of template instantiations in the object files) ultimately results in a 2 GB shared object file for the debug version (generating DWARF info for 300,000+ objects takes up a lot of space). The test suite for this project compiles and runs about 5,000 executables that link, in some way, to that giant shared object library. Statically linking the test suite would consume on the order of terabytes (I am not sure the exact number; I have never tried) of disk space which just is not feasible for a workstation, so dynamic linking is the only reasonable option. Dynamic linking also makes testing easier since I do not have to recompile tests as often.

That said, DLL hell is definitely real (as anyone who has ever used windows knows). Things are generally better (though not perfect) with OSs like Debian where dependencies are centrally managed across the whole system. In general, doing C++ development, I have found it advantageous to dynamically link: recompiling one library does not necessitate recompiling everything that depends on it.

Re: An alternative to shared libraries (2008)

#7

Post by theamk »

So an alternative to shared libraries is RPC over FUSE-like transport?

It is a sane idea and may work well, but I think the page overcomplicates it. Why bother with filesystem -- having cryptofs implement "getattr" and "readlink" seems like a total waste. Why not use the things designed for RPC?

For example, one may use raw unix sockets (this is how Xorg, and pulseaudio work), or D-Bus (this is how disk mounting in modern desktop linux works), or HTTP-based transports (this will be known as "microservices" then).

Re: An alternative to shared libraries (2008)

#8

Post by ebikelaw »

drwells wrote: post #6
_bxg1 wrote: post #2

I've done mercifully-little C(++) programming in my life, but the very idea of dll's has always seemed extremely fragile to me. Depending that deeply on the system configuration for basic functioning... ylech. I also can't help but wonder if they're obsolete these days, given how incredibly cheap disk storage is? Can anyone who works in that sector speak more to that?

At least one C++ library that I rely on (that produces an incredible number of template instantiations in the object files) ultimately results in a 2 GB shared object file for the debug version (generating DWARF info for 300,000+ objects takes up a lot of space). The test suite for this project compiles and runs about 5,000 executables that link, in some way, to that giant shared object library. Statically linking th…

Why don't you run your test suite with dynamic linking, then? I've certainly worked at large, successful companies with enormous C++ codebases where unoptimized tests are run with dynamic linking and production binaries optimized, stripped, and linked statically.
Post reply on HN