Re: [Buildroot] Large number of duplicate files in sdk

[Grant Edwards <grant.b.edwards@gmail.com>]

On 2024-11-21, Peter Korsgaard <peter@korsgaard.com> wrote:
> > On 2024-11-20, Grant Edwards <grant.b.edwards@gmail.com> wrote:
> >> When I do a "make sdk" (using 2024.02.6), the resulting tarball
> >> contains tons of duplicate files. [...]
>
> Some duplicates are expected, E.G. we have a number of packages that
> can be built for the host and the target (E.G. python3), so if your
> SDK has both host and target variant enabled then there will be some
> duplicated files.

Yes, that I expected. Those files need to be in both places. You can
save some space by hardlinking them, but you actually need two
"copies".  What surprised me was the duplication of the include and
library trees from the toolchain.

I would have thought that foo.h, libfoo.a, libfoo.so, and libfoo.so.1
would only need to be in one place (each). Does there need to be a
copy in both sysroot and opt/ext-toolchain?

Some effort was expended to avoid duplicating the toolchain binaries
themselves, but all of the other files are duplicated.

> So mainly the copy we do of the external toolchain into host/.

And I limited my custom "de-dupe" utility to that case: hard-linking
files that were conceptually "the same file" in duplicate trees. I
didn't link files within sysroot that happened to have identical
content or link files within opt/ext_toolchain because they had
identical content.

> I think we could be smarter about using hard links instead of
> actually copying files / perhaps use hardlink before creating the
> SDK tarball:

We're probably already further down this rabbit hole that it deserves,
but if an include/library file needs to be in sysroot, does it still
need to be in the opt/ext_toolchain directory also? Can we move the
file instead of copying/linking it? Are there some situations where
libfoo.so.1 is used from sysroot and other situations where it is used
from opt/ext-toolchain?  If yes, then moving the file won't work. Are
the two libfoo.so.1 files ever expected to differ? If not, then
linking seems to be the right answer instead of copying.

I tried using symlinks from sysroot to opt/ext-toolchain instead of
hardlinks, but I could not get that to work. I didn't persue that for
long, but it appeared that <something> was refusing to follow symlinks
for <some?> library files. The file was found in the expected
location, but it was the "wrong type": it was a symlink.

--
Grant


_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot