Re: RFC: -Wl,--as-needed by default (and glibc ldconfig file trigger)
On 21 November 2017 at 16:36, Daniel P. Berrange <berrange(a)redhat.com> wrote:
[..]
> > > > Counting numbers of affected packages by guessing
is very bad idea.
> > >
> > > Call it educated guess if you want.
> >
> > You know, there is a way to get more reliable data: do scratch builds of
> > all Fedora packages and analyze the results. Then we'd know _exactly_
> > how many packages would need to be patched.
Yes of courses. Alternatively quite precise data could be generated by:
a) build modified fedora-rpm-macros package and after this will be
possible to rebuild all Fedora packages to check which one are
failing. Such list of failing packages it will be necessary to compare
with koji data to remove those which is already known that they are
failing and on left list will be necessary to do one by one analyse to
identify those which are failing by add --as-needed to the linker
options. Still this list could be not 100% accurate as all Fedora
packages are constantly changing. You can do this if you have time and
other resources.
b) it is possible as well to take all current binary packages to
extract all elf binaries. After such extraction is possible to feed
database about list of all used and provided SONAMEs, list of all
external public symbols used and provided by each elf binary. After
analyse those data will be be possible to say:
1) which one binaries are linked with to many SONAMEs
2) which one binaries are still using some symbols which are available
only on run-time stage by indirect linking with libraries which are
linked with to many other libraries (AKA underlinking)
3) such static analyse can catch all possible run-time symbols clashes
Such statistic analyser/processor maybe it would be good to have in
Fedora but it would require relatively big investment into development
to catch probably only few cases each year.
********
Such effort to develop new infrastructure is way bigger than just
start use --as-needed by default then rebuild everything and at the
end fix only few new failing packages affected by use indirect
run-time linking. *** This way is WAY EASIER. Full stop ***
********
> ...depending on how thoroughly the analysis is done, as the
breakage caused
> by an erroneous --as-needed might, at least in principle, only happen at
> runtime, rather than at build time.
Pretty much all software in Fedora is already shipped in other distros
which have taken this linking approach for a long time. So it is pretty
reasonable to expect these kind of bugs have been identified & fixed
by maintainers in other distros already. There may be edge cases remaining
which no user has yet managed to tickle, but that's true of many aspects
of Fedora. eg when we introduced the hardened build flags, there were
places where we wouldn't know about breakage until much later. Requiring
perfection before making this kind of change effectively means never doing
the change.
Guys I'm really appreciate that you are still thinking about some
technical aspects or other things not related straight to Fedora.
As I wrote (IMO) now main obstacle is not technical and it is more
about "which buttons needs to be pushed in Fedora to make it happen?"
Looks like no one want to put wood under this furnace and this is why
this inferno^KFedora packages have tenths of thousands bogus SONAME
dependencies still dangling between the packages.
When this will be implemented in Fedora maybe as well it will be
easier to convince binutils maintains to remove all --as-needed
optional code and leave this option as kind of void option.
And again: the same issue is with ldconfig file trigger which needs to
be added to glibc.
This few lines glibc spec improvement can reduce install or upgrade
packages time by at least 20% (less memory on the system or slower
storage than impact will be even bigger) by not wasting time on
ldconfig multiple time executing in every packages with libraries
scriptlets.
This change as well is about regain a lot of time and IOs on Fedora
build infrastructure.
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH