Closed zaibon closed 4 years ago
For the utils that is impossible to build statically, the flist still can have the binary + all libs needed. (as long as the lib names has the version number) they can co-exist on the node without conflict. I am not sure about libc though. But in worst case we make sure that all are build with the same libc version
And the system would take cares to set all LD_LIBRARY_PATH
etc. environment ?
It would not be more easy to just chroot inside the flist which would have all the libs needed ?
No, a /usr/lib can have libx.1.so
and libx.2.so
. the dynamic linker will take care to load the correct version based on the binary it's trying to excute. LD_LIBRARY_PATH then is not needed
That's not what I mean. What if the flist provide a library already present ? What you talk about is only when using libraries which doesn't have same major version.
So what? if the same library is present multiple time supposedly 0-fs will not re-download it. so basically it's a copy from local cache to final place on the rootfs. But eventually everything still should work, no ?
New static build tools are included now and can be used to produce static binaries using musl. This is used for corex already. This could be extended for other usage later. Closing this since we don't need more for now.
@maxux please fill in first comment.
EDIT (maxux): My idea was compiling every subsoftware we use completely static to not depend on anything on runtime and just update the binary when we want to upgrade.
Compared to current build system, I'm investigating to use
portage
from Gentoo, which was the base idea few years ago. They have amusl
overlay we can reuse to get working code compiling against musl and try to get static build out of it.