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.
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/
