Bug#768876: unblock: busybox/1:1.22.0-14
28.11.2014 18:06, Thorsten Glaser wrote:
> 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
it supposed to be "To me".
> The builds probably differ, especially when using autoconf.
Probably? If they differ it is a bug which should be fixed.
In this case it is irrelevant because busybox only uses libc
and probably libm which both comes form the same package anyway
(plus whatever libgcc it is pulling in too). Even if some other
lib will be used, the same lib will be used for both static and
non-static versions.
>>> 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.
Um. Maybe we should assume exact versions of software running in
buildds too? I don't think this approach scales, to me it is wrong,
and we should use some more generic way.
BTW, how about somethig like gcc -v (I'm not sure it is the right
option actually) which shows all libs it actually used for linking -
run it once, find out all actual libs and go from there, translating
the list to debian package names. I think _that_ will be the only
real thing.
But for now, current way to construct built-using from shlibdeps,
maybe adding libgcc/gcc too on the way should be enough, for this
very package anyway. And more, I'm not sure at all I want to
perform another series of experiments while asking for an unblock...
Besides, this process should be automated with some helper, something
like dh_built-using, I dunno. Or else, due to the fact that it is
very difficult to get the value right, we'll have it all wrong, and
differently wrong in every place too.
>> 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.)
Oh well. Do you think I should reopen this bugreport?
Thanks,
/mjt
Reply to: