Hi Guillem! On Tue, 14 Jan 2020 at 02:01:09 +0100, Guillem Jover wrote: > The problem I've got is that I upgraded to gcc-10 from experimental, > which pulled in libgcc1-s1 and libgcc1 (that I later removed), neither > of which install libgcc_s.so.1 under /lib/$MULTIARCH anymore. The first > installs the shared library under /usr/lib/$MULTIARCH, the latter > under /lib/ (although that one might be in error, as there's an empty > multiarch dir under /lib in that package), so that logic does not find > it.
I see, thanks for the follow-up!
> IMO the assumption that libgcc will be located in the same directory
> as libc is incorrect, first because it comes from a different source
> package, and second because nothing says they need to be on the same
> directory. :)
Fair enough, and also ldd(1)'s output isn't meant to be parsable.
Finding libgcc that way a dirty hack which has served us well so far.
Not sure which one was first but FWIW there are a couple of other
packages using the same libc-based logic to determine which runtime
library to copy into the initramfs:
https://codesearch.debian.net/search?q=%2Flibc%5C%5C.so&literal=0
but rather than reinventing the wheel each on our end I'd welcome a tip
to find where libgcc_s (and other runtime libraries such as libnss) is
installed in a robust fashion. At least the one needed for a given
binary, but if there are multiple versions I guess shipping them all
wouldn't cause too much overhead. Parsing the output of `ldconfig -p`
sounds a bit overkill, but perhaps it's better (or at least not worse,
the output isn't meant to be parsable either AFAICT). If there is a
need for a complex logic I guess this could be done once and for all in
/usr/share/initramfs-tools/hook-functions.
Otherwise, I guess we could amend the sed script to allow an optional
/usr prefix (until the library moves elsewhere again).
Cheers,
--
Guilhem.
signature.asc
Description: PGP signature
