[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PROPOSAL] Builder, a build system integration for Emacs

From: Madhu
Subject: Re: [PROPOSAL] Builder, a build system integration for Emacs
Date: Sun, 28 May 2023 15:50:25 +0530

* Gregory Heytings <3a315ddd3aa7d7cda74e @heytings.org> :
Wrote on Sat, 27 May 2023 00:25:25 +0000:
>>> This is the misconception I pointed to in my previous post: Rust
>>> libraries are not dynamic libraries, they are compiled into the
>>> program.  This eliminates all compatibility problems: you can have
>>> as many programs as you want on your computer, each one compiled
>>> with a different version of a given library.
>> I have trouble understanding that.  Before dynamic libraries, we
>> used static libraries.  Each library was a .o file, made by
>> compilation.
> Rust libraries are neither dynamic (compiled separately and loaded at
> run time) nor static (compiled separately and linked at build time),
> they are always compiled together with the program.
>> But how can each program have its own version of one and the same
>> library?  Does Rust store all libraries as **source code** and
>> recompile each library each time that library is linked into a
>> program?
> Yes, that's how it works.  For example, there are 25 versions of the
> "itoa" library (which does the opposite of the well-known "atoi"
> function), and you could have 25 different Rust programs on your
> computer, each one using on a different version of that library.  If
> you build these programs yourself, you will end up, in your local
> CARGO_HOME directory, with a copy of the source code of the 25
> versions of that library: itoa-0.1.0, ..., itoa-1.0.6.

This (and in golang) is the spiritual equivalent of having (and
shipping) every variant of functions in all released versions glibc
available, and a program may "link" to any of the versions. Where
"linking" means compiling all the sourcees, using the current llvm
satisfying the hardware and build requirements including memory and
hardware and obligatory traffic to the repo homeservers (no payas you
cannot change crates.io, you can only add a second repo server, and
change all your config files to use it)

Conventional thinking would abhor at the horror of having all versions
of all glibc functions all the time, even if you have got the whole
thing from a repo server. Now why is this is a good idea?  The folk
investing in it and the jobs and also investing in the hardware and
bandwidth probably know.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]