You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
The current implementation of the
copy_gcc_libs()
helper function doesn't work for multilib systems.kubler/engine/docker/bob-core/build-root.sh
Lines 59 to 70 in cc6ae36
The
find
commands will return multiple lines for the amd64 and x86 libraries, and thecp
command will fail due to embedded newlines causing the file to not be found.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 justlib
tolib64
.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: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?The text was updated successfully, but these errors were encountered: