[kwlug-disc] Xubuntu 22.04 to 24.04 Upgrade

[Doug Moen]

I'm talking about C++ templates, generic functions in Go and Rust, macros and compile time module configuration in Rust. If a library function is implemented as a template, generic function, or Rust macro, then each user of the function gets a different machine code representation of that function, based on the arguments that were passed, and that's different from C, where each library function compiles into a single machine code implementation, which can then be shared between applications in a shared library. Rust also supports specializing the machine code for an entire library based on module configuration parameters.

I would argue that the doctrines that packagers of binary-based Linux distros have built up around shared libraries are very specific to the C language. When these doctrines were formed, all binary executables were compiled from C or early stage C++ code.

C++ has historically required you to partition your code into *.h and *.cpp files. Generic library functions (aka templates) are placed in header files, which allows for compile time code generation to specialize the template, while non-generic functions are placed in *.c files, which can be compiled into shared library code. So the generic/nongeneric split is something you explicitly manage. The syntax, tooling and culture of C encourage you to put most code in *.c/*.cpp files. But this *.h/*.cpp thing is a nuisance, just one more thing to manage, and the C preprocessor was always just a kludge. C++20 fixes this, and now you can define modules containing all of your library code, without partitioning it into the static and dynamic parts, just like Go, Rust and Zig. This makes it a lot more convenient to write generic code. Some languages (the ones I'm more excited about using) take this further. In the style of programming promoted by the Haskell community, the majority of functions are generic. In Julia, all functions are generic, all function bodies are specialized into machine code based on the argument types.

So I'm not really persuaded by moralistic sounding arguments against the use of non-C programming languages, based on how well they support compiling libraries into *.so files like in the C world. I think we have better, safer programming languages now, and we should be using these languages in preference to C. Packaging needs to evolve to be in sync with how modern programming languages work. Even the LGPL needs to evolve, since it assumes that libraries are written in C or C++ using header files.

Doug.

On Wed, Oct 9, 2024, at 5:04 AM, Chris Frey wrote:
> On Tue, Oct 08, 2024 at 08:33:50PM -0300, Doug Moen wrote:
>> Modern system languages like C++, Rust, Zig, and (recently) Go get
>> much of their power and performance from compile time code generation
>> features that allow library functions to be compiled into different
>> machine code specialized for different callers. These features are
>> incompatible with compiling a library into a single *.so file that
>> is shared by all applications. Static linking must be used.
>
> Are you referring to things like the inline keyword in C++?  That code is
> often in the header files and can be duplicated in the program binary,
> yes.
>
> But that doesn't mean dynamic libraries are impossible, it simply
> gives the choice to the programmer.  And both C++ and Zig give
> that choice.
>
> There's a chunk of code in the dynamic libstdc++ .so file
> that can be shared, even though there are tons of templates in the
> headers that generate static code on the fly as well.
>
> And C++'s stable ABI makes it possible to explicitly instantiate
> a template with specific types and have that stored in a .so file too,
> if the programmer really wants to go in that direction.
>
> - Chris
>
>
> [1] Hacked-together proof of concept of templates explicitly placed in
> a shared library:
> 	http://digon.foursquare.net/explicit.tar.bz2
>
>
> _______________________________________________
> kwlug-disc mailing list
> To unsubscribe, send an email to kwlug-disc-leave at kwlug.org
> with the subject "unsubscribe", or email
> kwlug-disc-owner at kwlug.org to contact a human being.