Bug#768876: unblock: busybox/1:1.22.0-14
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). Thanks, /mjt 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. bye, //mirabilos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768876: unblock: busybox/1:1.22.0-14
Michael Tokarev m...@tls.msk.ru (2014-12-01): So, can someone please tell me what's wrong with this unblock request? I did write in my first reply: “At this stage, I'd rather see the security fix only.” 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). Since these versions are (AFAICT) history now, having complex b-depends and/or b-conflicts looks like a thing we would like to avoid, which leads us back to the quote above. Mraw, KiBi. signature.asc Description: Digital signature
Bug#768876: unblock: busybox/1:1.22.0-14
On Thu, 27 Nov 2014, Michael Tokarev wrote:
(The Built-Using field generation is a bit fun here: I asked on IRC
how people identify which libc is in use, and got various somewhat-
incpmplete replies (the prob is that on different arches, libc package
is named differently). So I invented my own way for busybox, because
You didn’t ask in the #!/bin/mksh channel on IRC (= Freenode) ;-)
So let me add mine:
‣ 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)
In the mksh case, I have a switch between different libcs to use.
For dietlibc and klibc, the cases are clear:
• libc_pkgname='libklibc-dev linux-libc-dev'
• libc_pkgname=dietlibc-dev
For (e)glibc, or rather, “the default libc”, a little trick:
• x=$(dpkg -S $(readlink -f $($CC -print-file-name=libc.a)))
libc_pkgname=${x%%: *}
In *all* cases, you also need
• x=$(dpkg -S $(readlink -f $($CC -print-file-name=libgcc.a)))
libgcc_pkgname=${x%%: *}
Now you need to get from that to the corresponding source packages:
for x in $libc_pkgname $libgcc_pkgname; do
dpkg-query -Wf '${source:Package} (= ${source:Version})\n' $x
done | sort -u | {
srcpkgnames=
while IFS= read -r x; do
test -n $x || continue
test x$x = x (= ) continue
echo Built Using: $x
test -z $srcpkgnames || srcpkgnames=$srcpkgnames,
srcpkgnames=$srcpkgnames$x
done
echo mksh:B-U=$srcpkgnames builddir/substvars
}
bye,
//mirabilos
--
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database” ‣‣‣ Please, http://deb.li/mysql and MariaDB, finally die!
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768876: unblock: busybox/1:1.22.0-14
28.11.2014 15:11, Thorsten Glaser wrote:
On Thu, 27 Nov 2014, Michael Tokarev wrote:
(The Built-Using field generation is a bit fun here: I asked on IRC
how people identify which libc is in use, and got various somewhat-
incpmplete replies (the prob is that on different arches, libc package
is named differently). So I invented my own way for busybox, because
You didn’t ask in the #!/bin/mksh channel on IRC (= Freenode) ;-)
I asked in several debian-related places, since this is a debian-specific
thing.
So let me add mine:
‣ 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
really.
In the mksh case, I have a switch between different libcs to use.
For dietlibc and klibc, the cases are clear:
Wug.
[]
In *all* cases, you also need
• x=$(dpkg -S $(readlink -f $($CC -print-file-name=libgcc.a)))
libgcc_pkgname=${x%%: *}
Why? This assumes it is gcc an it uses libgcc, so it wont work with,
say, clang. Note also that if libgcc is used by shared build, it will
also be listed in shilbdeps.
Thanks,
/mjt
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768876: unblock: busybox/1:1.22.0-14
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-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768876: unblock: busybox/1:1.22.0-14
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. bye, //mirabilos -- [16:04:33] bkix: veni vidi violini [16:04:45] bkix: ich kam, sah und vergeigte... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
