On 21 November 2017 at 10:43, Igor Gnatenko <ignatenkobrain@xxxxxxxxxxxxxxxxx> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On Tue, 2017-11-21 at 10:26 +0000, Tomasz Kłoczko wrote: >> So is it any final decision about start use by default --as-needed in >> linker options? > > Can you link Change Proposal you (or someone else) submitted? I have not heard > anything about that. https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/3 [..] >> In my opinion number of affected packages will be very low (few). > > Counting numbers of affected packages by guessing is very bad idea. Call it educated guess if you want. More than decade ago when I've been leading maintenance of PLD distribution applying --as-needed on the scale of ~3.6k source packages. During introduction of such change none of the packages has been left behind and ~hundredth packages have been fixed by add <package>-as-needed.patch files. Most of those patches have been pushed to original source trees. After what happened in PLD for example SuSE added to own binutils package patch --- ld/ldmain.c.orig 2016-01-27 13:44:14.092983985 +0100 +++ ld/ldmain.c 2016-01-27 13:44:37.389254054 +0100 @@ -286,6 +286,8 @@ main (int argc, char **argv) #ifdef DEFAULT_FLAG_COMPRESS_DEBUG link_info.compress_debug = COMPRESS_DEBUG_GABI_ZLIB; #endif + if (getenv ("SUSE_ASNEEDED") && atoi(getenv ("SUSE_ASNEEDED")) > 0) + input_flags.add_DT_NEEDED_for_regular = TRUE; ldfile_add_arch (""); emulation = get_emulation (argc, argv); which is kind of JFDI/dirty hack to add --as-needed as default linker behavior. Other distributions like Arch Linux are using --as-needed as well as default liner options. As result many more packages have been fixed and those fixes mostly have been in meantime as well integrated into source tree. PLD, SuSE and Arch are not only iterations done on full scale distributions. In the past I saw many --as-needed fixes in Debian patches and now it is hard to find those patches. SuSE has now ~12k source packages. AltLinux (almost 18 src.rpm) IIRC is using --as-needed as well. I'm not sure about Mageia (+20.5k src.rpm) .. I wouldn't be surprised if Fedora is one of those few which are still not using --as-needed. Do you really need more? Many projects on switching from autoonf/automake/libtool to meson have been test as meson adds --as-needed to linker options so all packages build using meson are free of those issues. More than decade ago *all* KDE packages added in own build frameworks use --as-needed. People around the world wasted probably thousands man/hours to implement use --as-needed in many packages (for example net-snmp has [tkloczko@domek net-snmp-5.7.3]$ ./configure --help | grep need --disable-as-needed Link libperl against applications rather This autoconf switch has been added only because net-snmp maintainer did not understood nature of some perl related issues which should not be fixed in net-snmp (btw necessary fix in perl in mean time has been integrated). There is hundreds of packages which are already adding --as-needed to the linker options in own build frameworks. Probably more than year/man of developers time has been wasted because binutils ld still is not producing by default DSOs linked with *only* libraries which are needed. To be hones still I do not understand why --as-needed is the option because default ld behavior is causing produce non-optimally linked binaries on MASSIVE SCALE. This option should be IMO removed as current --as-needed behavior should be hardcoded into ld!!! One line change in redhat-rpm-config package will fix all those issues at least on the scale of Fedora distribution. I'm trying to support push such change in Fedora as for me it is way easier to discuss importance of --as-needed than discussing it with binutils maintainers who in many cases spend many years maintaining only binutils code and by this organically do not understand why ld should always produce correctly linked binaries. So this is why I'm 100% sure that in +99.9% Fedora most frequently used packages it will be no issues related to start use --as-needed. If anything still could require add (trivial) fixes will be amongst those less frequently used. [..] >> As f28 development cycle still is in the middle IMO it is right time >> to apply at least one of those two changes (if not both). > > While personally I think both changes are good to make, there seem to be some > concert from glibc developers so it would be better if you could discuss this > in bugreport with glibc maintainers and FPC members. Looks like you did not check what is in the comments of the ticket which I've posted (https://bugzilla.redhat.com/show_bug.cgi?id=1380878). In comments of this ticket is not only whole discussion but as well concrete propositions about how to implement glibc file trigger (with my personal proposal about how to implement those triggers in simplest possible form). > Also I think we should not mix those 2 things. Yes they are however looks like both changes are sharing the same non-technical reason why they are still not introduced despite very big positive impact which they care separately (probably bigger than many other large changes in Fedora introduced in recent years). This is only reason why I've decided to glue those tow things together. To be hones I'm not expecting any technical discussions about those two changes as whatever was to discuss from technical point of view already have been disused in more than last few years or decade in case of --as-needed. As all has been discussed and everything is ready I'm only expecting answer from Fedora Packaging Committee on the question "when?" and maybe some comments about "why not now yet?" (it maybe already scheduled some other large scale change in Fedora and here is some collision ..??). As I wrote IMO looks like reasons why those two changes still have not been integrated *are the same* and are not technical. I can only guess most of the Fedora maintainers/developers are usually working on scale of the single packages or few of them. There is only few Fedora guys able to work on scale of whole groups of the packages and even less on scale whole distribution. Most of the Fedora developers are enough skilled and even less enough experienced and confined to support such changes. As result whole situation now is like in old joke about angels visiting inferno to check why furnaces stopped heating it up .. In other words looks like both changes are stuck in Fedora decision making process mixed with shortage of man/hours people able to introduce those changes. As result we should be not discussing anything related to ld --as-neded or glibc ldconfig file triggers per se but how focus few decision making people that here we are dealing with some Fedora maintenance problems. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
