Dynamic linking and new languages/compilers.

Name
Email
Subject
Comment *
File	Select/drop/paste files here
* = required field	[▶ Show post options & limits] Confused? See the FAQ.

Embed	(replaces files and can be used instead)
Options	Do not bump (you can also write sage in the email field) Spoiler images (this replaces the thumbnails of your images with question marks)
Password	(For file and post deletion.)
Allowed file types:jpg, jpeg, gif, png, webm, mp4, pdf Max filesize is 8 MB. Max image dimensions are 10000 x 10000. You may upload 1 per post.

Dynamic linking and new languages/compilers. Anonymous 07/30/15 (Thu) 16:25:03 e14356 No.2939

So, for years, at least in the unix field, we've been using shared libraries to avoid duplication across every binary. This usually goes tightly coupled with a package manager. If myprogram needs libcrypto.so, it "depends" on it, and the package manager makes sure it's installed.

Static linking can be useful for binary redistribution, and when a program requires a specific version of a library to work.

Now, lately, some new (admittedly interesting) programming languages have popped up (Better worded: they have gained some popularity). I've found Go, Rust and Nim, though there could be others.

These three, all come with a package manager of their own to fetch and build dependencies, which is totally fine. The only problem is, it is very difficult if not impossible to build the dependencies as shared libraries, and link the binaries dynamically.

Sure, this might be a good idea if you just want to redistribute a binary, or if you want your dependencies at a very specific version.

But how will system package managers handle this? Sure, they can go the lazy way and provide the static binary, but that goes against what a package manager is meant to do (Hurp durp drag and drop in (/usr)/bin).

Why can't these languages/compilers at least make it easy to build shared objects and dynamically linked binaries "the olde way"?

Anonymous 07/30/15 (Thu) 21:39:15 000000 No.2944

There's a lot of overhead with dynamic linking: http://ewontfix.com/18/

Anonymous 07/31/15 (Fri) 08:13:43 e14356 No.2950

>>2944

That's a really shitty reason.

Mostly because these language's compilers link dynamically to at least libc, and other shared libraries written in C/C++ if they need to (hell, Nim seems to have it's own ld).

Why the fuck can't these compilers generate shared libraries themselves in a feasible way? (Rustc can, but cargo, it's makefile replacement, can't. So you have to go out of your way to call rustc manually.)

Anonymous 08/02/15 (Sun) 00:58:54 06f8d9 No.2953

>>2939

There aren't simply many good reasons for dynamic linking in the age of terabyte drives left.

The only one good I can think of is if you have a library that is used by the main program as well as by some interpreters FFI for some script that comes with the software.

And even that isn't necessarily a good reason, since those newer languages should making writing tools things easier.

Better compile the whole source code in one piece, because good compilers can make more of it. That's why C modules are expensive, once you get a halfwhat good JIT compiler for a classical scripting language.

Anonymous 08/02/15 (Sun) 22:50:50 b1d6bc No.2960

>>2950

[lib]
name = "..."
# this could be "staticlib" as well
crate-type = ["dylib"]

Anonymous 08/04/15 (Tue) 13:19:52 e14356 No.2964

>>2953

>There aren't simply many good reasons for dynamic linking in the age of terabyte drives left.

Heartbleed happens. What do? Dynamic: Fix libcrypto.so. Static: Fix libcrypto and recompile all the programs that use it.

Same goes for library updates that contain other kind of bug fixes, or just replacing them in general.

There aren't simply many good reasons for static linking in the age of quad-core cpus left.

In a more serious note though, I don't see any reason why a distribution would want their binaries to be statically linked and portable.

This is why I think both options should be easily available.

>>2960

Ah, thanks for mentioning that. Last time I looked it up I couldn't find anything about it.

Anonymous 08/04/15 (Tue) 16:15:41 31077f No.2965

>>2964

>Static: Fix libcrypto and recompile all the programs that use it.

Not a problem in programming languages that take ages to compile. Also known as: C++, actual but not future Rust

Anonymous 08/04/15 (Tue) 16:24:43 31077f No.2966

>>2964

>In a more serious note though, I don't see any reason why a distribution would want their binaries to be statically linked and portable.

Just look into your average bistros dependency tree. It's a total clusterfuck.

I wouldn't care so much for that.

The real problem it leads to is that people rely on binary compability for fixes and then the inevitable happens and shit crashes/behaves in shit ways and people download malware'd DLLs and stuff etc pp.

Anonymous 08/04/15 (Tue) 16:25:18 31077f No.2967

>>2965

*Only a problem

Anonymous 08/05/15 (Wed) 10:09:49 e14356 No.2975

>>2965

Taking ages to compile is subjective. It depends on the size of the project and the computer it's compiled on.

That said, with such a heavily depended on library as libcrypto, it takes a considerable amount of time to recompile everything.

>>2966

>Just look into your average bistros dependency tree. It's a total clusterfuck.

Having everything statically linked does not remove the need for a dependency tree. You have all the build-time dependencies, and sometimes even non-library runtime dependencies.

>The real problem it leads to is that people rely on binary compability for fixes

I have no idea what you're talking about. There's a reason a program changes it's libmine.so.x.x.x version if it breaks compatibility. Some package managers check for that.

>and then the inevitable happens and shit crashes/behaves in shit ways and people download malware'd DLLs and stuff etc pp.

In my noob days of ubuntu I've never had to touch a .so file because it was "missing" or broken. Only windows has that problem where it doesn't handle dependencies right. Only problems with .so files I have now are either severly outdated programs that try to link to some library that merged with another (libporttime, for example), and programs I install outside of the package manager, which just require recompilation.

Anonymous 08/05/15 (Wed) 15:08:20 46d804 No.2977

>>2975

>Having everything statically linked does not remove the need for a dependency tree. You have all the build-time dependencies, and sometimes even non-library runtime dependencies.

That wouldn't transist into the repositories. At least not into the binary part.