On Fri, 28 Nov 2014, Michael Tokarev wrote:
> > ‣ intimate knowledge of the build system required, so you know
> > what precidely is pulled in (reading shlibs:Depends from the
> > build of the shared version is almost certainly wrong)
>
> Why it is wrong? To be this looks like the most accurate approach
The builds probably differ, especially when using autoconf.
> > In *all* cases, you also need
> >
> > • x=$(dpkg -S "$(readlink -f "$($CC -print-file-name=libgcc.a)")")
> > libgcc_pkgname=${x%%: *}
>
> Why?
Because some of these functions do end up in the resulting executable.
> This assumes it is gcc an it uses libgcc, so it wont work with,
> say, clang.
True. But either “clang -print-file-name=libgcc.a” will be empty,
or it will report libgcc.a which may or may not be pulled in. But
archive builds are not done using clang _yet_. I’ll revisit this
when that option exists, or so. It’s too fast moving a target at
the moment, anyway.
> Note also that if libgcc is used by shared build, it will
> also be listed in shilbdeps.
Fallacy. I know GCC interna better than I wish to. Most of
libgcc.a is always put into binaries; the shared libgcc is
mostly the libgcc_eh.a equivalent, and -static-libgcc is,
normally, the default for C language builds. (Also, it’s a
good way to keep the GCC version used to build it in the
archive.)
bye,
//mirabilos
--
15:41⎜<Lo-lan-do:#fusionforge> Somebody write a testsuite for helloworld :-)
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/alpine.deb.2.11.1411281602190.10...@tglase.lan.tarent.de
