minimal

minimal copied to clipboard

The sysroot is currently unused and overlay bundles are build against libraries and headers installed on the host. (This is undesirable for a number of reasons, one being that libraries on the host are not necessarily binary-compatible with the ones build and used on the overlay rootfs)

Preferably using --sysroot and not -spec

@bauen1 Do you have an example of how to do this?

I'm currently working on this https://github.com/bauen1/minimal/tree/sysroot but this breaks a lot of bundles that depend on ncurses for example. I'm not sure how to handle dependencies because the order of OVERLAY_BUNDLES would suddenly become very important if you just copy the libraries to the sysroot.

This is very serious problem with all Linux based distributions. I will open separate issue for the bundle dependencies.

@bauen1 - I believe the dependency problem can be resolved in relatively easy way (at least in theory). Please take a look at #103. I will start working on it in December, unless someone provides implementation by then.

One more thought - assuming the --sysroot approach works, there should be a configuration flag which enables/disables this functionality. This is useful if for some reason the MLL user would like to switch to the older (i.e. the current) build approach.

I don't think a configuration flag is necessary, because the current build system should not be providing a working install.

I mean when it works, in the future. :)

ldd from glibc is a useful tool for viewing the libraries required for a binary. Is there a reason the glibc_full bundle only copies the libraries and not the packages? Would it make sense to create a second overlay glibc_lib for only the libraries?

Back then I only needed the so files. I never thought of adding the binary tools. The current glibc_full bundle can be extended to include them.

Regarding #105 - it turned out that adding the GLIBC executable files (ldd in particular) is not that simple. This feature brings value to MLL and I think it should be completed before the next MLL release.

@bauen1 - take a look at #103. I've implemented simple dependency resolution mechanism which passed my preliminary build test.

Just some thoughts.

There is significant difference between compile-time artifacts and runtime artifacts. If the build process for particular bundle generates everything which is needed for compile-time, then these artifacts have to be merged in the sysroot area. On the other hand, at runtime usually the bundle has to provide only some binaries and perhaps some 'so' libraries. We don't really care about compile-time object libraries (.a files), 'man' pages, etc.

One way to handle this is to enhance the build process for the bundles one step further and merge the compile-time artifacts separately from the runtime artifacts. Just for information, now all bundles merge runtime artifacts in the overlay root area. It should be quite easy to add few more install/copy operations in each build script and provide the necessary compile-time artifacts in the sysroot area.