Hi Jan, I will review this today, sorry for the delay.
Regards Bertrand > On 23 Nov 2020, at 15:16, Jan Beulich <[email protected]> wrote: > > In a few cases we link in library-like functions when they're not > actually needed. While we could use Kconfig options for each one > of them, I think the better approach for such generic code is to > build it always (thus making sure a build issue can't be introduced > for these in any however exotic configuration) and then put it into > an archive, for the linker to pick up as needed. The series here > presents a first few tiny steps towards such a goal. > > Note that we can't use thin archives yet, due to our tool chain > (binutils) baseline being too low. > > Further almost immediate steps I'd like to take if the approach > meets no opposition are > - split and move the rest of common/lib.c, > - split and move common/string.c, dropping the need for all the > __HAVE_ARCH_* (implying possible per-arch archives then need to > be specified ahead of lib/lib.a on the linker command lines), > - move common/libelf/ and common/libfdt/. > > v3 has a new 1st patch and some review feedback addressed. See > individual patches. > > 1: xen: fix build when $(obj-y) consists of just blanks > 2: lib: collect library files in an archive > 3: lib: move list sorting code > 4: lib: move parse_size_and_unit() > 5: lib: move init_constructors() > 6: lib: move rbtree code > 7: lib: move bsearch code > 8: lib: move sort code > > Jan >
