edannenberg
copy_gcc_libs() with multilib
The current implementation of the copy_gcc_libs() helper function doesn't work for multilib systems.
https://github.com/edannenberg/kubler/blob/cc6ae3601f4d9d076e7f4b6140bc542741d8b131/engine/docker/bob-core/build-root.sh#L59-L70
The find commands will return multiple lines for the amd64 and x86 libraries, and the cp command will fail due to embedded newlines causing the file to not be found.
cp: cannot stat '/usr/lib/gcc/x86_64-pc-linux-gnu/14/libgcc_s.so.1'$'\n''/usr/lib/gcc/x86_64-pc-linux-gnu/14/32/libgcc_s.so.1': No such file or directory
I'm working on a PR to fix this.
However, one thing confusing me is the code use ${_EMERGE_ROOT}${_LIB}, and for amd64 this will be /emerge-root/lib64. So, the source will be /usr/lib/ and the destination will end up being /lib64/ (in the resulting container) - e.g no /usr/ and changes from just lib to lib64.
With merged-usr, /lib{,64} are symlinks to /usr/lib,{64}. But in the resulting container it won't be doing merged-usr symlinks.
The /etc/ld.so.conf doesn't contained the /lib{,64} directory. In my experiments it contains:
# contents of /etc/env.d directory.
include ld.so.conf.d/*.conf
# ld.so.conf autogenerated by env-update; make all changes to
/usr/lib
/usr/lib64
/usr/local/lib
/usr/local/lib64
Should copy_gcc_libs() be reproducing the /usr/lib{,64} directory structure?
Should the resulting containers be following the merged-usr layout with symlinks?
Or is it ok (safe) to change this to /lib{,64) (drop /usr/)?
If the /usr/ bit is dropped, should /etc/ld.so.conf be updated to include /lib{,64} (no /usr/) and /etc/ld.so.cache in /emerge_root be regenerated?
