Bug#768876: unblock: busybox/1:1.22.0-14
- To: Thorsten Glaser <email@example.com>
- Cc: firstname.lastname@example.org
- Subject: Bug#768876: unblock: busybox/1:1.22.0-14
- From: Michael Tokarev <email@example.com>
- Date: Mon, 01 Dec 2014 18:54:25 +0300
- Message-id: <[🔎] 547C8F31.firstname.lastname@example.org>
- Reply-to: Michael Tokarev <email@example.com>, firstname.lastname@example.org
- In-reply-to: <alpine.DEB.email@example.com>
- References: <firstname.lastname@example.org> <alpine.DEB.email@example.com> <54788E02.firstname.lastname@example.org> <alpine.DEB.email@example.com> <firstname.lastname@example.org> <alpine.DEB.email@example.com>
So, can someone please tell me what's wrong with
this unblock request?
I can try to fix built-using generation adding gcc
to the mix but I'm afraid to do that this late in
the release cycle, especially after it required so
many iterations to get the most important in this
context part of built-using. Note that this most
important part - which prompted the original bug
report wrt built-using - is here with proper
value (it is glibc which had bug in several
versions, producing buggy static binaries).
28.11.2014 18:33, Thorsten Glaser wrote:
> On Fri, 28 Nov 2014, Michael Tokarev wrote:
>> Um. Maybe we should assume exact versions of software running in
>> buildds too?
> No, only things that end up in the binaries.
>> 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 -
> Yes, except that is not parsable, and varies by compiler.
>> 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.
> I agree. Maybe -Wl,-v or -Wl,-t instead. We always use binutils…
> but these options also have their shortcomings.
>> 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
> No, this requires intimate knowledge of the build system in use;
> autoconf will break during the configure phase if you use some
> compiler flags (like -Werror) for example, so you have to inject
> that flag somewhere.
> Also, not everything is always static, and if you build multiple
> binary packages, you need to track what is what anyway.
> I think that, for B-U, we can’t find a generic solution.
>> Oh well. Do you think I should reopen this bugreport?
> I think you probably only should add the libgcc.a provider
> and cross fingers for now. B-U are not unimportant, but a
> real PITA anyway right now.