On 1/6/24 09:35, Polarian wrote:
The nature of static linking is for portability, and although reading about it there is some use cases for static libraries [2], most programs which static link will compile the program from source by default.
Secondly this is slightly out of the scope of Arch Linux. Unless it is Rust or Go in which static linking is used by default, almost all software I have found written in C was dynamically linked, because there is little reason not to. The one big benefit of static linking is that it is a single executable, but when you have a package manager dealing with the libraries, it becomes redundant.
Plus, if everything was static linked, you would have hundreds and hundreds of duplicate references to libraries included within the executable. Also another issue is the need for recompiling to update libraries which are out of date/vulnerable, although Arch Linux already will do this in a lot of cases, if the ABI remains constant, if a dynamic library is updated, anything linked against it will continue to work. (The big if there is the ABI remaining constant :P)
Yep, it does help! My thinking was that since this, like arm-none-eabi-gcc (and arm-none-eabi-binutils, etc..) are for cross-compiling for a different target, I was unclear whether including the static lib may be beneficial for those creating distributable packages for the target (ARM or RISC). I don't create things that are redistributable on embedded devices, more for my own use, but not sure whether there was a need otherwise. We can leave it out for now, and if somebody has a special need, they can build it and pull the static lib from the source. Take less than 60 seconds to build anyway. The reason I didn't split the package here -- is it is TINY (oh, tiny...) Having a one file package and another 3-file package (plus the LICENSE) just didn't seem like a good use of space. I'll finish going through all comments, incorporating the changes, build and then repost the PKGBUILD of another review. -- David C. Rankin, J.D.,P.E.