Dne 10.7.2018 v 14:03 Tomasz Kłoczko napsal(a):
> On Tue, 10 Jul 2018 at 12:26, Tomasz Kłoczko <kloczko.tomasz@xxxxxxxxx> wrote:
> [..]
>> # dnf -C repoquery --qf "%{name}.%{arch} %{source_name} %{reponame}" |
>> grep -w rawhide | grep x86_64 | awk '{print $2}' | sort | uniq | wc -l
>> Last metadata expiration check: 0:03:06 ago on Tue 10 Jul 2018 12:17:44 BST.
>> 9314
> Just one more comment about this number and why this is quite precise
> number of the packages which even not now depends on gcc soon maybe
> have such dependency.
AFAIK, the list of packages where "BR: gcc{,-g++}" was added had been
compiled based on real rebuild errors and not on some artificial query.
The rest of you email is OT. Changing BR for every package is much
simpler task then adding BR to packages where it belongs.
V.
> Simple someone may bring as the argument that not all x86_64
> containing packages now needs gcc.
> That is (now) 100% true however it is one additional fact: related to
> LTO optimisation.
>
> On use LTO optimisation is necessary to use gcc-{ar,nm,ranlib}
> executable and so far even if some non-C/C++ compilers may be able to
> produce .o LTO aware bytecode to be able link using ld to produce
> final DSO or ELF executables.
> In such cases I don't think that it will be possible to use such
> compilers straight (like ada, go or other) if someone will be trying
> to use LTO optimisation.
> This will probably force to go over produce asm -> as [-> ar/ranlib] -> ld.
> In such pipeline LTO aware wrappers are part of the gcc.
>
> # rpm -qf /usr/bin/gcc-{ar,nm,ranlib}
> gcc-8.1.1-4.fc29.1.x86_64
> gcc-8.1.1-4.fc29.1.x86_64
> gcc-8.1.1-4.fc29.1.x86_64
>
> LTO still is not prod ready and I found that it produces now some
> highly unstable binaries. In case od zabbix code I found that
> zabbix_agentd crashes and zabbix_server on processing triggers using
> pcre library functions (which has not been optimised using LTO)
> produces binaries which behaves not as expected (producing negated
> values).
> If someone is interested is bugzilla ticket about this:
> https://bugzilla.redhat.com/show_bug.cgi?id=1567112
>
> In other words even if now not all binaries may have straight gcc
> dependency as long as LTO will be stable it will change.
> Looks like clang/llvm 7 will be able produce LTO aware bytecode so
> from this point of view probably it can be used as full gcc
> replacement even to use LTO.
> https://llvm.org/docs/LinkTimeOptimization.html
> In other words above adds last few missing lines to the picture with
> title "why putting gcc BRs is/was wrong?"
>
> kloczek
> --
> Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
> _______________________________________________
> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/A6JBPULBPEFIUYBCD3C66QHRFIVYEKOY/
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/VQCAF7DR27Y4ZBZW46XJ6N6ZM3YK5OTE/
