On Friday, 2 February 2018 at 14:04:09 UTC, Russel Winder wrote:
On Fri, 2018-02-02 at 10:03 +0000, Atila Neves via Digitalmars-d wrote:


[…]
Whether it's .a or .so depends on the dependent package being `staticLibrary` or `dynamicLibrary`. It's possible for a package to be both if it has a configuration for each.

I think that is one of my points, the package source downloaded from the Dub repository should not be determining whether a .a or ,so is produced, it should be determined by the receiver of the downloaded package.

Personally I don't even see the point - just link all the .o files. In a traditional build system static libraries might be useful to specify that multiple targets link to this particular binary blob. With dub there's only ever one binary anyway.

But a static library is just a collection of .o files so I think it fits with "link all the .o together".

Not quite. There's an extra step and when linking with a static library unused symbols are thrown away by default. That hid a dmd bug in 2.078.0 that only manifests when linking with the object files themselves.


It is clear that there is a move in the Go, Rust, D communities to rejecting the concept of shared library, and that 100MB executables are acceptable.

On a desktop, 100MB executables are, at least to me. Shared libraries aren't going to magically make 100MB executables disappear, it depends on how much code is actually shared.


And at this point in time I think shared libraries are mostly a mistake. The only time I use them is when I have to, as in when developing Python extensions.

The single biggest argument for shared libraries in D is GtkD. Linking an executable with a static GtkD library takes ages, and when developing you do a lot of linking. Fast turnaround, and thus reasonable development times, requires use of a shared library for GtkD.

That's a fair point.

Atila

Reply via email to