[devel] I: LTO in %optflags by default

[devel] I: LTO in %optflags by default

[Dmitry V. Levin]

Hi,

Пришло время включить в Сизифе LTO (link-time optimization).
К сожалению, ещё не все пакеты собираются с этой оптимизацией,
некоторые предстоит исправить.

* 4 пакета перестанут пересобираться с диагностикой следующего вида:
/usr/bin/strip: Unable to recognise the format of the input file `./usr/libexec/arm-none-eabi/lib/libm.a(lib_a-wrf_lgamma.o)'

Сборку этих пакетов можно исправить, добавив такие библиотеки в %brp_strip_none.

* 382 пакета перестанут пересобираться с диагностикой следующего вида:
process-lto: ERROR: ./usr/lib64/libtcb.a: contains __gnu_lto_slim only.
Perhaps, you need to %define optflags_lto %optflags_lto -ffat-lto-objects

С такими пакетами можно поступить одним из двух способов:
- перестать паковать статические библиотеки;
- добавить %define optflags_lto %optflags_lto -ffat-lto-objects
  в спек-файл.

* Около 158 пакетов перестанут пересобираться с другой диагностикой,
связанной с включением LTO.  С такими пакетами можно поступить одним из
нескольких способов:
- обновить пакеты, весьма вероятно, что они уже исправлены в новых версиях;
- исправить LTO самостоятельно;
- выключить LTO, переопределив макрос optflags_lto.

Благодарность за проделанную работу принимает Виталий. :)


-- 
ldv

Re: [devel] I: LTO in %optflags by default

[Dmitry V. Levin]

On Tue, Aug 24, 2021 at 09:20:50PM +0300, Dmitry V. Levin wrote:
> * 4 пакета перестанут пересобираться с диагностикой следующего вида:
> /usr/bin/strip: Unable to recognise the format of the input file `./usr/libexec/arm-none-eabi/lib/libm.a(lib_a-wrf_lgamma.o)'

Вот список этих пакетов:

arm-none-eabi-gcc	antohami @everybody
arm-none-eabi-newlib	antohami @everybody
avr-libc	week viy
cross-toolchain-aarch64-linux-gnu	asheplyakov @everybody


-- 
ldv

Re: [devel] I: LTO in %optflags by default

[Dmitry V. Levin]

On Tue, Aug 24, 2021 at 09:20:50PM +0300, Dmitry V. Levin wrote:
> * 382 пакета перестанут пересобираться с диагностикой следующего вида:
> process-lto: ERROR: ./usr/lib64/libtcb.a: contains __gnu_lto_slim only.
> Perhaps, you need to %define optflags_lto %optflags_lto -ffat-lto-objects
> 
> С такими пакетами можно поступить одним из двух способов:
> - перестать паковать статические библиотеки;
> - добавить %define optflags_lto %optflags_lto -ffat-lto-objects
>   в спек-файл.

Вот список этих пакетов:

4th	led @everybody
GraphicsMagick	sbolshakov @everybody
I2util	imz @everybody
PDFlib-Lite	mike @qa
SDL	mike @everybody
SDL2_sound	viy @everybody
SDL_net	lvol @everybody
SDL_sound	lvol @everybody
adns	rider @everybody
aeskulap	rider @everybody
alsa-oss	mike shrek @qa
antlr	viy @java @python
apmd	mike viy @qa
attr	@core
audiofile	mike @everybody
avrdude	week sin viy
barcode	rider @everybody
beecrypt	@core
binutils	@core
bison	@core
bitcoin	taf @everybody
boost	iv sem @qa
bs2b	drool @everybody
bzip2	@core
capnproto	vt @everybody
capstone	arei @everybody
catch2	pv @everybody
cfitsio	zerg
cgns-seq	antohami @everybody
check	mike mithraen shrek grenka @qa
chicken	oddity @everybody
clanlib0.8	darktemplar @everybody
clsync	bircoph mike @everybody
coturn	arseny @everybody
courier-authlib	lakostis @everybody
curl	rider ldv glebfm
dante	george @everybody
dap	george @everybody
devil	rider @everybody
df_shm	@nobody
dhcp	sem
dialog	lav @everybody
directfb	mike @everybody
dmraid	aris @everybody
e2fsprogs	@core
ecl	cas @everybody
editorconfig	aris
espeak	vseleznv @everybody
evms	mike @everybody
exiv2	aris
file	@core vt
flex	@core
freehdl	mithraen @everybody
fstrcmp	sbolshakov @everybody
gamin	grenka @everybody
gdb	glebfm ldv sbolshakov
geomview	oddity @qa
glib2	aris
glog	dd @everybody
glpk	@nobody
glpk36	@nobody
gmp	@core
grace	mike evg @qa @everybody
gsoap	sin @everybody
gtk-engines-wonderland	@nobody
gtk2-theme-nimbus	@nobody
hackrf	antohami @everybody
hdf	oddity @everybody
hfsutils	george @everybody
hiredis	darktemplar @everybody
hivex	shaba rider @cpan
hts_engine	msp @everybody
httrack	@nobody
hwinfo	george @qa @everybody
icecream	led @everybody
iksemel	mithraen @everybody
intercal	@core @everybody
ipmiutil	mike @everybody
ipset	rider @everybody
iverilog	egori lineprinter @everybody
jclassinfo	viy
js	@nobody
judy	mike @everybody
kannel	week @qa
kde5-kstars	zerg
kde5-marble	zerg mcpain
klish	manowar @everybody
lam	dans @everybody @qa
ldns	darktemplar @everybody
lesstif	sin snejok @qa @everybody
libXaw3d	slazav @everybody
libaacs	sbolshakov @everybody
libabseil-cpp	lav @everybody
libadplug	ildar @everybody
libaltselinux	@nobody
libaom	darktemplar @everybody
libarpack-ng	cas @everybody
libast	viy @everybody
libatomic_ops	sbolshakov @everybody
libavc1394	lav @qa
libayemu	@nobody
libbenchmark	lav @everybody
libbtree	@nobody
libcap	@core
libcityhash	george @everybody
libclastfm	@nobody
libconfig	mike @everybody
libcoredumper	grenka @everybody
libcryptopp	lav @qa @everybody
libcuefile	@nobody
libdap	viy @everybody
libdb1	@core
libdb4.7	@core
libdb4.8	darktemplar @everybody
libdb5.3	darktemplar @everybody
libdbi	darktemplar @everybody
libdbi-drivers	darktemplar @everybody
libdha	@nobody
libdivecomputer-subsurface	viy @everybody
libdmtx	george @everybody
libdotconf	msp @qa @everybody
libdrmhelper	legion
libdv	@core @everybody
libdvbcsa	taf @everybody
libecap	viy @everybody
libenet	george @qa
libev4	mithraen @everybody
libexempi	aris
libfacet	@nobody
libfcgi	mithraen
libffcall	sbolshakov @everybody
libffi	glebfm at
libflame	@nobody
libflann	viy @everybody
libfltk13	grenka
libfplll	viy @everybody
libftdi1	sin @everybody
libgarmin	week @everybody
libgavl	ruslandh @everybody
libgdsii	george @everybody
libgeotiff2	viy @everybody
libggi	george @everybody
libgii	george @qa @everybody
libgmtk	crux @everybody
libgringotts	grenka @everybody
libguestfs	shaba rider @cpan obirvalger
libhtp	darktemplar @everybody
libiec61850	cas @everybody
libilbc	mithraen
libinklevel	oddity @everybody
libjpeg-turbo	sbolshakov ldv
liblbxutil	george @everybody
liblcms	@nobody
liblog4cpp	taf @everybody
libmaa	cheusov @everybody
libmcrypt	lav @qa @everybody
libmesode	george @everybody
libmhash	@nobody
libmilter-workers	viy @everybody
libmimalloc	george @everybody
libmm	mike @qa
libmpsse	slazav @everybody
libmrss	evg @everybody
libmtquery	@nobody
libmtsupport	@nobody
libncursesxx	mithraen @everybody
libnftnl	taf @everybody
libnghttp2	crux @everybody
libomniORB	pv @everybody
libopenaptx	aris
libopencv	darktemplar @everybody
libopenh264	aris lav
liboping	mike @qa @everybody
libparsifal	@nobody
libpki	cow @everybody
libpopt	@core rider
libproj	slazav @everybody
librarian	lav @gnome @qa @everybody
libraw	aris
librubberband	@nobody
librx	@nobody
libscalapack	darktemplar @everybody
libsdp	darktemplar @everybody
libselinux	rider nbr darktemplar
libsemanage	rider sem darktemplar
libsepol	rider sem darktemplar
libsidplayfp	drool @everybody
libsieve	enp @qa
libsilk	rider @everybody
libsixel	mithraen @everybody
libsodium	vt mithraen @everybody
libspf2	darktemplar @everybody
libsrs_alt	sbolshakov @everybody
libstrophe	george @everybody
libsz2	@nobody
libt1ha	at @everybody
libtomcrypt	george @everybody
libtommath	george @everybody
libtool_2.4	@core
libtpcmisc	viy @everybody
libudfread	rider @everybody
liburing	mike @everybody
libusb	shrek shaba mike
libutempter	ldv @norebuild
libvsqlite++	viy @everybody
libxprintutil	george @qa
libxsettings-client0	viy @everybody
libxview	viy @everybody
libyajl1	shaba @everybody
link-grammar	aris
linuxcnc	antohami @everybody
liri-eglfs	sbolshakov @everybody
litecoin	drool @everybody
littlewizard	george @qa
live555	sbolshakov @everybody
lizardfs	andy @everybody
lldpd	ender @everybody
llvm11.0	shrek arseny
llvm12.0	arseny @everybody
lm_sensors3	ender rider @everybody
log4c	grenka @everybody
ltxml	grenka @everybody
lua5.1	vseleznv viy @qa
lua5.3	vseleznv viy
lvm2	shaba vitty rider
lxde-lxappearance-obconf	@lxde @qa
lzlib	mike @everybody
lzo	@core
mailutils	asy @python @everybody
manatee-open	kirill @everybody
mariadb	shaba @everybody
mate-notification-daemon	shrek
mbelib	antohami @everybody
mcpp	sin @qa @everybody
mct	grenka @everybody
menu-cache	@lxde gns antohami @qa
minidjvu	vkni @everybody
miredo	naf @qa
mjpegtools	rider @everybody
mnogosearch	naf @qa
modsecurity	naf @qa
mono	darktemplar @everybody
mpeg2dec	@nobody
mrprojext	pv @qa
mstflint	shaba @everybody
mswatch	darktemplar @everybody
mt-daapd	@nobody
munt	ildar @everybody
musitorius	msp @everybody
mxml	dshein @everybody
nDPI	taf @everybody
nas	grenka @everybody
ncurses	george ldv
net-snmp35	shaba @everybody
netxms	enp @everybody
newt52	@python @qa
nftables	taf @everybody
nilfs-utils	led mike @qa
nspr	legion
nvidia-settings	zerg
ocaml-camlbz2	rider @everybody
ocaml-curl	rider @everybody
ocaml-curses	snejok @everybody
ocaml-lablgl	rider @everybody
ocaml-labltk	rider @everybody
ocaml-libvirt	snejok @everybody
ocaml-mysql	shaba @everybody
ocaml-zarith	rider @everybody
ocfs2-tools	rider @everybody
ocrad	oddity @everybody
openblas	slazav @everybody
opendpi	@nobody
openssl1.1	glebfm
opie	boresexpress gns @everybody
orc	aris manowar @everybody
otf	grenka @everybody
owncloud-client	zerg
pam_userpass	ldv @norebuild
parted	shrek @everybody
pcc	oddity @qa @everybody
pcre	@core at
pcre2	aris
pinball	viy @everybody
ploop	andy shaba @everybody
pnetcdf	darktemplar @everybody
poke	naf @everybody
polyml	zerg @everybody
postgresql10	taf @pgsql @cpan @everybody
postgresql11	taf @pgsql @cpan
postgresql12	taf @pgsql @cpan @everybody
postgresql12-1C	taf @pgsql @everybody
postgresql13	taf @pgsql @everybody
postgresql9.6	taf @pgsql @cpan @everybody
ppl	viy @everybody
progsreiserfs	mike @qa @everybody
python	vseleznv imz george cow glebfm
python-module-numpy	@python lav @qa
python3-module-numpy	darktemplar @everybody
python3-module-pythonmagick	@python @everybody
qgis3	cas @everybody
qt3	rom_as @everybody
qt5-declarative	zerg
qt5-tools	zerg
qtbrowserplugin	cas @everybody
quesoglc	rider
qxmledit	led @everybody
random	@nobody
readline	@core
readline5	glebfm ldv @qa
reiser4progs	darktemplar @everybody
rhash	sin @everybody
rocksdb	shaba @everybody
rss_glx	mike boyarsh @qa @everybody
ruby	@ruby @everybody
sablotron	lav @everybody
scorep	darktemplar @everybody
sexpr	@nobody
sibcoin	drool @everybody
sispmctl	mike @qa
slang2	asy @everybody
smpeg	darktemplar @everybody
sowing	grenka
sox	mithraen @everybody
spai	grenka @everybody
speech-dispatcher	msp manowar @everybody
speex	mithraen viy rider
sphinx	rider @everybody
sphinxbase	mithraen @everybody
sprng	underwit @everybody
ssdeep	george @everybody
stk	@nobody
supertuxkart	oddity @everybody
surgescript	arbars @everybody
sylpheed	oddity @everybody
sysfsutils	shaba @everybody
syslog-ng	asy @everybody
sysprof	aris
systemd	shaba
tcb	ldv @norebuild
tcc	george @everybody
tcl	vseleznv
tcl-img	vseleznv
tcl-memchan	vseleznv @everybody
tcl-tdom	vseleznv
tcl-trf	vseleznv
tcl-xml	vseleznv @everybody
tcl-zlib	vseleznv @everybody
tidyp	crux @everybody
tk	vseleznv
tokyocabinet	crux @everybody
tokyodystopia	@nobody
tokyotyrant	@nobody
torsocks	cow @everybody
toxcore	mithraen @everybody
trousers	sbolshakov @everybody
uchardet	drool @everybody
udis86	@nobody
unadf	george @qa @everybody
unit	vt andy @everybody
usbip	pv led @everybody
ustr	@nobody
uw-imap	mithraen rider
vkd3d	lakostis @everybody
vlc	rider darktemplar
vmfs-tools	@nobody
vo-aacenc	@nobody
voiceman	msp @everybody
vulkan	lakostis
wmhdplop	mike @qa @everybody
wvstreams	cas @everybody
wxsvg	rider @everybody
xblas	lav @everybody
xdrfile	@nobody
xinetd	@core
xosd	evg @everybody
xpa	egori @everybody
xz	@core vseleznv vt
yajl	shaba @everybody
yasm	sbolshakov @everybody
zbar	rider @everybody
zlib	@core
zlib-ng	nenderus @everybody


-- 
ldv

Re: [devel] I: LTO in %optflags by default

[Dmitry V. Levin]

On Tue, Aug 24, 2021 at 09:20:50PM +0300, Dmitry V. Levin wrote:
> * Около 158 пакетов перестанут пересобираться с другой диагностикой,
> связанной с включением LTO.  С такими пакетами можно поступить одним из
> нескольких способов:
> - обновить пакеты, весьма вероятно, что они уже исправлены в новых версиях;
> - исправить LTO самостоятельно;
> - выключить LTO, переопределив макрос optflags_lto.

Вот список этих пакетов:

BlocksRuntime	darktemplar @everybody
ElectricFence	lav @qa
NetworkManager	sem
TiMidity++	mike stanv @qa @everybody
aircrack-ng	darktemplar @everybody
arm-none-eabi-gcc	antohami @everybody
arm-none-eabi-newlib	antohami @everybody
assaultcube	darktemplar @everybody
avr-libc	week viy
bcc	vt @everybody
bear	mattaku arseny cow @everybody
blogc	glebfm @qa
canorus	majioa @everybody
ceph	shaba @qa
cmocka	shaba @everybody
collectd	rider mike asy @cpan shaba @qa
cross-toolchain-aarch64-linux-gnu	asheplyakov @everybody
crtools	vseleznv @everybody
crtools-ovz	andy @everybody
cups-backend-bjnp	mcpain @everybody
deepin-music	lvol @everybody
deepin-terminal	lvol @everybody
dhcdrop	@nobody
dosemu	@nobody
dotnet-corefx-2.1	lav @everybody
dotnet-corefx-3.1	lav @everybody
dovecot	george glebfm @everybody
dpdk	snejok @everybody
dragonfly-reverb	iv @everybody
elfutils	ldv vt @norebuild
elinks	george glebfm at
farstream0.2	aris @everybody
ffmpeg	rider darktemplar
firebird	darktemplar @everybody
fprintd	rider @everybody
freeswitch	rider @cpan
fscrypt	bircoph @everybody
gcc10	glebfm ldv
gcc4.3	glebfm @everybody
gcc4.4	glebfm @everybody
gcc4.5	sbolshakov glebfm @everybody
gcc4.6	sbolshakov glebfm @everybody
gcc4.7	sbolshakov glebfm @everybody
gcc4.8	glebfm @everybody
gcc4.9	glebfm
gcc5	glebfm
gcc6	glebfm
gcc7	glebfm
gcc8	glebfm ldv
gcc9	glebfm ldv
ghc8.6.4	sin @everybody
glibc	@core
gnome-builder	aris
gnome-control-center	aris
gnustep-objc2	cas @everybody
gpm	@core
gprolog	ldv @everybody
grub	rider @norebuild nickel
guitarix	antohami @everybody
gzdoom	arbars @everybody
handbrake	drool @everybody
hyperscan	lav @everybody
igt-gpu-tools	george @everybody
indilib	zerg
java-1.8.0-openjdk	cas viy @everybody
java-10-openjdk	viy @jvm @everybody
java-11-openjdk	viy @jvm @everybody
jikes	@nobody
keepassxc	zorg paulelms @everybody
ladspa_sdk	aris @qa
libalsa	mike shrek @qa
libbpf	vt shaba @everybody
libbsd	lav @everybody
libcdaudio	@nobody
libcerf	viy @everybody
libcomedi	lav rom_as pv @qa
libcxxtools	sbolshakov @everybody
libgdchart	grenka @everybody
libglade	@nobody
libgtksourceview4	aris
libmodelfile	viy @everybody
libmozjs78	aris
libmtxclient	manowar @everybody
liboil	@core aris @qa
libomp	viy @qa
libpsl-native	lav @everybody
libsigsegv	@core
libtorrent	darktemplar @everybody
libvidcap	viy @everybody
libwacom	aris
libwebkitgtk4	aris
libx264	sbolshakov @everybody
libxmp	drool @everybody
linphone	taf @everybody
lksctp-tools	mithraen @everybody
ltp	vt @everybody
ltrace	grenka
lzdoom	arbars @everybody
mdadm	shaba vitty @everybody
mpir	antohami @everybody
mplayer	vseleznv led ender rider
newsboat	vseleznv @everybody
openmodelica	cas @everybody
papi	lav @everybody
php7	rider
php7-imap	rider @everybody
php8.0	rider @everybody
php8.0-imap	rider @everybody
php8.0-opcache	rider @everybody
pmplib	@nobody
printer-driver-ptouch	mcpain @everybody
python-module-pyorbit	lav @python @gnome
python3-module-PySide2	cas @everybody
python3-module-cpopen	@python @everybody
python3-module-faketime	@python @everybody
qboot	shaba @everybody
qcad	cas @everybody
qt4	zerg
qt5-base	zerg
qt5-script	zerg
qt5-webkit	zerg
quota	@core
ricochet	lav @everybody
root6	arei @everybody
rootsh	naf
rpcs3	nenderus @everybody
rpm-build-vm	vt @everybody
sandbox	arei @everybody
scim-anthy	oddity @everybody
scim-hangul	oddity @everybody
scim-m17n	oddity @everybody
sdcc	darktemplar @everybody
seahorse	aris
squid	glebfm shaba
sssd	sin shaba asheplyakov slev iv
syslinux	zerg mike ptrnine
tcptrace	@nobody
tdlib	lav @everybody
texlive	viy @everybody
thunderbird	cas legion
totem	aris
trace-cmd	vt @everybody
ucblogo	george @everybody
uftrace	lav @everybody
valgrind	@core vsu
vidix	@nobody
vifm	sin @everybody
virtualbox	sin nbr greh
vogl	bip @everybody
weston	aris legion
wine	lav @qa
wine-vanilla	lav @qa
wsjtx	antohami @everybody
wxGTK	mike @everybody
x264	rider ender @everybody
xen	shadrinov @everybody
xorg-drv-intel	shrek
xorg-server	shrek
ytalk	rider @everybody


-- 
ldv

Re: [devel] I: LTO in %optflags by default

[Dmitry V. Levin]

On Tue, Aug 24, 2021 at 09:20:50PM +0300, Dmitry V. Levin wrote:
[...]
> * 382 пакета перестанут пересобираться с диагностикой следующего вида:
> process-lto: ERROR: ./usr/lib64/libtcb.a: contains __gnu_lto_slim only.
> Perhaps, you need to %define optflags_lto %optflags_lto -ffat-lto-objects
> 
> С такими пакетами можно поступить одним из двух способов:
> - перестать паковать статические библиотеки;
> - добавить %define optflags_lto %optflags_lto -ffat-lto-objects
>   в спек-файл.

Пожалуй, лучше будет %global optflags_lto %optflags_lto -ffat-lto-objects


-- 
ldv

Re: [devel] I: LTO in %optflags by default

[Dmitry V. Levin]

On Tue, Aug 24, 2021 at 09:22:16PM +0300, Dmitry V. Levin wrote:
> On Tue, Aug 24, 2021 at 09:20:50PM +0300, Dmitry V. Levin wrote:
> > * 382 пакета перестанут пересобираться с диагностикой следующего вида:
> > process-lto: ERROR: ./usr/lib64/libtcb.a: contains __gnu_lto_slim only.
> > Perhaps, you need to %define optflags_lto %optflags_lto -ffat-lto-objects
> > 
> > С такими пакетами можно поступить одним из двух способов:
> > - перестать паковать статические библиотеки;
> > - добавить %define optflags_lto %optflags_lto -ffat-lto-objects
> >   в спек-файл.
> 
> Вот список этих пакетов:

Из них есть 18 исходных пакетов, из которых собираются -devel-static,
присутствующие в сборочной среде других пакетов:

boost	iv sem @qa
glib2	aris
gsoap	sin @everybody
libatomic_ops	sbolshakov @everybody
libffi	glebfm at
libsepol	rider sem darktemplar
llvm12.0	arseny @everybody
lvm2	shaba vitty rider
ncurses	george ldv
newt52	@python @qa
openssl1.1	glebfm
postgresql13	taf @pgsql @everybody
qt5-declarative	zerg
qt5-tools	zerg
rocksdb	shaba @everybody
slang2	asy @everybody
uchardet	drool @everybody
wvstreams	cas @everybody


-- 
ldv

Re: [devel] I: LTO in %optflags by default

[Dmitry V. Levin]

On Tue, Aug 24, 2021 at 10:19:06PM +0300, Dmitry V. Levin wrote:
> On Tue, Aug 24, 2021 at 09:20:50PM +0300, Dmitry V. Levin wrote:
> [...]
> > * 382 пакета перестанут пересобираться с диагностикой следующего вида:
> > process-lto: ERROR: ./usr/lib64/libtcb.a: contains __gnu_lto_slim only.
> > Perhaps, you need to %define optflags_lto %optflags_lto -ffat-lto-objects
> > 
> > С такими пакетами можно поступить одним из двух способов:
> > - перестать паковать статические библиотеки;
> > - добавить %define optflags_lto %optflags_lto -ffat-lto-objects
> >   в спек-файл.
> 
> Пожалуй, лучше будет %global optflags_lto %optflags_lto -ffat-lto-objects

Вероятно, более переносимой будет следующая конструкция:

%{?optflags_lto:%global optflags_lto %optflags_lto -ffat-lto-objects}


-- 
ldv

Re: [devel] I: LTO in %optflags by default

[Ivan A. Melnikov]

On Tue, Aug 24, 2021 at 09:20:50PM +0300, Dmitry V. Levin wrote:
> Hi,
> 
> Пришло время включить в Сизифе LTO (link-time optimization).
> К сожалению, ещё не все пакеты собираются с этой оптимизацией,
> некоторые предстоит исправить.

Скажите, а как это влияет на время сборки пакетов?

Это тестировалось только на основных архитектурах? На всех?

-- 
  wbr,
    iv m.

Re: [devel] I: LTO in %optflags by default

[Denis Medvedev]

В Wed, 25 Aug 2021 09:27:50 +0400
"Ivan A. Melnikov" <iv@altlinux.org> пишет:

> On Tue, Aug 24, 2021 at 09:20:50PM +0300, Dmitry V. Levin wrote:
> > Hi,
> > 
> > Пришло время включить в Сизифе LTO (link-time optimization).
> > К сожалению, ещё не все пакеты собираются с этой оптимизацией,
> > некоторые предстоит исправить.  
> 
> Скажите, а как это влияет на время сборки пакетов?
> 
> Это тестировалось только на основных архитектурах? На всех?
> 

Я, конечно, понимаю, что запоздал с этим,
но можно ли включить
по умолчаниию заодно вот это:


-mmitigate-rop
Attempt to compile code without unintended return addresses, making ROP just a little harder.

-mindirect-branch=thunk -mfunction-return=thunk
Enables retpoline (return trampolines) to mitigate some variants of Spectre V2. The second flag is necessary on Skylake+ due to the fact that the branch target buffer is vulnerable.

-fstack-protector-all -Wstack-protector --param ssp-buffer-size=4
choice of "-fstack-protector" does not protect all functions . You need -fstack-protector-all to guarantee guards are applied to all functions, although this will likely incur a performance penalty. Consider -fstack-protector-strong as a middle ground.
The -Wstack-protector flag here gives warnings for any functions that aren't going to get protected.

-fstack-clash-protection
Defeats a class of attacks called stack clashing.

-pie -fPIE
Required to obtain the full security benefits of ASLR.

-ftrapv
Generates traps for signed overflow (currently bugged in gcc, and may interfere with UBSAN).

-­D_FORTIFY_SOURCE=2
Buffer overflow checks. See also difference between =2 and =1.

­-Wl,-z,relro,-z,now
RELRO (read-only relocation). The options relro & now specified
together are known as "Full RELRO". You can specify "Partial RELRO" by
omitting the now flag. RELRO marks various ELF memory sections
read­only (E.g. the GOT).

Re: [devel] I: LTO in %optflags by default

[Denis Medvedev]

В Wed, 25 Aug 2021 08:46:40 +0300
Denis Medvedev <nbr@altlinux.org> пишет:

> В Wed, 25 Aug 2021 09:27:50 +0400
> "Ivan A. Melnikov" <iv@altlinux.org> пишет:
> 
> > On Tue, Aug 24, 2021 at 09:20:50PM +0300, Dmitry V. Levin wrote:
> > > Hi,
> > > 
> > > Пришло время включить в Сизифе LTO (link-time optimization).
> > > К сожалению, ещё не все пакеты собираются с этой оптимизацией,
> > > некоторые предстоит исправить.  
> > 
> > Скажите, а как это влияет на время сборки пакетов?
> > 
> > Это тестировалось только на основных архитектурах? На всех?
> > 
> 
> Я, конечно, понимаю, что запоздал с этим,
> но можно ли включить
> по умолчаниию заодно вот это:
> 
> 
> -mmitigate-rop
> Attempt to compile code without unintended return addresses, making
> ROP just a little harder.
> 
> -mindirect-branch=thunk -mfunction-return=thunk
> Enables retpoline (return trampolines) to mitigate some variants of
> Spectre V2. The second flag is necessary on Skylake+ due to the fact
> that the branch target buffer is vulnerable.
> 
> -fstack-protector-all -Wstack-protector --param ssp-buffer-size=4
> choice of "-fstack-protector" does not protect all functions . You
> need -fstack-protector-all to guarantee guards are applied to all
> functions, although this will likely incur a performance penalty.
> Consider -fstack-protector-strong as a middle ground. The
> -Wstack-protector flag here gives warnings for any functions that
> aren't going to get protected.
> 
> -fstack-clash-protection
> Defeats a class of attacks called stack clashing.
> 
> -pie -fPIE
> Required to obtain the full security benefits of ASLR.
> 
> -ftrapv
> Generates traps for signed overflow (currently bugged in gcc, and may
> interfere with UBSAN).
Интересно, оно до сих пор bugged?
> 
> -­D_FORTIFY_SOURCE=2
> Buffer overflow checks. See also difference between =2 and =1.
> 
> ­-Wl,-z,relro,-z,now
> RELRO (read-only relocation). The options relro & now specified
> together are known as "Full RELRO". You can specify "Partial RELRO" by
> omitting the now flag. RELRO marks various ELF memory sections
> read­only (E.g. the GOT).
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] I: LTO in %optflags by default

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 2890 bytes --]

On Wed, 25 Aug 2021 08:46:40 +0300 Denis Medvedev wrote:
> В Wed, 25 Aug 2021 09:27:50 +0400
> "Ivan A. Melnikov" <iv@altlinux.org> пишет:
> 
> > On Tue, Aug 24, 2021 at 09:20:50PM +0300, Dmitry V. Levin wrote:
> > > Hi,
> > > 
> > > Пришло время включить в Сизифе LTO (link-time optimization).
> > > К сожалению, ещё не все пакеты собираются с этой оптимизацией,
> > > некоторые предстоит исправить.  
> > 
> > Скажите, а как это влияет на время сборки пакетов?
> > 
> > Это тестировалось только на основных архитектурах? На всех?
> > 
> 
> Я, конечно, понимаю, что запоздал с этим,
> но можно ли включить
> по умолчаниию заодно вот это:
> 
> 
> -mmitigate-rop
> Attempt to compile code without unintended return addresses, making ROP just a little harder.
> 
> -mindirect-branch=thunk -mfunction-return=thunk
> Enables retpoline (return trampolines) to mitigate some variants of Spectre V2. The second flag is necessary on Skylake+ due to the fact that the branch target buffer is vulnerable.

Но эти опции, ведь, не на всех архитектурах нужны, даже в основной
сборочнице. Поэтому если и включать, то выборочно в зависимости от
архитектуры.
 
> -fstack-protector-all -Wstack-protector --param ssp-buffer-size=4
> choice of "-fstack-protector" does not protect all functions . You need -fstack-protector-all to guarantee guards are applied to all functions, although this will likely incur a performance penalty. Consider -fstack-protector-strong as a middle ground.
> The -Wstack-protector flag here gives warnings for any functions that aren't going to get protected.
> 
> -fstack-clash-protection
> Defeats a class of attacks called stack clashing.

Эта может поломать много приложений и может быть значимый удар по
производительности.
 
> ­-Wl,-z,relro,-z,now
> RELRO (read-only relocation). The options relro & now specified
> together are known as "Full RELRO". You can specify "Partial RELRO" by
> omitting the now flag. RELRO marks various ELF memory sections
> read­only (E.g. the GOT).

С точки зрения безопасности это хорошо, а вот тормоза даёт дикие,
особенно на тяжёлых приложениях типа LO. Возможно, в этом есть смысл
в специальных ветках, но в Сизиф такое не нужно тянуть.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] I: LTO in %optflags by default

[Denis Medvedev]

В Wed, 25 Aug 2021 09:53:29 +0300
Andrey Savchenko <bircoph@altlinux.org> пишет:

> On Wed, 25 Aug 2021 08:46:40 +0300 Denis Medvedev wrote:
> > В Wed, 25 Aug 2021 09:27:50 +0400
> > "Ivan A. Melnikov" <iv@altlinux.org> пишет:
> >   
> > > On Tue, Aug 24, 2021 at 09:20:50PM +0300, Dmitry V. Levin wrote:  
> > > > Hi,
> > > > 
> > > > Пришло время включить в Сизифе LTO (link-time optimization).
> > > > К сожалению, ещё не все пакеты собираются с этой оптимизацией,
> > > > некоторые предстоит исправить.    
> > > 
> > > Скажите, а как это влияет на время сборки пакетов?
> > > 
> > > Это тестировалось только на основных архитектурах? На всех?
> > >   
> > 
> > Я, конечно, понимаю, что запоздал с этим,
> > но можно ли включить
> > по умолчаниию заодно вот это:
> > 
> > 
> > -mmitigate-rop
> > Attempt to compile code without unintended return addresses, making
> > ROP just a little harder.
> > 
> > -mindirect-branch=thunk -mfunction-return=thunk
> > Enables retpoline (return trampolines) to mitigate some variants of
> > Spectre V2. The second flag is necessary on Skylake+ due to the
> > fact that the branch target buffer is vulnerable.  
> 
> Но эти опции, ведь, не на всех архитектурах нужны, даже в основной
> сборочнице. Поэтому если и включать, то выборочно в зависимости от
> архитектуры.
>  
> > -fstack-protector-all -Wstack-protector --param ssp-buffer-size=4
> > choice of "-fstack-protector" does not protect all functions . You
> > need -fstack-protector-all to guarantee guards are applied to all
> > functions, although this will likely incur a performance penalty.
> > Consider -fstack-protector-strong as a middle ground. The
> > -Wstack-protector flag here gives warnings for any functions that
> > aren't going to get protected.
> > 
> > -fstack-clash-protection
> > Defeats a class of attacks called stack clashing.  
> 
> Эта может поломать много приложений и может быть значимый удар по
> производительности.
>  
> > ­-Wl,-z,relro,-z,now
> > RELRO (read-only relocation). The options relro & now specified
> > together are known as "Full RELRO". You can specify "Partial RELRO"
> > by omitting the now flag. RELRO marks various ELF memory sections
> > read­only (E.g. the GOT).  
> 
> С точки зрения безопасности это хорошо, а вот тормоза даёт дикие,
> особенно на тяжёлых приложениях типа LO. Возможно, в этом есть смысл
> в специальных ветках, но в Сизиф такое не нужно тянуть.
В таком случае как мне правильно сделать дефолты для особых веток?
Сделать свою версию какого пакета?
> 
> Best regards,
> Andrew Savchenko

Re: [devel] I: LTO in %optflags by default

[Ivan A. Melnikov]

On Wed, Aug 25, 2021 at 09:53:29AM +0300, Andrey Savchenko wrote:
> On Wed, 25 Aug 2021 08:46:40 +0300 Denis Medvedev wrote:
>  
> > -fstack-protector-all -Wstack-protector --param ssp-buffer-size=4
> > choice of "-fstack-protector" does not protect all functions . You need -fstack-protector-all to guarantee guards are applied to all functions, although this will likely incur a performance penalty. Consider -fstack-protector-strong as a middle ground.
> > The -Wstack-protector flag here gives warnings for any functions that aren't going to get protected.
> > 
> > -fstack-clash-protection
> > Defeats a class of attacks called stack clashing.
> 
> Эта может поломать много приложений и может быть значимый удар по
> производительности.

А разве -fstack-clash-protection уже не включен в нашем gcc10
по умолчанию?

-- 
  wbr,
    iv m.

Re: [devel] I: LTO in %optflags by default

[Alexey Sheplyakov]

Добрый день!

On 25.08.2021 09:46, Denis Medvedev wrote:

> -mmitigate-rop
> Attempt to compile code without unintended return addresses, making ROP just a little harder.
> 
> -mindirect-branch=thunk -mfunction-return=thunk
> Enables retpoline (return trampolines) to mitigate some variants of Spectre V2. The second flag is necessary on Skylake+ due to the fact that the branch target buffer is vulnerable.

Для некоторых архитектур, для отдельных приложений (ssh, gpg), возможно, и имеет смысл.
А "счастья всем, даром, и пусть никто не уйдёт обиженным" - спасибо, не надо.

> -pie -fPIE
> Required to obtain the full security benefits of ASLR.

Уже включили. Его бы **отключить**. Особенно на 32-битных архитектурах.

> -ftrapv
> Generates traps for signed overflow (currently bugged in gcc, and may interfere with UBSAN). 

На ровном месте урезать возможности оптимизации? Нет, спасибо.
Вы ещё предложите с -O0 собирать.
Самое главное - это не сделает код с UB более безопасным.

Re: [devel] I: LTO in %optflags by default

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 3644 bytes --]

On Wed, 25 Aug 2021 10:03:39 +0300 Denis Medvedev wrote:
> В Wed, 25 Aug 2021 09:53:29 +0300
> Andrey Savchenko <bircoph@altlinux.org> пишет:
> 
> > On Wed, 25 Aug 2021 08:46:40 +0300 Denis Medvedev wrote:
> > > В Wed, 25 Aug 2021 09:27:50 +0400
> > > "Ivan A. Melnikov" <iv@altlinux.org> пишет:
> > >   
> > > > On Tue, Aug 24, 2021 at 09:20:50PM +0300, Dmitry V. Levin wrote:  
> > > > > Hi,
> > > > > 
> > > > > Пришло время включить в Сизифе LTO (link-time optimization).
> > > > > К сожалению, ещё не все пакеты собираются с этой оптимизацией,
> > > > > некоторые предстоит исправить.    
> > > > 
> > > > Скажите, а как это влияет на время сборки пакетов?
> > > > 
> > > > Это тестировалось только на основных архитектурах? На всех?
> > > >   
> > > 
> > > Я, конечно, понимаю, что запоздал с этим,
> > > но можно ли включить
> > > по умолчаниию заодно вот это:
> > > 
> > > 
> > > -mmitigate-rop
> > > Attempt to compile code without unintended return addresses, making
> > > ROP just a little harder.
> > > 
> > > -mindirect-branch=thunk -mfunction-return=thunk
> > > Enables retpoline (return trampolines) to mitigate some variants of
> > > Spectre V2. The second flag is necessary on Skylake+ due to the
> > > fact that the branch target buffer is vulnerable.  
> > 
> > Но эти опции, ведь, не на всех архитектурах нужны, даже в основной
> > сборочнице. Поэтому если и включать, то выборочно в зависимости от
> > архитектуры.
> >  
> > > -fstack-protector-all -Wstack-protector --param ssp-buffer-size=4
> > > choice of "-fstack-protector" does not protect all functions . You
> > > need -fstack-protector-all to guarantee guards are applied to all
> > > functions, although this will likely incur a performance penalty.
> > > Consider -fstack-protector-strong as a middle ground. The
> > > -Wstack-protector flag here gives warnings for any functions that
> > > aren't going to get protected.
> > > 
> > > -fstack-clash-protection
> > > Defeats a class of attacks called stack clashing.  
> > 
> > Эта может поломать много приложений и может быть значимый удар по
> > производительности.
> >  
> > > ­-Wl,-z,relro,-z,now
> > > RELRO (read-only relocation). The options relro & now specified
> > > together are known as "Full RELRO". You can specify "Partial RELRO"
> > > by omitting the now flag. RELRO marks various ELF memory sections
> > > read­only (E.g. the GOT).  
> > 
> > С точки зрения безопасности это хорошо, а вот тормоза даёт дикие,
> > особенно на тяжёлых приложениях типа LO. Возможно, в этом есть смысл
> > в специальных ветках, но в Сизиф такое не нужно тянуть.
> В таком случае как мне правильно сделать дефолты для особых веток?
> Сделать свою версию какого пакета?

rpmbuild, нужно править макрос(ы) %optflags_* в platform.in; думаю,
%optflags_default должно хватить.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] I: LTO in %optflags by default

[Alexey Sheplyakov]

Здравствуйте!

On 24.08.2021 22:20, Dmitry V. Levin wrote:

> Пришло время включить в Сизифе LTO (link-time optimization).

Поскольку LTO ломает сборку сотен пакетов, причем не каких попало,
а gcc, glibc, и т.п. - то время включать LTO как раз таки НЕ пришло.

А если кому-то всё равно очень хочется - надо сначала доработать пакеты
(на которые повлияет LTO), а потом уж включать. И нет, это не сопровождающие
пакетов должны заниматься этой глупостью, а именно этот "кто-то", кому
понадобилась LTO (или ещё какая модная фенечка).

А "я тут всё сломал, а вы теперь - чините" - это прямое вредительство.

> * 382 пакета перестанут пересобираться с диагностикой следующего вида:

> * Около 158 пакетов перестанут пересобираться с другой диагностикой,


gcc10	glebfm ldv
gcc4.3	glebfm @everybody
gcc4.4	glebfm @everybody
gcc4.5	sbolshakov glebfm @everybody
gcc4.6	sbolshakov glebfm @everybody
gcc4.7	sbolshakov glebfm @everybody
gcc4.8	glebfm @everybody
gcc4.9	glebfm
gcc5	glebfm
gcc6	glebfm
gcc7	glebfm
gcc8	glebfm ldv
gcc9	glebfm ldv
ghc8.6.4	sin @everybody
glibc	@core

Ничего так списочек, внушает.

Re: [devel] I: LTO in %optflags by default

[Alexey Tourbin]

On Wed, Aug 25, 2021 at 9:54 AM Andrey Savchenko <bircoph@altlinux.org> wrote:
> > ­-Wl,-z,relro,-z,now
> > RELRO (read-only relocation). The options relro & now specified
> > together are known as "Full RELRO". You can specify "Partial RELRO" by
> > omitting the now flag. RELRO marks various ELF memory sections
> > read­only (E.g. the GOT).
>
> С точки зрения безопасности это хорошо, а вот тормоза даёт дикие,
> особенно на тяжёлых приложениях типа LO. Возможно, в этом есть смысл
> в специальных ветках, но в Сизиф такое не нужно тянуть.

Насколько дикие тормоза примерно?
По-моему оно включено давно.

$ cat hello.c
#include <stdio.h>
int main(){printf("divanus expertus vulgaris\n");}
$ gcc -O2 hello.c && md5sum a.out
ba46117902b0a993a384d3702247e81a  a.out
$ gcc -O2 hello.c -Wl,-z,relro,-z,now && md5sum a.out
ba46117902b0a993a384d3702247e81a  a.out

Re: [devel] I: LTO in %optflags by default

[Vitaly Lipatov]

Dmitry V. Levin писал 25.8.21 3:04:
> On Tue, Aug 24, 2021 at 09:22:16PM +0300, Dmitry V. Levin wrote:
>> On Tue, Aug 24, 2021 at 09:20:50PM +0300, Dmitry V. Levin wrote:
>> > * 382 пакета перестанут пересобираться с диагностикой следующего вида:
>> > process-lto: ERROR: ./usr/lib64/libtcb.a: contains __gnu_lto_slim only.
>> > Perhaps, you need to %define optflags_lto %optflags_lto -ffat-lto-objects
>> >
>> > С такими пакетами можно поступить одним из двух способов:
>> > - перестать паковать статические библиотеки;
>> > - добавить %define optflags_lto %optflags_lto -ffat-lto-objects
>> >   в спек-файл.
>> 
>> Вот список этих пакетов:
> 
> Из них есть 18 исходных пакетов, из которых собираются -devel-static,
> присутствующие в сборочной среде других пакетов:
> 
> boost	iv sem @qa
> glib2	aris
> gsoap	sin @everybody
> libatomic_ops	sbolshakov @everybody
> libffi	glebfm at
> libsepol	rider sem darktemplar
> llvm12.0	arseny @everybody
> lvm2	shaba vitty rider
> ncurses	george ldv
> newt52	@python @qa
> openssl1.1	glebfm
> postgresql13	taf @pgsql @everybody
> qt5-declarative	zerg
> qt5-tools	zerg
> rocksdb	shaba @everybody
> slang2	asy @everybody
> uchardet	drool @everybody
> wvstreams	cas @everybody

У меня есть впечатление, что не всем этим другим пакетам прям необходимы 
-devel-static.
По крайней мере в одном своём пакете я обнаружил прошло шутку от 
buildreq, притягивающую лишний devel-static.

Вот небольшой обзор использующих -devel-static, порождённые из пакетов 
по списку выше:
(единственное, я не смог найти следов static в пакете lvm2)


boost    iv sem @qa
     boost-devel-static - Boost libraries
           karbowanecwallet 	drool @everybody
           sibcoin 	drool @everybody
           taler 	drool @everybody

glib2    aris
     glib2-devel-static - Static version of GLib libraries
           qemu 	shaba glebfm

gsoap    sin @everybody
     libgsoap-devel-static - Static devel libraries and headers for 
linking with gSOAP generated stubs
           v4l2onvif 	sbolshakov @everybody
           virtualbox 	sin nbr greh

libatomic_ops    sbolshakov @everybody
     libatomic_ops-devel-static - A library for accessing hardware 
provided atomic memory operations
           ggaoed 	sbolshakov @everybody
           libgc 	lav @qa @everybody
           rakudo 	crux @everybody

libffi    glebfm at
     libffi-devel-static - Static library for Foreign Function Interface 
development
           libmozjs78 	aris

libsepol    rider sem darktemplar
     libsepol-devel-static - Static development files for libsepol
           checkpolicy 	rider sem darktemplar
           libselinux 	rider nbr darktemplar
           policycoreutils 	rider zerg darktemplar
           setools 	darktemplar sem led rider @qa

llvm12.0    arseny @everybody
     llvm12.0-devel-static - Static libraries for LLVM
           bcc 	vt @everybody
           bpftrace 	vt @everybody
           castxml 	darktemplar @everybody
           cvise 	lav @everybody
           dolphin-emu 	nenderus @everybody
           ispc 	vt @everybody
           libcxx 	lav @everybody
           libcxxabi 	lav @everybody
           qt-creator 	cas @everybody
           rust 	legion crux @everybody

Can't find for lvm2

ncurses    george ldv
     libncursesxx-devel-static - Static libraries for libncursesxx
ncurses    george ldv
     libncurses++-devel-static - Development static libncurses++ library
ncurses    george ldv
     libncurses-devel-static - Development static ncurses libraries
ncurses    george ldv
     libtinfo-devel-static - A low-level terminfo static library
           lvm2 	shaba vitty rider
           sash 	@core


newt52    @python @qa
     libnewt-devel-static - Newt windowing toolkit development files.
           propagator 	rider boyarsh mike sem

openssl1.1    glebfm
     libssl-devel-static - OpenSSL static libraries
           libwebsockets 	lav @everybody
           xmr-stak 	drool @everybody
           xmrig 	drool @everybody

postgresql13    taf @pgsql @everybody
     postgresql-devel-static - Development static library for 
postgresql-devel
           pg_catcheck 	kondratyuk @everybody
           pg_rman 	darktemplar @everybody
           qt4 	zerg
           qt5-base 	zerg
           repmgr 	shaba @everybody

qt5-declarative    zerg
     qt5-declarative-devel-static - Development files for qt5-declarative
           pythonqt 	darktemplar @everybody
           qt5-tools 	zerg
           qt5-virtualkeyboard 	zerg

qt5-tools    zerg
     qt5-tools-devel-static - Development files for qt5-tools
           CTK 	darktemplar @everybody
           OpenBoard 	antohami @everybody
           freecad 	cas @everybody
           kde5-calendarsupport 	zerg
           kde5-eventviews 	zerg
           kde5-kmail-account-wizard 	zerg
           kde5-korganizer 	zerg
           kde5-libkdepim 	zerg
           kde5-libksieve 	zerg
           kde5-mailcommon 	zerg
           kde5-mailimporter 	zerg
           kde5-messagelib 	zerg
           kde5-pim-apps-libs 	zerg
           kde5-pimcommon 	zerg
           kexi 	zerg
           kf5-kjsembed 	zerg
           kf5-kross 	zerg
           kf5-kwidgetsaddons 	zerg
           klatexformula 	george @everybody
           lightdm-kde-greeter 	darktemplar @everybody
           lmms 	antohami @everybody
           musescore 	lav @qa @everybody
           plasma5-kwin 	zerg
           plasma5-nm 	zerg @everybody
           python3-module-PySide2 	cas @everybody
           pythonqt 	darktemplar @everybody
           qcad 	cas @everybody
           qgis3 	cas @everybody
           qmapshack 	glebfm @qa
           slicer 	darktemplar @everybody
           texstudio 	oddity @everybody
           texworks 	grenka
           trojita 	grenka @everybody
           zint 	underwit @everybody

rocksdb    shaba @everybody
     librocksdb-devel-static - Static library for rocksdb
           clickhouse 	rider darktemplar

slang2    asy @everybody
     libslang2-devel-static - The static library for development using 
S-Lang
           propagator 	rider boyarsh mike sem

uchardet    drool @everybody
     libuchardet-devel-static - Static library for uchardet
           deepin-editor 	lvol @everybody

wvstreams    cas @everybody
     libwvstreams-devel-static - C++ libraries for rapid application 
development
           wvdial 	cas @everybody



-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] I: LTO in %optflags by default

[Ivan A. Melnikov]

On Wed, Aug 25, 2021 at 11:18:16AM +0300, Vitaly Lipatov wrote:
> Dmitry V. Levin писал 25.8.21 3:04:
> > On Tue, Aug 24, 2021 at 09:22:16PM +0300, Dmitry V. Levin wrote:
> > > On Tue, Aug 24, 2021 at 09:20:50PM +0300, Dmitry V. Levin wrote:
> > > > * 382 пакета перестанут пересобираться с диагностикой следующего вида:
> > > > process-lto: ERROR: ./usr/lib64/libtcb.a: contains __gnu_lto_slim only.
> > > > Perhaps, you need to %define optflags_lto %optflags_lto -ffat-lto-objects
> > > >
> > > > С такими пакетами можно поступить одним из двух способов:
> > > > - перестать паковать статические библиотеки;
> > > > - добавить %define optflags_lto %optflags_lto -ffat-lto-objects
> > > >   в спек-файл.
> > > 
> > > Вот список этих пакетов:
> > 
> > Из них есть 18 исходных пакетов, из которых собираются -devel-static,
> > присутствующие в сборочной среде других пакетов:
> > 
> > boost	iv sem @qa
> > glib2	aris
> > gsoap	sin @everybody
> > libatomic_ops	sbolshakov @everybody
> > libffi	glebfm at
> > libsepol	rider sem darktemplar
> > llvm12.0	arseny @everybody
> > lvm2	shaba vitty rider
> > ncurses	george ldv
> > newt52	@python @qa
> > openssl1.1	glebfm
> > postgresql13	taf @pgsql @everybody
> > qt5-declarative	zerg
> > qt5-tools	zerg
> > rocksdb	shaba @everybody
> > slang2	asy @everybody
> > uchardet	drool @everybody
> > wvstreams	cas @everybody
> 
> У меня есть впечатление, что не всем этим другим пакетам прям необходимы
> -devel-static.
> По крайней мере в одном своём пакете я обнаружил прошло шутку от buildreq,
> притягивающую лишний devel-static.
> 
> Вот небольшой обзор использующих -devel-static, порождённые из пакетов по
> списку выше:
> (единственное, я не смог найти следов static в пакете lvm2)
> 
> 
> boost    iv sem @qa
>     boost-devel-static - Boost libraries
>           karbowanecwallet 	drool @everybody
>           sibcoin 	drool @everybody
>           taler 	drool @everybody

Я помню просьбы людей, использовавших boost из репозитория в своих
проектах, оставить devel-static. Было это правда давно: одним из
этих людей был real@. Но всё равно, думаю тут лучше починить.

Насколько boost-devel-static нужен именно при сборке пакетов в Сизиф
-- это другой вопрос. Я думаю, что скорее не нужен.

-- 
  wbr,
    iv m.

Re: [devel] I: LTO in %optflags by default

[Vitaly Lipatov]

Ivan A. Melnikov писал 25.8.21 11:28:
> On Wed, Aug 25, 2021 at 11:18:16AM +0300, Vitaly Lipatov wrote:
...
>> boost    iv sem @qa
>>     boost-devel-static - Boost libraries
>>           karbowanecwallet 	drool @everybody
>>           sibcoin 	drool @everybody
>>           taler 	drool @everybody
> 
> Я помню просьбы людей, использовавших boost из репозитория в своих
> проектах, оставить devel-static. Было это правда давно: одним из
> этих людей был real@. Но всё равно, думаю тут лучше починить.
Да, это может быть кому-то полезно для сборки каких-то standalone, 
недистрибутивных решений.

> Насколько boost-devel-static нужен именно при сборке пакетов в Сизиф
> -- это другой вопрос. Я думаю, что скорее не нужен.
Да. Я просто воспользовался случаем обратить внимание, что по 
возможности надо бы избавиться от статической линковки.

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] I: LTO in %optflags by default

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1501 bytes --]

On Wed, 25 Aug 2021 11:14:31 +0300 Alexey Tourbin wrote:
> On Wed, Aug 25, 2021 at 9:54 AM Andrey Savchenko <bircoph@altlinux.org> wrote:
> > > ­-Wl,-z,relro,-z,now
> > > RELRO (read-only relocation). The options relro & now specified
> > > together are known as "Full RELRO". You can specify "Partial RELRO" by
> > > omitting the now flag. RELRO marks various ELF memory sections
> > > read­only (E.g. the GOT).
> >
> > С точки зрения безопасности это хорошо, а вот тормоза даёт дикие,
> > особенно на тяжёлых приложениях типа LO. Возможно, в этом есть смысл
> > в специальных ветках, но в Сизиф такое не нужно тянуть.
> 
> Насколько дикие тормоза примерно?

Разница во времени запуска LO между ~120 и ~40 секундами на старом
атоме, где сравнивлась система, собранная целиком с relro, now
и без.

> По-моему оно включено давно.
> 
> $ cat hello.c
> #include <stdio.h>
> int main(){printf("divanus expertus vulgaris\n");}
> $ gcc -O2 hello.c && md5sum a.out
> ba46117902b0a993a384d3702247e81a  a.out
> $ gcc -O2 hello.c -Wl,-z,relro,-z,now && md5sum a.out
> ba46117902b0a993a384d3702247e81a  a.out

Очень плохо, если так.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] I: LTO in %optflags by default

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 2025 bytes --]

On Wed, 25 Aug 2021 11:38:58 +0300 Vitaly Lipatov wrote:
> Ivan A. Melnikov писал 25.8.21 11:28:
> > On Wed, Aug 25, 2021 at 11:18:16AM +0300, Vitaly Lipatov wrote:
> ...
> >> boost    iv sem @qa
> >>     boost-devel-static - Boost libraries
> >>           karbowanecwallet 	drool @everybody
> >>           sibcoin 	drool @everybody
> >>           taler 	drool @everybody
> > 
> > Я помню просьбы людей, использовавших boost из репозитория в своих
> > проектах, оставить devel-static. Было это правда давно: одним из
> > этих людей был real@. Но всё равно, думаю тут лучше починить.
> Да, это может быть кому-то полезно для сборки каких-то standalone, 
> недистрибутивных решений.
> 
> > Насколько boost-devel-static нужен именно при сборке пакетов в Сизиф
> > -- это другой вопрос. Я думаю, что скорее не нужен.
> Да. Я просто воспользовался случаем обратить внимание, что по 
> возможности надо бы избавиться от статической линковки.

А почему не наоборот?

Динамическая линковка лишь создаёт иллюзию безопасности за счёт
исправления проблемы в одной библиотеке сразу для всех. Но проблема
может быть в хедерах, а C++ библиотеки всё больше переходят
в хедеры. В итоге может получится, что CVE исправлен, библиотека
обновлена без изменения ABI, а непересобранные приложения всё ещё
уязвимы.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] I: LTO in %optflags by default

[Vitaly Lipatov]

Dmitry V. Levin писал 24.8.21 21:20:
> Hi,
> 
> Пришло время включить в Сизифе LTO (link-time optimization).
> К сожалению, ещё не все пакеты собираются с этой оптимизацией,
> некоторые предстоит исправить.
...
> Благодарность за проделанную работу принимает Виталий. :)
Почему-то нет анонса об изменениях в rpm-build. Виталий Чикунов ни разу 
не писал в devel@, как я смог посмотреть, поэтому странно ссылаться на 
него. Ведь мог пострадать и я от неразобравшихся, кто виноват :)

Ну и странно, что изменения Виталия анонсируете вы, а ваше добавление 
--runstatedir не анонсировал Виталий, который отправил пакет в Сизиф.

rpm-build changelog:
* Tue Aug 24 2021 Vitaly Chikunov <vt at altlinux.org> 4.0.4-alt175
- platform.in: Parallelize LTO with -flto=auto.
- process-lto: Fix suggestion text.

* Tue Aug 24 2021 Dmitry V. Levin <ldv at altlinux.org> 4.0.4-alt174
- Added support for --runstatedir configure option.

* Mon Aug 23 2021 Vitaly Chikunov <vt at altlinux.org> 4.0.4-alt173
- platform.in: Enable LTO by default.
- brp: Add brp-strip-lto & process-lto scripts.

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] I: LTO in %optflags by default

[Dmitry V. Levin]

On Wed, Aug 25, 2021 at 01:45:23PM +0300, Vitaly Lipatov wrote:
> Dmitry V. Levin писал 24.8.21 21:20:
> > Hi,
> > 
> > Пришло время включить в Сизифе LTO (link-time optimization).
> > К сожалению, ещё не все пакеты собираются с этой оптимизацией,
> > некоторые предстоит исправить.
> ...
> > Благодарность за проделанную работу принимает Виталий. :)
> Почему-то нет анонса об изменениях в rpm-build. Виталий Чикунов ни разу 
> не писал в devel@, как я смог посмотреть, поэтому странно ссылаться на 
> него. Ведь мог пострадать и я от неразобравшихся, кто виноват :)

У нас разделение труда: благодарность принимает Виталий, а всё остальное - я.
Не вижу ничего плохого в том, чтобы благодарность приняло более одного
Виталия. :)

> Ну и странно, что изменения Виталия анонсируете вы,

Поскольку решение принимал я, мы договорились, что и анонсирую тоже я.

> а ваше добавление 
> --runstatedir не анонсировал Виталий, который отправил пакет в Сизиф.

Добавление --runstatedir отправлял в Сизиф я, а не Виталий:
https://lists.altlinux.org/pipermail/sisyphus-incominger/2021-August/630930.html
https://lists.altlinux.org/pipermail/sisyphus-incominger/2021-August/630950.html

Мне почему-то показалось, что оно ничего не сломает, иначе бы я его не
стал отправлять.  Потом я увидел, что это не так, и у --runstatedir нет
никаких шансов в обозримом будущем, поэтому я это изменение откатываю.


-- 
ldv

Re: [devel] I: LTO in %optflags by default

[Dmitry V. Levin]

On Wed, Aug 25, 2021 at 08:46:40AM +0300, Denis Medvedev wrote:
[...]
> Я, конечно, понимаю, что запоздал с этим,
> но можно ли включить
> по умолчаниию заодно вот это:

У меня две просьбы:
1. Не начинать новый тред кнопкой "Ответить".
2. Изучить предметную область перед тем, как задавать вопрос,
хотя бы просто прочитать нашу документацию:

# apt-get install gcc-doc
$ info gcc
поискать там ALT.*gcc
$ rpmquery --changelog gcc10 |less


-- 
ldv

Re: [devel] devel-static

[Dmitry V. Levin]

On Wed, Aug 25, 2021 at 12:18:40PM +0300, Andrey Savchenko wrote:
> On Wed, 25 Aug 2021 11:38:58 +0300 Vitaly Lipatov wrote:
> > Ivan A. Melnikov писал 25.8.21 11:28:
> > > On Wed, Aug 25, 2021 at 11:18:16AM +0300, Vitaly Lipatov wrote:
> > ...
> > >> boost    iv sem @qa
> > >>     boost-devel-static - Boost libraries
> > >>           karbowanecwallet 	drool @everybody
> > >>           sibcoin 	drool @everybody
> > >>           taler 	drool @everybody
> > > 
> > > Я помню просьбы людей, использовавших boost из репозитория в своих
> > > проектах, оставить devel-static. Было это правда давно: одним из
> > > этих людей был real@. Но всё равно, думаю тут лучше починить.
> > Да, это может быть кому-то полезно для сборки каких-то standalone, 
> > недистрибутивных решений.
> > 
> > > Насколько boost-devel-static нужен именно при сборке пакетов в Сизиф
> > > -- это другой вопрос. Я думаю, что скорее не нужен.
> > Да. Я просто воспользовался случаем обратить внимание, что по 
> > возможности надо бы избавиться от статической линковки.
> 
> А почему не наоборот?
> 
> Динамическая линковка лишь создаёт иллюзию безопасности за счёт
> исправления проблемы в одной библиотеке сразу для всех. Но проблема
> может быть в хедерах, а C++ библиотеки всё больше переходят
> в хедеры. В итоге может получится, что CVE исправлен, библиотека
> обновлена без изменения ABI, а непересобранные приложения всё ещё
> уязвимы.

А безопаснее всего публиковать только исходники, и пусть пользователи
сами пересобирают, как сочтут нужным, правда же?


-- 
ldv

Re: [devel] devel-static

[Alexey Sheplyakov]

On 25.08.2021 21:14, Dmitry V. Levin wrote:
>> А почему не наоборот?
>>
>> Динамическая линковка лишь создаёт иллюзию безопасности за счёт
>> исправления проблемы в одной библиотеке сразу для всех. Но проблема
>> может быть в хедерах, а C++ библиотеки всё больше переходят
>> в хедеры. В итоге может получится, что CVE исправлен, библиотека
>> обновлена без изменения ABI, а непересобранные приложения всё ещё
>> уязвимы.
> 
> А безопаснее всего публиковать только исходники, и пусть пользователи
> сами пересобирают, как сочтут нужным, правда же?
> 

Вы, Дмитрий, можете сколько угодно оскорблять людей, но C++ шаблоны
всё равно останутся устроены так, как они устроены.

Re: [devel] I: LTO in %optflags by default

[Dmitry V. Levin]

On Wed, Aug 25, 2021 at 09:27:50AM +0400, Ivan A. Melnikov wrote:
> On Tue, Aug 24, 2021 at 09:20:50PM +0300, Dmitry V. Levin wrote:
> > Hi,
> > 
> > Пришло время включить в Сизифе LTO (link-time optimization).
> > К сожалению, ещё не все пакеты собираются с этой оптимизацией,
> > некоторые предстоит исправить.
> 
> Скажите, а как это влияет на время сборки пакетов?

По идее, всякая новая оптимизация занимает какое-то время, и LTO точно не
исключение, линковка должна происходить дольше.  С численной оценкой не
всё просто.  Тестовая пересборка всего репозитория до включения LTO и
после включения (без других изменений, в т.ч. без изменений про
--runstatedir) суммарно заняла одинаковое время, возможно, за счёт того,
что какие-то пакеты не собрались.  При этом одни пакеты из тех, что
собрались, сделали это быстрее, а другие - медленнее.  Можно посмотреть,
сколько занимала тестовая пересборка тех или иных пакетов, например, так:

$ join -t$'\t' /beehive/logs/Sisyphus/x86_64/{previous,latest}/time.list \
| sed -E 's/-[^-[:space:]]+-[^-[:space:]]+([[:space:]])/\1/' \
| sort \
| join -t$'\t' -v1 - /beehive/stats/Sisyphus-x86_64/ftbfs-since \
| sort -n -k2


-- 
ldv

Re: [devel] Administrivia

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1242 bytes --]

Здравствуйте,

On Wed, Aug 25, 2021 at 11:37:46AM +0400, Alexey Sheplyakov wrote:
> Здравствуйте!
> 
> On 24.08.2021 22:20, Dmitry V. Levin wrote:
> 
> > Пришло время включить в Сизифе LTO (link-time optimization).
> 
> Поскольку LTO ломает сборку сотен пакетов, причем не каких попало,
> а gcc, glibc, и т.п. - то время включать LTO как раз таки НЕ пришло.
> 
> А если кому-то всё равно очень хочется - надо сначала доработать пакеты
> (на которые повлияет LTO), а потом уж включать. И нет, это не сопровождающие
> пакетов должны заниматься этой глупостью, а именно этот "кто-то", кому
> понадобилась LTO (или ещё какая модная фенечка).

Эту тему можно было бы обсудить по-существу, если бы вы не написали то,
что вы написали дальше.

> А "я тут всё сломал, а вы теперь - чините" - это прямое вредительство.

А дальше вы написали то, что квалифицируется как распространение заведомо
ложных сведений, порочащих честь и достоинство другого лица или
подрывающих его репутацию, а это уже УК РФ Статья 128.1. Клевета.

Клевета у нас запрещена, поэтому вам больше не разрешается писать сюда
писем до тех пор, пока вы так же публично не принесёте извинений,
которые будут приняты тем, кого вы оклеветали.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] devel-static

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 7832 bytes --]

On Wed, 25 Aug 2021 20:14:41 +0300 Dmitry V. Levin wrote:
> On Wed, Aug 25, 2021 at 12:18:40PM +0300, Andrey Savchenko wrote:
> > On Wed, 25 Aug 2021 11:38:58 +0300 Vitaly Lipatov wrote:
> > > Ivan A. Melnikov писал 25.8.21 11:28:
[...]
> > > > Насколько boost-devel-static нужен именно при сборке пакетов в Сизиф
> > > > -- это другой вопрос. Я думаю, что скорее не нужен.
> > > Да. Я просто воспользовался случаем обратить внимание, что по 
> > > возможности надо бы избавиться от статической линковки.
> > 
> > А почему не наоборот?
> > 
> > Динамическая линковка лишь создаёт иллюзию безопасности за счёт
> > исправления проблемы в одной библиотеке сразу для всех. Но проблема
> > может быть в хедерах, а C++ библиотеки всё больше переходят
> > в хедеры. В итоге может получится, что CVE исправлен, библиотека
> > обновлена без изменения ABI, а непересобранные приложения всё ещё
> > уязвимы.
> 
> А безопаснее всего публиковать только исходники, и пусть пользователи
> сами пересобирают, как сочтут нужным, правда же?

На этот вопрос нельзя однозначно ответить, поскольку в таком
случае задача обеспечения безопасности во многом перекладывается на
пользователей и ответ зависит от их квалификации. Так вернёмся к
обсуждению DSO vs static в бинарном дистрибутиве общего назначения.

1) Безопасность.

Выше я привёл пример, когда DSO лишь маскирует проблему
безопасности, но не решает её. В случае со static очевидно, что
пересобирать нужно всех потребителей (при необходимости рекурсивно).
Так что относительно просто реализовать механизм контроля
гарантированного исправления ошибок и уязвимостей среди
прямых и косвенных пользователей библиотеки.

В случае с DSO может возникнуть крайне опасная ситуация скрытого
наличия уязвимости, когда CVE в библиотеке исправлен, по
setversions с клиентами всё хорошо, мы успешно заявили об
исправлении данной CVE в дистрибутиве, а в реальности уязвимость
кое-где осталась.

Самым простым решением данной проблемы будет безусловная пересборка
всех зависимостей, так же, как и со static — но в таком случае
никаких преимуществ у DSO не остаётся.

Можно попробовать отслеживать, были ли изменения хедеров
и пересобирать безусловно только в таком случае — но это более
сложный и в то же время всё ещё грубый путь решения задачи, т.к. не
всякое изменение в хедере ведёт к изменению бинарного кода
в клиенте.

Самым «изящным» решением будет аналог setversions для хедеров —
чтоб пересобирать только те зависимости, на которые влияют
выполненные изменения хедеров. Однако, мне такая задача
представляется не решаемой на практике без полной препроцессорной
обработки всех зависимостей, что по трудоёмкости сопоставимо с их
пересборкой.

2) Экономия памяти или места на диске.

Безусловно, для повсеместно используемых библиотек эффект будет
значимым — ну та же glibc. Однако, есть очень много библиотек для
одного-двух клиент и здесь выигрыша уже нет, а может быть
и проигрыш, т.к. DSO в общем случае приводит к менее эффективному
и более раздутому коду.

Это не только моё мнение, вот что пишет по этому поводу Линус
Торвальдс:
https://lore.kernel.org/lkml/CAHk-=whs8QZf3YnifdLv57+FhBi5_WeNTG1B-suOES=RcUSmQg@mail.gmail.com/

3) Производительность.

DSO в целом всегда хуже static. Иногда эта разница пренебрежима, во
многом это зависит от архитектуры (например, i686 здесь много хуже
amd64).

В любом случае, для более-менее хорошей производительности DSO
нужно сильно переписывать код по сравнению со static версией.
Совершенно невероятное по своей сложности руководство от Ульриха
Дреппера это подтверждает:
https://akkadia.org/drepper/dsohowto.pdf

Т.е. DSO можно сделать эффективной, но это неимоверное количество
работы, которую _обычно_ апстримы не делают в полной мере, или не
делают вовсе.

4) Технические сложности.

DSO характерны вечные проблемы версионирования, безопасности (relro
и now затем ведь делаются, м?), конфликтов по soname, технических
проблем (привер -fcommon) и т.п.. У static большинства этого нет.

Самое интересное, что даже Ульрих Дреппер призывает пореже
создавать DSO (и использовать PIE):
https://udrepper.livejournal.com/8790.html

В общем, тренд во многих дистрибутивах к выбросу static везде, где
только можно, мне представляется ошибочным. Разумеется, DSO тоже
нужны: как для широко используемых библиотек, так и для плагинов
и редких случаев, где без DSO работать не будет.

Так что я рекомендовал бы отказаться от подхода «а давайте выкинем
ещё и этот devel-static» и постепенно переходить к использованию
именно static версий в тех многих случаях, где они оправданы.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] devel-static

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1531 bytes --]

On Wed, 25 Aug 2021 21:25:40 +0400 Alexey Sheplyakov wrote:
> On 25.08.2021 21:14, Dmitry V. Levin wrote:
> >> А почему не наоборот?
> >>
> >> Динамическая линковка лишь создаёт иллюзию безопасности за счёт
> >> исправления проблемы в одной библиотеке сразу для всех. Но проблема
> >> может быть в хедерах, а C++ библиотеки всё больше переходят
> >> в хедеры. В итоге может получится, что CVE исправлен, библиотека
> >> обновлена без изменения ABI, а непересобранные приложения всё ещё
> >> уязвимы.
> > 
> > А безопаснее всего публиковать только исходники, и пусть пользователи
> > сами пересобирают, как сочтут нужным, правда же?
> > 
> 
> Вы, Дмитрий, можете сколько угодно оскорблять людей, но C++ шаблоны
> всё равно останутся устроены так, как они устроены.

Шаблоны C++ — это, конечно, основной источник проблемы, но не
единственный. То же самое может быть и в обычных макросах, даже
на C.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] Administrivia

[Alexey Sheplyakov]

On 25.08.2021 22:07, Dmitry V. Levin wrote:

> Эту тему можно было бы обсудить по-существу, если бы вы не написали то,
> что вы написали дальше.
> 
>> А "я тут всё сломал, а вы теперь - чините" - это прямое вредительство.

Простите, погорячился. Это я зря. Постараюсь в дальнейшем аккуратнее подбирать формулировки.

Re: [devel] I: LTO in %optflags by default

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 2639 bytes --]

On Wed, 25 Aug 2021 11:37:46 +0400 Alexey Sheplyakov wrote:
> Здравствуйте!
> 
> On 24.08.2021 22:20, Dmitry V. Levin wrote:
> 
> > Пришло время включить в Сизифе LTO (link-time optimization).
> 
> Поскольку LTO ломает сборку сотен пакетов, причем не каких попало,
> а gcc, glibc, и т.п. - то время включать LTO как раз таки НЕ пришло.
> 
> А если кому-то всё равно очень хочется - надо сначала доработать пакеты
> (на которые повлияет LTO), а потом уж включать. И нет, это не сопровождающие
> пакетов должны заниматься этой глупостью, а именно этот "кто-то", кому
> понадобилась LTO (или ещё какая модная фенечка).

Это давняя проблема. У нас есть правило: «кто сломал, тот
и чинит» (я не нашёл такую политику, возможно, это джентельменское
соглашение). Однако, на практике оно работает лишь для простых
смертных, а с ключевыми компонентами системы — тем же тулчейном —
всё наоборот: чинят мейнтенеры пакетов, которых обычно никто не
справшивает и просто ставят перед фактом.

С одной стороны, такой подход можно понять, т.к. когда сломанных
пакетов слишком много, авторы изменений просто физически не могут
без помощи остальных всё исправить. С другой стороны он
несправедлив по отношению к мейнтенерам других сложных подсистем
(питон, джава, telive, cmake).

Давайте искать в этом вопросе золотую середину, чтоб всё было по
справедливости. Возможно, следует сделать лимит на количество
затронутых пакетов, после которого следует подключать сообщество
к исправлению проблем. Другие предложения приветствуются.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] devel-static

[Vitaly Lipatov]

Andrey Savchenko писал 25.8.21 22:14:
> On Wed, 25 Aug 2021 20:14:41 +0300 Dmitry V. Levin wrote:
>> On Wed, Aug 25, 2021 at 12:18:40PM +0300, Andrey Savchenko wrote:
...
>> > Динамическая линковка лишь создаёт иллюзию безопасности за счёт
>> > исправления проблемы в одной библиотеке сразу для всех. Но проблема
>> > может быть в хедерах, а C++ библиотеки всё больше переходят
>> > в хедеры. В итоге может получится, что CVE исправлен, библиотека
>> > обновлена без изменения ABI, а непересобранные приложения всё ещё
>> > уязвимы.
>> 
>> А безопаснее всего публиковать только исходники, и пусть пользователи
>> сами пересобирают, как сочтут нужным, правда же?
> 
> На этот вопрос нельзя однозначно ответить, поскольку в таком
> случае задача обеспечения безопасности во многом перекладывается на
> пользователей и ответ зависит от их квалификации. Так вернёмся к
> обсуждению DSO vs static в бинарном дистрибутиве общего назначения.
> 
> 1) Безопасность.
> 
> Выше я привёл пример, когда DSO лишь маскирует проблему
> безопасности, но не решает её. В случае со static очевидно, что
> пересобирать нужно всех потребителей (при необходимости рекурсивно).
> Так что относительно просто реализовать механизм контроля
> гарантированного исправления ошибок и уязвимостей среди
> прямых и косвенных пользователей библиотеки.
> 
> В случае с DSO может возникнуть крайне опасная ситуация скрытого
> наличия уязвимости, когда CVE в библиотеке исправлен, по
> setversions с клиентами всё хорошо, мы успешно заявили об
> исправлении данной CVE в дистрибутиве, а в реальности уязвимость
> кое-где осталась.
> 
> Самым простым решением данной проблемы будет безусловная пересборка
> всех зависимостей, так же, как и со static — но в таком случае
> никаких преимуществ у DSO не остаётся.
> 
> Можно попробовать отслеживать, были ли изменения хедеров
> и пересобирать безусловно только в таком случае — но это более
> сложный и в то же время всё ещё грубый путь решения задачи, т.к. не
> всякое изменение в хедере ведёт к изменению бинарного кода
> в клиенте.
Я бы хотел добавить только, что
в реальной жизни эта проблема решается проще — при исправлении CVE 
проект выпускает новую версию библиотеки, и если вдруг уязвимость 
требует пересборки клиентов (из-за её исправления в заголовочных 
файлах), то об этом сообщат пользователям библиотеки (в описании 
релиза).
Также, как я понимаю, достаточно сложно создать уязвимость именно в том 
коде, который генерируется при сборке приложения, а не библиотеки. Разве 
известны такие случаи?

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] Administrivia

[Alexey V. Vissarionov]

On 2021-08-25 23:25:54 +0400, Alexey Sheplyakov wrote:

 >> Эту тему можно было бы обсудить по-существу, если бы вы не
 >> написали то, что вы написали дальше.
 >>> А "я тут всё сломал, а вы теперь - чините" - это прямое
 >>> вредительство.
 > Простите, погорячился. Это я зря. Постараюсь в дальнейшем
 > аккуратнее подбирать формулировки.

Вот тут квантором \forall размахивать уж точно не следовало,
да и умысла что-либо ломать у ldv заведомо не было.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] I: LTO in %optflags by default

[Vitaly Lipatov]

Dmitry V. Levin писал 25.8.21 19:20:
> On Wed, Aug 25, 2021 at 01:45:23PM +0300, Vitaly Lipatov wrote:
>> Dmitry V. Levin писал 24.8.21 21:20:
>> > Hi,
>> >
>> > Пришло время включить в Сизифе LTO (link-time optimization).
>> > К сожалению, ещё не все пакеты собираются с этой оптимизацией,
>> > некоторые предстоит исправить.
>> ...
>> > Благодарность за проделанную работу принимает Виталий. :)
>> Почему-то нет анонса об изменениях в rpm-build. Виталий Чикунов ни 
>> разу
>> не писал в devel@, как я смог посмотреть, поэтому странно ссылаться на
>> него. Ведь мог пострадать и я от неразобравшихся, кто виноват :)
> 
> У нас разделение труда: благодарность принимает Виталий, а всё 
> остальное - я.
> Не вижу ничего плохого в том, чтобы благодарность приняло более одного
> Виталия. :)
:)

>> Ну и странно, что изменения Виталия анонсируете вы,
...
> Добавление --runstatedir отправлял в Сизиф я, а не Виталий:
> https://lists.altlinux.org/pipermail/sisyphus-incominger/2021-August/630930.html
> https://lists.altlinux.org/pipermail/sisyphus-incominger/2021-August/630950.html
Ух ты, извините, это было моё неверное предположение из-за отправки в 
один день.

> Мне почему-то показалось, что оно ничего не сломает, иначе бы я его не
> стал отправлять.  Потом я увидел, что это не так, и у --runstatedir нет
> никаких шансов в обозримом будущем, поэтому я это изменение откатываю.
Я был только же уверен, что оно ничего не сломает, но оказалось, что 
configure делает warning только для неизвестных параметров 
--with-something, а для прочих параметров даёт ошибку.
А я правильно понимаю, что если перегенерировать configure с помощью 
нового autoconf, то поддержка --runstatedir появится?

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] I: LTO in %optflags by default

[Dmitry V. Levin]

On Wed, Aug 25, 2021 at 11:23:38PM +0300, Vitaly Lipatov wrote:
> Dmitry V. Levin писал 25.8.21 19:20:
[...]
> > Мне почему-то показалось, что оно ничего не сломает, иначе бы я его не
> > стал отправлять.  Потом я увидел, что это не так, и у --runstatedir нет
> > никаких шансов в обозримом будущем, поэтому я это изменение откатываю.
> Я был только же уверен, что оно ничего не сломает, но оказалось, что 
> configure делает warning только для неизвестных параметров 
> --with-something, а для прочих параметров даёт ошибку.
> А я правильно понимаю, что если перегенерировать configure с помощью 
> нового autoconf, то поддержка --runstatedir появится?

Нет, потому что я откатил этот бэкпорт:
https://lists.altlinux.org/pipermail/sisyphus-incominger/2021-August/631035.html

Но в новом autoconf 2.7x эта фича есть, так что и у нас появится.


-- 
ldv

Re: [devel] devel-static

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 4949 bytes --]

On Wed, 25 Aug 2021 22:58:03 +0300 Vitaly Lipatov wrote:
> Andrey Savchenko писал 25.8.21 22:14:
> > On Wed, 25 Aug 2021 20:14:41 +0300 Dmitry V. Levin wrote:
> >> On Wed, Aug 25, 2021 at 12:18:40PM +0300, Andrey Savchenko wrote:
> ...
> >> > Динамическая линковка лишь создаёт иллюзию безопасности за счёт
> >> > исправления проблемы в одной библиотеке сразу для всех. Но проблема
> >> > может быть в хедерах, а C++ библиотеки всё больше переходят
> >> > в хедеры. В итоге может получится, что CVE исправлен, библиотека
> >> > обновлена без изменения ABI, а непересобранные приложения всё ещё
> >> > уязвимы.
> >> 
> >> А безопаснее всего публиковать только исходники, и пусть пользователи
> >> сами пересобирают, как сочтут нужным, правда же?
> > 
> > На этот вопрос нельзя однозначно ответить, поскольку в таком
> > случае задача обеспечения безопасности во многом перекладывается на
> > пользователей и ответ зависит от их квалификации. Так вернёмся к
> > обсуждению DSO vs static в бинарном дистрибутиве общего назначения.
> > 
> > 1) Безопасность.
> > 
> > Выше я привёл пример, когда DSO лишь маскирует проблему
> > безопасности, но не решает её. В случае со static очевидно, что
> > пересобирать нужно всех потребителей (при необходимости рекурсивно).
> > Так что относительно просто реализовать механизм контроля
> > гарантированного исправления ошибок и уязвимостей среди
> > прямых и косвенных пользователей библиотеки.
> > 
> > В случае с DSO может возникнуть крайне опасная ситуация скрытого
> > наличия уязвимости, когда CVE в библиотеке исправлен, по
> > setversions с клиентами всё хорошо, мы успешно заявили об
> > исправлении данной CVE в дистрибутиве, а в реальности уязвимость
> > кое-где осталась.
> > 
> > Самым простым решением данной проблемы будет безусловная пересборка
> > всех зависимостей, так же, как и со static — но в таком случае
> > никаких преимуществ у DSO не остаётся.
> > 
> > Можно попробовать отслеживать, были ли изменения хедеров
> > и пересобирать безусловно только в таком случае — но это более
> > сложный и в то же время всё ещё грубый путь решения задачи, т.к. не
> > всякое изменение в хедере ведёт к изменению бинарного кода
> > в клиенте.
> Я бы хотел добавить только, что
> в реальной жизни эта проблема решается проще — при исправлении CVE 
> проект выпускает новую версию библиотеки, и если вдруг уязвимость 
> требует пересборки клиентов (из-за её исправления в заголовочных 
> файлах), то об этом сообщат пользователям библиотеки (в описании 
> релиза).

Некоторые апстримы ушли по-умолчанию целиком в хедеры и отдельно не
выделяют такие ситуации, например, cgal.

> Также, как я понимаю, достаточно сложно создать уязвимость именно в том 
> коде, который генерируется при сборке приложения, а не библиотеки. Разве 
> известны такие случаи?

Я отдельно не искал. Но почему ошибка в реализации шаблона
представляется невероятной?

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] devel-static

[Vitaly Lipatov]

Andrey Savchenko писал 25.8.21 23:52:
> On Wed, 25 Aug 2021 22:58:03 +0300 Vitaly Lipatov wrote:
...
> Некоторые апстримы ушли по-умолчанию целиком в хедеры и отдельно не
> выделяют такие ситуации, например, cgal.
Безусловно, нужно отмечать такие пакеты, и при их изменении пересобирать 
всё, что от них зависит. Иначе смысла в их изменении нет :)
Сейчас это могут делать и делают мантейнеры вручную (через rebuild 
зависящих по сборке пакетов), но вполне возможно, что когда-нибудь в 
сборочницу будет добавлена такая проверка и проверка будет выполняться 
автоматически.

>> Также, как я понимаю, достаточно сложно создать уязвимость именно в 
>> том
>> коде, который генерируется при сборке приложения, а не библиотеки. 
>> Разве
>> известны такие случаи?
> 
> Я отдельно не искал. Но почему ошибка в реализации шаблона
> представляется невероятной?
Представляется очень маловероятной. Потенциальная проблема может 
возникнуть у нескольких пакетов среди десятков тысяч в репозитории, 
поэтому особо никого не волнует — в смысле никто не готов ради этого 
переходить на статику, например.

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] I: LTO in %optflags by default

[Dmitry V. Levin]

On Tue, Aug 24, 2021 at 09:20:50PM +0300, Dmitry V. Levin wrote:
> Hi,
> 
> Пришло время включить в Сизифе LTO (link-time optimization).

Поскольку мы в теме, нам это казалось очевидным и не требующим
дополнительных пояснений, но, поскольку это ещё не всем очевидно,
поясню, из каких соображений мы исходили:

- LTO - это безусловно полезная оптимизация, об этом много написано,
  см. напр. [1] [2], поэтому ею хорошо было бы воспользоваться;

- LTO - это уже широко распространённая оптимизация, её уже включили в
  openSUSE, Fedora, Ubuntu, Clearlinux, скоро Debian, там уже вытоптали
  основные грабли, большинство фиксов пакетов заапстримлено, поэтому ею
  уже можно пользоваться;

- LTO - это уже настолько распространённая оптимизация, что скоро без LTO
  уже мало кто будет собирать, поэтому не пользоваться ею скоро будет себе
  дороже;

- После бранчевания мы в начале нового цикла разработки, самое время
  включить LTO.

- Исправление самой массовой сборочной ошибки "process-lto: ERROR:",
  вызванной включением LTO, тривиально.

- Выключить LTO в пакете в случае необходимости - тривиально.

[1] https://documentation.suse.com/sbp/all/html/SBP-GCC-10/index.html
[2] https://wiki.ubuntu.com/ToolChain/LTO

-- 
ldv

Re: [devel] devel-static

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 2243 bytes --]

On Thu, 26 Aug 2021 00:06:23 +0300 Vitaly Lipatov wrote:
> Andrey Savchenko писал 25.8.21 23:52:
> > On Wed, 25 Aug 2021 22:58:03 +0300 Vitaly Lipatov wrote:
> >> Также, как я понимаю, достаточно сложно создать уязвимость именно в 
> >> том
> >> коде, который генерируется при сборке приложения, а не библиотеки. 
> >> Разве
> >> известны такие случаи?
> > 
> > Я отдельно не искал. Но почему ошибка в реализации шаблона
> > представляется невероятной?
> Представляется очень маловероятной.

А зря. Это точно такой же полноценный код с среднестатистически
такой же частотой ошибок. Вот пример по тому же cgal:
https://www.cvedetails.com/vulnerability-list/vendor_id-24019/Cgal.html

Все 4 CVE по header-only коду. Т.е. просто в яблочко.

> Потенциальная проблема может 
> возникнуть у нескольких пакетов среди десятков тысяч в репозитории, 
> поэтому особо никого не волнует — в смысле никто не готов ради этого 
> переходить на статику, например.

1. Формально закрытые, но в реальности оставшиеся CVE — это слишком
серьёзная проблема, чтоб её игнорировать. Даже если таких пакетов
0.1% (я думаю, что в десятки раз больше).

2. В исходном письме я перечислил достаточно много примемуществ
статики со ссылкой на весьма авторитетные источники.

Повторюсь, я не призываю полностью избавляться от DSO, но статику
можно и нужно использовать.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] I: LTO in %optflags by default

[Aleksey Novodvorsky]

чт, 26 авг. 2021 г. в 00:24, Dmitry V. Levin <ldv@altlinux.org>:
>
> On Tue, Aug 24, 2021 at 09:20:50PM +0300, Dmitry V. Levin wrote:
> > Hi,
> >
> > Пришло время включить в Сизифе LTO (link-time optimization).
>
> Поскольку мы в теме, нам это казалось очевидным и не требующим
> дополнительных пояснений, но, поскольку это ещё не всем очевидно,
> поясню, из каких соображений мы исходили:
>
> - LTO - это безусловно полезная оптимизация, об этом много написано,
>   см. напр. [1] [2], поэтому ею хорошо было бы воспользоваться;
>
> - LTO - это уже широко распространённая оптимизация, её уже включили в
>   openSUSE, Fedora, Ubuntu, Clearlinux, скоро Debian, там уже вытоптали
>   основные грабли, большинство фиксов пакетов заапстримлено, поэтому ею
>   уже можно пользоваться;
>
> - LTO - это уже настолько распространённая оптимизация, что скоро без LTO
>   уже мало кто будет собирать, поэтому не пользоваться ею скоро будет себе
>   дороже;
>
> - После бранчевания мы в начале нового цикла разработки, самое время
>   включить LTO.
>
> - Исправление самой массовой сборочной ошибки "process-lto: ERROR:",
>   вызванной включением LTO, тривиально.
>
> - Выключить LTO в пакете в случае необходимости - тривиально.
>
> [1] https://documentation.suse.com/sbp/all/html/SBP-GCC-10/index.html
> [2] https://wiki.ubuntu.com/ToolChain/LTO

Это хорошо, но все ли наши архитектуры поддерживают LTO?
Ответ важен и его надо знать.

Rgrds, Алексей

>
> --
> ldv
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] I: LTO in %optflags by default

[Dmitry V. Levin]

On Thu, Aug 26, 2021 at 02:07:49AM +0300, Aleksey Novodvorsky wrote:
> чт, 26 авг. 2021 г. в 00:24, Dmitry V. Levin <ldv@altlinux.org>:
> >
> > On Tue, Aug 24, 2021 at 09:20:50PM +0300, Dmitry V. Levin wrote:
> > > Hi,
> > >
> > > Пришло время включить в Сизифе LTO (link-time optimization).
> >
> > Поскольку мы в теме, нам это казалось очевидным и не требующим
> > дополнительных пояснений, но, поскольку это ещё не всем очевидно,
> > поясню, из каких соображений мы исходили:
> >
> > - LTO - это безусловно полезная оптимизация, об этом много написано,
> >   см. напр. [1] [2], поэтому ею хорошо было бы воспользоваться;
> >
> > - LTO - это уже широко распространённая оптимизация, её уже включили в
> >   openSUSE, Fedora, Ubuntu, Clearlinux, скоро Debian, там уже вытоптали
> >   основные грабли, большинство фиксов пакетов заапстримлено, поэтому ею
> >   уже можно пользоваться;
> >
> > - LTO - это уже настолько распространённая оптимизация, что скоро без LTO
> >   уже мало кто будет собирать, поэтому не пользоваться ею скоро будет себе
> >   дороже;
> >
> > - После бранчевания мы в начале нового цикла разработки, самое время
> >   включить LTO.
> >
> > - Исправление самой массовой сборочной ошибки "process-lto: ERROR:",
> >   вызванной включением LTO, тривиально.
> >
> > - Выключить LTO в пакете в случае необходимости - тривиально.
> >
> > [1] https://documentation.suse.com/sbp/all/html/SBP-GCC-10/index.html
> > [2] https://wiki.ubuntu.com/ToolChain/LTO
> 
> Это хорошо, но все ли наши архитектуры поддерживают LTO?

Конечно, LTO поддерживается на всех наших архитектурах.


-- 
ldv

Re: [devel] I: LTO in %optflags by default

[Dmitry V. Levin]

On Wed, Aug 25, 2021 at 10:27:49PM +0300, Andrey Savchenko wrote:
> On Wed, 25 Aug 2021 11:37:46 +0400 Alexey Sheplyakov wrote:
> > Здравствуйте!
> > 
> > On 24.08.2021 22:20, Dmitry V. Levin wrote:
> > 
> > > Пришло время включить в Сизифе LTO (link-time optimization).
> > 
> > Поскольку LTO ломает сборку сотен пакетов, причем не каких попало,
> > а gcc, glibc, и т.п. - то время включать LTO как раз таки НЕ пришло.
> > 
> > А если кому-то всё равно очень хочется - надо сначала доработать пакеты
> > (на которые повлияет LTO), а потом уж включать. И нет, это не сопровождающие
> > пакетов должны заниматься этой глупостью, а именно этот "кто-то", кому
> > понадобилась LTO (или ещё какая модная фенечка).
> 
> Это давняя проблема. У нас есть правило: «кто сломал, тот
> и чинит» (я не нашёл такую политику, возможно, это джентельменское
> соглашение). Однако, на практике оно работает лишь для простых
> смертных, а с ключевыми компонентами системы — тем же тулчейном —
> всё наоборот: чинят мейнтенеры пакетов, которых обычно никто не
> справшивает и просто ставят перед фактом.
> 
> С одной стороны, такой подход можно понять, т.к. когда сломанных
> пакетов слишком много, авторы изменений просто физически не могут
> без помощи остальных всё исправить. С другой стороны он
> несправедлив по отношению к мейнтенерам других сложных подсистем
> (питон, джава, telive, cmake).
> 
> Давайте искать в этом вопросе золотую середину, чтоб всё было по
> справедливости. Возможно, следует сделать лимит на количество
> затронутых пакетов, после которого следует подключать сообщество
> к исправлению проблем. Другие предложения приветствуются.

Мы обсуждали обновления тулчейна в конце марта - начале апреля в этом треде:
https://lore.altlinux.org/devel/20210330142347.GA29398@altlinux.org/T/#u
И даже договорились, насколько я понимаю:
https://lore.altlinux.org/devel/20210404201605.GC15347@altlinux.org/

Надо понимать, что тулчейном у нас суммарно занимается менее одного
человека, а пользуются все, кто собирают arch-пакеты.
В таких условиях правило «кто сломал, тот и чинит» не применимо
совершенно, и максимум, что можно сделать - это опубликовать обзор
ожидаемых последствий изменений и дать ссылки для дальнейшего чтения.


-- 
ldv

Re: [devel] I: LTO in %optflags by default

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 3345 bytes --]

On Thu, 26 Aug 2021 02:19:29 +0300 Dmitry V. Levin wrote:
> On Thu, Aug 26, 2021 at 02:07:49AM +0300, Aleksey Novodvorsky wrote:
> > чт, 26 авг. 2021 г. в 00:24, Dmitry V. Levin <ldv@altlinux.org>:
> > >
> > > On Tue, Aug 24, 2021 at 09:20:50PM +0300, Dmitry V. Levin wrote:
> > > > Hi,
> > > >
> > > > Пришло время включить в Сизифе LTO (link-time optimization).
> > >
> > > Поскольку мы в теме, нам это казалось очевидным и не требующим
> > > дополнительных пояснений, но, поскольку это ещё не всем очевидно,
> > > поясню, из каких соображений мы исходили:
> > >
> > > - LTO - это безусловно полезная оптимизация, об этом много написано,
> > >   см. напр. [1] [2], поэтому ею хорошо было бы воспользоваться;
> > >
> > > - LTO - это уже широко распространённая оптимизация, её уже включили в
> > >   openSUSE, Fedora, Ubuntu, Clearlinux, скоро Debian, там уже вытоптали
> > >   основные грабли, большинство фиксов пакетов заапстримлено, поэтому ею
> > >   уже можно пользоваться;
> > >
> > > - LTO - это уже настолько распространённая оптимизация, что скоро без LTO
> > >   уже мало кто будет собирать, поэтому не пользоваться ею скоро будет себе
> > >   дороже;
> > >
> > > - После бранчевания мы в начале нового цикла разработки, самое время
> > >   включить LTO.
> > >
> > > - Исправление самой массовой сборочной ошибки "process-lto: ERROR:",
> > >   вызванной включением LTO, тривиально.
> > >
> > > - Выключить LTO в пакете в случае необходимости - тривиально.
> > >
> > > [1] https://documentation.suse.com/sbp/all/html/SBP-GCC-10/index.html
> > > [2] https://wiki.ubuntu.com/ToolChain/LTO
> > 
> > Это хорошо, но все ли наши архитектуры поддерживают LTO?
> 
> Конечно, LTO поддерживается на всех наших архитектурах.

Если мы говорим про все архитектуры, включая вторичные
сборочницы, то нет, на e2k не поддерживается. -flto игнорируется,
а вот более продвинутые опции приводят к ошибке:

$ gcc -flto -ffat-lto-objects test.c -o test
lcc: error: unrecognized command line option "-ffat-lto-objects"

С другой стороны, исправить это в e2k-версии rpm-build не сложно,
если не забыть. А вот если готовить эти изменения к вливанию
в основную ветку rpm-build, то там много переделывать нужно.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] I: LTO in %optflags by default

[Dmitry V. Levin]

On Thu, Aug 26, 2021 at 02:54:54AM +0300, Andrey Savchenko wrote:
> On Thu, 26 Aug 2021 02:19:29 +0300 Dmitry V. Levin wrote:
> > On Thu, Aug 26, 2021 at 02:07:49AM +0300, Aleksey Novodvorsky wrote:
> > > чт, 26 авг. 2021 г. в 00:24, Dmitry V. Levin <ldv@altlinux.org>:
> > > >
> > > > On Tue, Aug 24, 2021 at 09:20:50PM +0300, Dmitry V. Levin wrote:
> > > > > Hi,
> > > > >
> > > > > Пришло время включить в Сизифе LTO (link-time optimization).
> > > >
> > > > Поскольку мы в теме, нам это казалось очевидным и не требующим
> > > > дополнительных пояснений, но, поскольку это ещё не всем очевидно,
> > > > поясню, из каких соображений мы исходили:
> > > >
> > > > - LTO - это безусловно полезная оптимизация, об этом много написано,
> > > >   см. напр. [1] [2], поэтому ею хорошо было бы воспользоваться;
> > > >
> > > > - LTO - это уже широко распространённая оптимизация, её уже включили в
> > > >   openSUSE, Fedora, Ubuntu, Clearlinux, скоро Debian, там уже вытоптали
> > > >   основные грабли, большинство фиксов пакетов заапстримлено, поэтому ею
> > > >   уже можно пользоваться;
> > > >
> > > > - LTO - это уже настолько распространённая оптимизация, что скоро без LTO
> > > >   уже мало кто будет собирать, поэтому не пользоваться ею скоро будет себе
> > > >   дороже;
> > > >
> > > > - После бранчевания мы в начале нового цикла разработки, самое время
> > > >   включить LTO.
> > > >
> > > > - Исправление самой массовой сборочной ошибки "process-lto: ERROR:",
> > > >   вызванной включением LTO, тривиально.
> > > >
> > > > - Выключить LTO в пакете в случае необходимости - тривиально.
> > > >
> > > > [1] https://documentation.suse.com/sbp/all/html/SBP-GCC-10/index.html
> > > > [2] https://wiki.ubuntu.com/ToolChain/LTO
> > > 
> > > Это хорошо, но все ли наши архитектуры поддерживают LTO?
> > 
> > Конечно, LTO поддерживается на всех наших архитектурах.
> 
> Если мы говорим про все архитектуры, включая вторичные
> сборочницы, то нет, на e2k не поддерживается. -flto игнорируется,
> а вот более продвинутые опции приводят к ошибке:
> 
> $ gcc -flto -ffat-lto-objects test.c -o test
> lcc: error: unrecognized command line option "-ffat-lto-objects"

А почему там -flto игнорируется, а -ffat-lto-objects не игнорируется?
Это непоследовательно.

Впрочем, мы ожидали чего-то подобного со стороны lcc, поэтому наша
реализация это учитывает.  Если все будут следовать нашим рекомендациям
про %optflags_lto, то на e2k это практически не отразится, там просто
не станут включать %optflags_lto в %optflags.


-- 
ldv

Re: [devel] I: LTO in %optflags by default

[Dmitry V. Levin]

On Tue, Aug 24, 2021 at 09:20:50PM +0300, Dmitry V. Levin wrote:
[...]
> * Около 158 пакетов перестанут пересобираться с другой диагностикой,
> связанной с включением LTO.  С такими пакетами можно поступить одним из
> нескольких способов:
> - обновить пакеты, весьма вероятно, что они уже исправлены в новых версиях;
> - исправить LTO самостоятельно;
> - выключить LTO, переопределив макрос optflags_lto.

Забыл добавить очевидное: большая часть необходимых исправлений доступна
в репозиториях, где LTO включили раньше нас.


-- 
ldv

Re: [devel] I: LTO in %optflags by default

[alexei]

Добрый день!

----- Исходное сообщение -----
> От: "ldv" <ldv@altlinux.org>
> Кому: "ALT Linux Team development discussions" <devel@lists.altlinux.org>
> Отправленные: Четверг, 26 Август 2021 г 7:19:29
> Тема: Re: [devel] I: LTO in %optflags by default

> On Thu, Aug 26, 2021 at 02:07:49AM +0300, Aleksey Novodvorsky wrote:
>> чт, 26 авг. 2021 г. в 00:24, Dmitry V. Levin <ldv@altlinux.org>:
>> >
>> > On Tue, Aug 24, 2021 at 09:20:50PM +0300, Dmitry V. Levin wrote:
>> > > Hi,
>> > >
>> > > Пришло время включить в Сизифе LTO (link-time optimization).
>> >
>> > Поскольку мы в теме, нам это казалось очевидным и не требующим
>> > дополнительных пояснений, но, поскольку это ещё не всем очевидно,
>> > поясню, из каких соображений мы исходили:
>> >
>> > - LTO - это безусловно полезная оптимизация, об этом много написано,
>> >   см. напр. [1] [2], поэтому ею хорошо было бы воспользоваться;
>> >
>> > - LTO - это уже широко распространённая оптимизация, её уже включили в
>> >   openSUSE, Fedora, Ubuntu, Clearlinux, скоро Debian, там уже вытоптали
>> >   основные грабли, большинство фиксов пакетов заапстримлено, поэтому ею
>> >   уже можно пользоваться;
>> >
>> > - LTO - это уже настолько распространённая оптимизация, что скоро без LTO
>> >   уже мало кто будет собирать, поэтому не пользоваться ею скоро будет себе
>> >   дороже;
>> >
>> > - После бранчевания мы в начале нового цикла разработки, самое время
>> >   включить LTO.
>> >
>> > - Исправление самой массовой сборочной ошибки "process-lto: ERROR:",
>> >   вызванной включением LTO, тривиально.
>> >
>> > - Выключить LTO в пакете в случае необходимости - тривиально.
>> >
>> > [1] https://documentation.suse.com/sbp/all/html/SBP-GCC-10/index.html
>> > [2] https://wiki.ubuntu.com/ToolChain/LTO
>> 
>> Это хорошо, но все ли наши архитектуры поддерживают LTO?
> 
> Конечно, LTO поддерживается на всех наших архитектурах.

Есть некоторые сомнения по этому поводу.

http://git.altlinux.org/tasks/283741/build/100/armh/log
======================================================
[00:02:11] /usr/lib/gcc/armh-alt-linux-gnueabi/10/include/arm_acle.h: In function 'pg_comp_crc32c_armv8':
[00:02:11] /usr/lib/gcc/armh-alt-linux-gnueabi/10/include/arm_acle.h:739:10: error: this builtin is not supported for this target
[00:02:11]   739 |   return __builtin_arm_crc32cb (__a, __b);
[00:02:11]       |          ^
[00:02:11] /usr/lib/gcc/armh-alt-linux-gnueabi/10/include/arm_acle.h:745:10: error: this builtin is not supported for this target
[00:02:11]   745 |   return __builtin_arm_crc32ch (__a, __b);
[00:02:11]       |          ^
[00:02:11] /usr/lib/gcc/armh-alt-linux-gnueabi/10/include/arm_acle.h:751:10: error: this builtin is not supported for this target
[00:02:11]   751 |   return __builtin_arm_crc32cw (__a, __b);
[00:02:11]       |          ^
[00:02:11] /usr/lib/gcc/armh-alt-linux-gnueabi/10/include/arm_acle.h:751:10: error: this builtin is not supported for this target
[00:02:11]   751 |   return __builtin_arm_crc32cw (__a, __b);
[00:02:11]       |          ^
[00:02:11] /usr/lib/gcc/armh-alt-linux-gnueabi/10/include/arm_acle.h:751:10: error: this builtin is not supported for this target
[00:02:11]   751 |   return __builtin_arm_crc32cw (__a, __b);
[00:02:11]       |          ^
[00:02:11] /usr/lib/gcc/armh-alt-linux-gnueabi/10/include/arm_acle.h:751:10: error: this builtin is not supported for this target
[00:02:11]   751 |   return __builtin_arm_crc32cw (__a, __b);
[00:02:11]       |          ^
[00:02:11] /usr/lib/gcc/armh-alt-linux-gnueabi/10/include/arm_acle.h:745:10: error: this builtin is not supported for this target
[00:02:11]   745 |   return __builtin_arm_crc32ch (__a, __b);
[00:02:11]       |          ^
[00:02:11] /usr/lib/gcc/armh-alt-linux-gnueabi/10/include/arm_acle.h:739:10: error: this builtin is not supported for this target
[00:02:11]   739 |   return __builtin_arm_crc32cb (__a, __b);
[00:02:11]       |          ^
[00:02:11] make[3]: *** [/usr/src/tmp/ccaltlWW.mk:377: /usr/src/tmp/postgres.w4Po8V.ltrans125.ltrans.o] Error 1
[00:02:11] lto-wrapper: fatal error: make returned 2 exit status
[00:02:11] compilation terminated.
[00:02:11] ld: error: lto-wrapper failed
[00:02:11] collect2: error: ld returned 1 exit status
[00:02:11] make[2]: *** [Makefile:66: postgres] Error 1
[00:02:11] make[2]: Leaving directory '/usr/src/RPM/BUILD/postgresql13-13.4/src/backend'
[00:02:11] make[1]: *** [Makefile:42: all-backend-recurse] Error 2
[00:02:11] make: *** [GNUmakefile:11: all-src-recurse] Error 2
=======================================================

При этом задание с отключенным LTO для armh собирается успешно
( http://git.altlinux.org/tasks/283796/ )

Re: [devel] I: LTO in %optflags by defaulta (top-level asm)

[Vitaly Chikunov]

Hi,

On Wed, Aug 25, 2021 at 03:33:51AM +0300, Dmitry V. Levin wrote:
> > [...]
> Вероятно, более переносимой будет следующая конструкция:
> 
> %{?optflags_lto:%global optflags_lto %optflags_lto -ffat-lto-objects}

Небольшое количество пакетов содержат в configure тесты с top-level
asm() - к сожалению, это не совместимо с LTO и такие тесты будут давать
false positive, что может привести к ошибкам в сборке. Бага в gcc:

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57703

GCC only workaround: чтоб оставить LTO можно включить -ffat-lto-objects.

Проверить configure на asm() можно, например:

  egrep -w '_?_?asm_?_?.*\(' configure*

Список пакетов из Fedora, где есть такая проблема:

  lcdproc
  libcaca
  libgcrypt
  librdkafka
  libsecp256k1
  libsodium
  mednafen
  openpgm

Re: [devel] I: LTO in %optflags by default

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 4562 bytes --]

On Thu, 26 Aug 2021 03:04:26 +0300 Dmitry V. Levin wrote:
> On Thu, Aug 26, 2021 at 02:54:54AM +0300, Andrey Savchenko wrote:
> > On Thu, 26 Aug 2021 02:19:29 +0300 Dmitry V. Levin wrote:
> > > On Thu, Aug 26, 2021 at 02:07:49AM +0300, Aleksey Novodvorsky wrote:
> > > > чт, 26 авг. 2021 г. в 00:24, Dmitry V. Levin <ldv@altlinux.org>:
> > > > >
> > > > > On Tue, Aug 24, 2021 at 09:20:50PM +0300, Dmitry V. Levin wrote:
> > > > > > Hi,
> > > > > >
> > > > > > Пришло время включить в Сизифе LTO (link-time optimization).
> > > > >
> > > > > Поскольку мы в теме, нам это казалось очевидным и не требующим
> > > > > дополнительных пояснений, но, поскольку это ещё не всем очевидно,
> > > > > поясню, из каких соображений мы исходили:
> > > > >
> > > > > - LTO - это безусловно полезная оптимизация, об этом много написано,
> > > > >   см. напр. [1] [2], поэтому ею хорошо было бы воспользоваться;
> > > > >
> > > > > - LTO - это уже широко распространённая оптимизация, её уже включили в
> > > > >   openSUSE, Fedora, Ubuntu, Clearlinux, скоро Debian, там уже вытоптали
> > > > >   основные грабли, большинство фиксов пакетов заапстримлено, поэтому ею
> > > > >   уже можно пользоваться;
> > > > >
> > > > > - LTO - это уже настолько распространённая оптимизация, что скоро без LTO
> > > > >   уже мало кто будет собирать, поэтому не пользоваться ею скоро будет себе
> > > > >   дороже;
> > > > >
> > > > > - После бранчевания мы в начале нового цикла разработки, самое время
> > > > >   включить LTO.
> > > > >
> > > > > - Исправление самой массовой сборочной ошибки "process-lto: ERROR:",
> > > > >   вызванной включением LTO, тривиально.
> > > > >
> > > > > - Выключить LTO в пакете в случае необходимости - тривиально.
> > > > >
> > > > > [1] https://documentation.suse.com/sbp/all/html/SBP-GCC-10/index.html
> > > > > [2] https://wiki.ubuntu.com/ToolChain/LTO
> > > > 
> > > > Это хорошо, но все ли наши архитектуры поддерживают LTO?
> > > 
> > > Конечно, LTO поддерживается на всех наших архитектурах.
> > 
> > Если мы говорим про все архитектуры, включая вторичные
> > сборочницы, то нет, на e2k не поддерживается. -flto игнорируется,
> > а вот более продвинутые опции приводят к ошибке:
> > 
> > $ gcc -flto -ffat-lto-objects test.c -o test
> > lcc: error: unrecognized command line option "-ffat-lto-objects"
> 
> А почему там -flto игнорируется, а -ffat-lto-objects не игнорируется?
> Это непоследовательно.

Потому что они обычно игнорируют те опции, которые попадаются на
практике. Кроме того, -ffat-lto-objects появилась существенно позже
-flto. Разумеется, я запрошу игнорирование и этой опции, но это
займёт время.

> Впрочем, мы ожидали чего-то подобного со стороны lcc, поэтому наша
> реализация это учитывает.  Если все будут следовать нашим рекомендациям
> про %optflags_lto, то на e2k это практически не отразится, там просто
> не станут включать %optflags_lto в %optflags.

Да. Но кто-нибудь может просто черезю %add_optflags добавить. Не все
полностью читают devel на регулярной основе. Нужно как минимум на
вики добавить.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] I: LTO in %optflags by default

[Vitaly Lipatov]

Andrey Savchenko писал 26.8.21 9:39:
> On Thu, 26 Aug 2021 03:04:26 +0300 Dmitry V. Levin wrote:
...
> Потому что они обычно игнорируют те опции, которые попадаются на
> практике. Кроме того, -ffat-lto-objects появилась существенно позже
> -flto. Разумеется, я запрошу игнорирование и этой опции, но это
> займёт время.
> 
>> Впрочем, мы ожидали чего-то подобного со стороны lcc, поэтому наша
>> реализация это учитывает.  Если все будут следовать нашим 
>> рекомендациям
>> про %optflags_lto, то на e2k это практически не отразится, там просто
>> не станут включать %optflags_lto в %optflags.
> 
> Да. Но кто-нибудь может просто черезю %add_optflags добавить. Не все
> полностью читают devel на регулярной основе. Нужно как минимум на
> вики добавить.
https://www.altlinux.org/LTO

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] I: LTO in %optflags by default

[Dmitry V. Levin]

On Thu, Aug 26, 2021 at 12:23:01PM +0800, alexei@taf.ru wrote:
[...]
> >> Это хорошо, но все ли наши архитектуры поддерживают LTO?
> > 
> > Конечно, LTO поддерживается на всех наших архитектурах.
> 
> Есть некоторые сомнения по этому поводу.

У вас уже собралось несколько пакетов с включённой LTO,
так что не сомневайтесь.

> http://git.altlinux.org/tasks/283741/build/100/armh/log
> ======================================================
> [00:02:11] /usr/lib/gcc/armh-alt-linux-gnueabi/10/include/arm_acle.h: In function 'pg_comp_crc32c_armv8':
> [00:02:11] /usr/lib/gcc/armh-alt-linux-gnueabi/10/include/arm_acle.h:739:10: error: this builtin is not supported for this target
> [00:02:11]   739 |   return __builtin_arm_crc32cb (__a, __b);
> [00:02:11]       |          ^
> [00:02:11] /usr/lib/gcc/armh-alt-linux-gnueabi/10/include/arm_acle.h:745:10: error: this builtin is not supported for this target
> [00:02:11]   745 |   return __builtin_arm_crc32ch (__a, __b);
> [00:02:11]       |          ^
> [00:02:11] /usr/lib/gcc/armh-alt-linux-gnueabi/10/include/arm_acle.h:751:10: error: this builtin is not supported for this target
> [00:02:11]   751 |   return __builtin_arm_crc32cw (__a, __b);
> [00:02:11]       |          ^
> [00:02:11] /usr/lib/gcc/armh-alt-linux-gnueabi/10/include/arm_acle.h:751:10: error: this builtin is not supported for this target
> [00:02:11]   751 |   return __builtin_arm_crc32cw (__a, __b);
> [00:02:11]       |          ^
> [00:02:11] /usr/lib/gcc/armh-alt-linux-gnueabi/10/include/arm_acle.h:751:10: error: this builtin is not supported for this target
> [00:02:11]   751 |   return __builtin_arm_crc32cw (__a, __b);
> [00:02:11]       |          ^
> [00:02:11] /usr/lib/gcc/armh-alt-linux-gnueabi/10/include/arm_acle.h:751:10: error: this builtin is not supported for this target
> [00:02:11]   751 |   return __builtin_arm_crc32cw (__a, __b);
> [00:02:11]       |          ^
> [00:02:11] /usr/lib/gcc/armh-alt-linux-gnueabi/10/include/arm_acle.h:745:10: error: this builtin is not supported for this target
> [00:02:11]   745 |   return __builtin_arm_crc32ch (__a, __b);
> [00:02:11]       |          ^
> [00:02:11] /usr/lib/gcc/armh-alt-linux-gnueabi/10/include/arm_acle.h:739:10: error: this builtin is not supported for this target
> [00:02:11]   739 |   return __builtin_arm_crc32cb (__a, __b);
> [00:02:11]       |          ^
> [00:02:11] make[3]: *** [/usr/src/tmp/ccaltlWW.mk:377: /usr/src/tmp/postgres.w4Po8V.ltrans125.ltrans.o] Error 1
> [00:02:11] lto-wrapper: fatal error: make returned 2 exit status
> [00:02:11] compilation terminated.
> [00:02:11] ld: error: lto-wrapper failed
> [00:02:11] collect2: error: ld returned 1 exit status
> [00:02:11] make[2]: *** [Makefile:66: postgres] Error 1
> [00:02:11] make[2]: Leaving directory '/usr/src/RPM/BUILD/postgresql13-13.4/src/backend'
> [00:02:11] make[1]: *** [Makefile:42: all-backend-recurse] Error 2
> [00:02:11] make: *** [GNUmakefile:11: all-src-recurse] Error 2
> =======================================================
> 
> При этом задание с отключенным LTO для armh собирается успешно
> ( http://git.altlinux.org/tasks/283796/ )

Это один из нескольких случаев, которые, видимо, были исправлены в gcc11:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96939

Наверное, можно пока отключить LTO для armh и оставить в спек-файле
соответствующий комментарий, а после перехода на gcc11 включить обратно.


-- 
ldv

Re: [devel] I: LTO in %optflags by default

[Alexey V. Vissarionov]

On 2021-08-26 02:54:20 +0300, Dmitry V. Levin wrote:

 > Надо понимать, что тулчейном у нас суммарно занимается менее
 > одного человека, а пользуются все, кто собирают arch-пакеты.
 > В таких условиях правило "кто сломал, тот и чинит" не применимо
 > совершенно, и максимум, что можно сделать - это опубликовать
 > обзор ожидаемых последствий изменений и дать ссылки для
 > дальнейшего чтения.

Но при этом "максимум, что можно" - еще и "минимум, что нужно".


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] I: LTO in %optflags by default

[Alexey V. Vissarionov]

On 2021-08-26 03:04:26 +0300, Dmitry V. Levin wrote:

 > Впрочем, мы ожидали чего-то подобного со стороны lcc, поэтому
 > наша реализация это учитывает. Если все будут следовать нашим
 > рекомендациям про %optflags_lto, то на e2k это практически не
 > отразится, там просто не станут включать %optflags_lto в
 > %optflags.

Это уже документировано? Где?


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] I: LTO in %optflags by default

[Michael Shigorin]

On Wed, Aug 25, 2021 at 10:03:39AM +0300, Denis Medvedev wrote:
> > С точки зрения безопасности это хорошо, а вот тормоза даёт дикие,
> > особенно на тяжёлых приложениях типа LO. Возможно, в этом есть смысл
> > в специальных ветках, но в Сизиф такое не нужно тянуть.
> В таком случае как мне правильно сделать дефолты для особых веток?
> Сделать свою версию какого пакета?

Возможно, стоит сделать в rpm-build ручку hardening
и включать её в конфигурации сборочницы для веток c10*
(у нас для sisyphus_e2k и соответствующих бранчей таких
ручек много, хоть потихоньку и убавляются; можем научить).

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] Administrivii

[Michael Shigorin]

On Wed, Aug 25, 2021 at 11:03:22PM +0300, Alexey V. Vissarionov wrote:
> >> Эту тему можно было бы обсудить по-существу, если бы вы не
> >> написали то, что вы написали дальше.

Дим, такое в твой адрес говорит далеко не первый человек --
возможно, дело всё-таки не в бобине, а в

  постановке людей перед фактом того, что _им_ нужно теперь
  выполнить дополнительную работу в интересах _других_ людей,

вместо

  _анонса_ таких изменений и доведения общей пользы до общего
  сведения и уже затем COMMIT через денёк.

Даже когда на самом деле польза вернётся обратно (думаю, многие
помнят -Wl,--as-needed в 2007 или когда там), баланс интересов
беречь стоит (и порой стоит даже слушать обратную связь или
хотя бы принимать её, иначе лишаешь себя права на ошибку,
а это чудовищная ответственность, которую никто из нас нести
не способен, по опыту).

> >>> А "я тут всё сломал, а вы теперь - чините" - это прямое
> >>> вредительство.
> > Простите, погорячился. Это я зря. Постараюсь в дальнейшем
> > аккуратнее подбирать формулировки.
> Вот тут квантором \forall размахивать уж точно не следовало,
> да и умысла что-либо ломать у ldv заведомо не было.

Тем не менее изменение и впрямь было произведено,
насколько могу видеть, предельно дИмократично,
а вовсе не "со всенародным обсуждением" и прочими
рюшиками, которые типа как должны бы быть.

Просто для протокола, так-то я Диму люблю не менее всех
и Виталику за труды благодарен (хотя пока что не понял,
debugedit в итоге починили или всё так же падает).

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] debugedit

[Dmitry V. Levin]

On Thu, Aug 26, 2021 at 10:02:55PM +0300, Michael Shigorin wrote:
[...]
> Просто для протокола, так-то я Диму люблю не менее всех
> и Виталику за труды благодарен (хотя пока что не понял,
> debugedit в итоге починили или всё так же падает).

На обычных архитектурах debugedit не падает (и вроде бы никогда не падал),
а на e2k тебе виднее.


-- 
ldv

Re: [devel] I: LTO in %optflags by default

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 5219 bytes --]

On Thu, 26 Aug 2021 02:54:20 +0300 Dmitry V. Levin wrote:
> On Wed, Aug 25, 2021 at 10:27:49PM +0300, Andrey Savchenko wrote:
> > On Wed, 25 Aug 2021 11:37:46 +0400 Alexey Sheplyakov wrote:
> > > Здравствуйте!
> > > 
> > > On 24.08.2021 22:20, Dmitry V. Levin wrote:
> > > 
> > > > Пришло время включить в Сизифе LTO (link-time optimization).
> > > 
> > > Поскольку LTO ломает сборку сотен пакетов, причем не каких попало,
> > > а gcc, glibc, и т.п. - то время включать LTO как раз таки НЕ пришло.
> > > 
> > > А если кому-то всё равно очень хочется - надо сначала доработать пакеты
> > > (на которые повлияет LTO), а потом уж включать. И нет, это не сопровождающие
> > > пакетов должны заниматься этой глупостью, а именно этот "кто-то", кому
> > > понадобилась LTO (или ещё какая модная фенечка).
> > 
> > Это давняя проблема. У нас есть правило: «кто сломал, тот
> > и чинит» (я не нашёл такую политику, возможно, это джентельменское
> > соглашение). Однако, на практике оно работает лишь для простых
> > смертных, а с ключевыми компонентами системы — тем же тулчейном —
> > всё наоборот: чинят мейнтенеры пакетов, которых обычно никто не
> > справшивает и просто ставят перед фактом.
> > 
> > С одной стороны, такой подход можно понять, т.к. когда сломанных
> > пакетов слишком много, авторы изменений просто физически не могут
> > без помощи остальных всё исправить. С другой стороны он
> > несправедлив по отношению к мейнтенерам других сложных подсистем
> > (питон, джава, telive, cmake).
> > 
> > Давайте искать в этом вопросе золотую середину, чтоб всё было по
> > справедливости. Возможно, следует сделать лимит на количество
> > затронутых пакетов, после которого следует подключать сообщество
> > к исправлению проблем. Другие предложения приветствуются.
> 
> Мы обсуждали обновления тулчейна в конце марта - начале апреля в этом треде:
> https://lore.altlinux.org/devel/20210330142347.GA29398@altlinux.org/T/#u
> И даже договорились, насколько я понимаю:
> https://lore.altlinux.org/devel/20210404201605.GC15347@altlinux.org/

И где же в этих обсуждениях анонс повсеместного включения LTO?
Я что-то не вижу по ссылкам.

Недовольство у сообщества оттого, что людей никто не спрашивал,
публичного обсуждения не было, а в закрытом кругу было принято
решение и остальных лишь поставили перед фактом: мы сделали так,
живите с этим как хотите.

> Надо понимать, что тулчейном у нас суммарно занимается менее одного
> человека, а пользуются все, кто собирают arch-пакеты.
> В таких условиях правило «кто сломал, тот и чинит» не применимо
> совершенно, и максимум, что можно сделать - это опубликовать обзор
> ожидаемых последствий изменений и дать ссылки для дальнейшего чтения.

Да, я это понимаю и в предыдущем письме недвусмысленно об этом
написал. Но точно так же у нас меньше одного человека занимается
другими тяжёлыми подсистемами, затрагивающими большое число пакетов,
например, texlive, java и, возможно, python. А правила получаются
для всех разные. И я нахожу это несправедливым, поэтому предлагаю
выработать общие критерии когда чинит, кто сломал, а когда
подключаются мейнтенеры поломанных пакетов.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] I: LTO in %optflags by default

[Dmitry V. Levin]

On Thu, Aug 26, 2021 at 09:39:30AM +0300, Andrey Savchenko wrote:
> On Thu, 26 Aug 2021 03:04:26 +0300 Dmitry V. Levin wrote:
> > On Thu, Aug 26, 2021 at 02:54:54AM +0300, Andrey Savchenko wrote:
[...]
> > > Если мы говорим про все архитектуры, включая вторичные
> > > сборочницы, то нет, на e2k не поддерживается. -flto игнорируется,
> > > а вот более продвинутые опции приводят к ошибке:
> > > 
> > > $ gcc -flto -ffat-lto-objects test.c -o test
> > > lcc: error: unrecognized command line option "-ffat-lto-objects"
> > 
> > А почему там -flto игнорируется, а -ffat-lto-objects не игнорируется?
> > Это непоследовательно.
> 
> Потому что они обычно игнорируют те опции, которые попадаются на
> практике. Кроме того, -ffat-lto-objects появилась существенно позже
> -flto. Разумеется, я запрошу игнорирование и этой опции, но это
> займёт время.

Никак не могу привыкнуть к тому, что вы не можете сами пропатчить фронтенд
компилятора, чтобы добавить просто игнорирование опции, что вам нужно
обращаться к каким-то проприетарщикам с просьбой сделать такое тривиальное
изменение.

> > Впрочем, мы ожидали чего-то подобного со стороны lcc, поэтому наша
> > реализация это учитывает.  Если все будут следовать нашим рекомендациям
> > про %optflags_lto, то на e2k это практически не отразится, там просто
> > не станут включать %optflags_lto в %optflags.
> 
> Да. Но кто-нибудь может просто черезю %add_optflags добавить.

Мы можем мониторить spec.git на эту тему.

> Не все
> полностью читают devel на регулярной основе. Нужно как минимум на
> вики добавить.

На вики добавлено.


-- 
ldv

Re: [devel] I: LTO in %optflags by default

[Dmitry V. Levin]

On Thu, Aug 26, 2021 at 10:33:49PM +0300, Andrey Savchenko wrote:
> On Thu, 26 Aug 2021 02:54:20 +0300 Dmitry V. Levin wrote:
> > On Wed, Aug 25, 2021 at 10:27:49PM +0300, Andrey Savchenko wrote:
> > > On Wed, 25 Aug 2021 11:37:46 +0400 Alexey Sheplyakov wrote:
> > > > Здравствуйте!
> > > > 
> > > > On 24.08.2021 22:20, Dmitry V. Levin wrote:
> > > > 
> > > > > Пришло время включить в Сизифе LTO (link-time optimization).
> > > > 
> > > > Поскольку LTO ломает сборку сотен пакетов, причем не каких попало,
> > > > а gcc, glibc, и т.п. - то время включать LTO как раз таки НЕ пришло.
> > > > 
> > > > А если кому-то всё равно очень хочется - надо сначала доработать пакеты
> > > > (на которые повлияет LTO), а потом уж включать. И нет, это не сопровождающие
> > > > пакетов должны заниматься этой глупостью, а именно этот "кто-то", кому
> > > > понадобилась LTO (или ещё какая модная фенечка).
> > > 
> > > Это давняя проблема. У нас есть правило: «кто сломал, тот
> > > и чинит» (я не нашёл такую политику, возможно, это джентельменское
> > > соглашение). Однако, на практике оно работает лишь для простых
> > > смертных, а с ключевыми компонентами системы — тем же тулчейном —
> > > всё наоборот: чинят мейнтенеры пакетов, которых обычно никто не
> > > справшивает и просто ставят перед фактом.
> > > 
> > > С одной стороны, такой подход можно понять, т.к. когда сломанных
> > > пакетов слишком много, авторы изменений просто физически не могут
> > > без помощи остальных всё исправить. С другой стороны он
> > > несправедлив по отношению к мейнтенерам других сложных подсистем
> > > (питон, джава, telive, cmake).
> > > 
> > > Давайте искать в этом вопросе золотую середину, чтоб всё было по
> > > справедливости. Возможно, следует сделать лимит на количество
> > > затронутых пакетов, после которого следует подключать сообщество
> > > к исправлению проблем. Другие предложения приветствуются.
> > 
> > Мы обсуждали обновления тулчейна в конце марта - начале апреля в этом треде:
> > https://lore.altlinux.org/devel/20210330142347.GA29398@altlinux.org/T/#u
> > И даже договорились, насколько я понимаю:
> > https://lore.altlinux.org/devel/20210404201605.GC15347@altlinux.org/
> 
> И где же в этих обсуждениях анонс повсеместного включения LTO?
> Я что-то не вижу по ссылкам.

Что толку в анонсе LTO, пока нет списка последствий.
А когда есть список последствий, что толку откладывать неизбежное.
Обсуждать имеет смысл, когда есть выбор, включать LTO или нет.

Единственная тема, которую можно было бы обсудить - это что делать
сначала, обновлять тулчейн или включать LTO.  Но и тут всё просто:
что готово первым, то и внедряется первым.

> Недовольство у сообщества оттого, что людей никто не спрашивал,
> публичного обсуждения не было, а в закрытом кругу было принято
> решение и остальных лишь поставили перед фактом: мы сделали так,
> живите с этим как хотите.

Люди, как правило, не замечают пользы, но замечают дополнительную работу,
которую приходится делать, пусть даже тривиальную.
Кроме того, люди хотят, чтобы им всё объяснили и спросили их мнения даже
тогда, когда выбора по сути нет.
Такое поведение людей сложно назвать рациональным.


-- 
ldv

Re: [devel] I: LTO in %optflags by default

[Sergey V Turchin]

On Friday, 27 August 2021 03:37:45 MSK Dmitry V wrote:

[...]
> Люди, как правило, не замечают пользы, но замечают дополнительную работу,
> которую приходится делать, пусть даже тривиальную.
> Кроме того, люди хотят, чтобы им всё объяснили и спросили их мнения даже
> тогда, когда выбора по сути нет.
> Такое поведение людей сложно назвать рациональным.
Так, о том и разговор, что как бы кому-то не хотелось, а корректнее всегда 
будет попытка улаживать эти 3 вышеуказанных пункта, иначе по факту это лишние 
провокации негативного отношения со стороны тех самых "людей".

-- 
Regards, Sergey.

Re: [devel] I: LTO in %optflags by default

[Alexey V. Vissarionov]

On 2021-08-27 03:37:45 +0300, Dmitry V. Levin wrote:

 >> И где же в этих обсуждениях анонс повсеместного включения LTO?
 >> Я что-то не вижу по ссылкам.
 > Что толку в анонсе LTO, пока нет списка последствий. А когда
 > есть список последствий, что толку откладывать неизбежное.
 > Обсуждать имеет смысл, когда есть выбор, включать LTO или нет.

Еще бывает "когда" и "в какие сроки".

 > Единственная тема, которую можно было бы обсудить - это что
 > делать сначала, обновлять тулчейн или включать LTO. Но и тут
 > всё просто: что готово первым, то и внедряется первым.

Ну ведь не по принципу "раз-два, и в production"... Или?

 >> Недовольство у сообщества оттого, что людей никто не
 >> спрашивал, публичного обсуждения не было, а в закрытом кругу
 >> было принято решение и остальных лишь поставили перед фактом:
 >> мы сделали так, живите с этим как хотите.
 > Люди, как правило, не замечают пользы,

Так покажи ее. В простейшем случае - "мы собираемся сделать %s,
это позволит нам сделать %s и избавиться от %s, ожидаемый срок
%s, проверять вот так, про обнаруженные коряквы писать %s".

 > но замечают дополнительную работу, которую приходится делать,
 > пусть даже тривиальную.

Ага. И выглядит это как "они там опять что-то навертели".

 > Кроме того, люди хотят, чтобы им всё объяснили

Вполне разумное желание.

 > и спросили их мнения даже тогда, когда выбора по сути нет.

См. выше про "когда" и "в какие сроки".

 > Такое поведение людей сложно назвать рациональным.

Пинками в светлое будущее, ага.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] I: LTO in %optflags by default

[Alexey Sheplyakov]

On 27.08.2021 04:37, Dmitry V. Levin wrote:

> Люди, как правило, не замечают пользы, но замечают дополнительную работу,
> которую приходится делать, пусть даже тривиальную.

Полегче, пожалуйста, с квантором общности.
Люди прекрасно понимают преимущества cross-module/whole program optimization.
Но и отрицательные последствия тоже знают:

1) Дополнительные оптимизации часто вскрывают баги, причину которых достаточно
   сложно выяснить, а как чинить - вообще не ясно [1]

   [1] Пример: https://www.ginac.de/pipermail/cln-list/2020-September/000772.html

2) Глобальная оптимизация жрёт память, как не в себя.
   Потому на машинах с "небольшим" (8 ГБ) объёмом памяти сборка чего-то сложнее
   "hello, world" будет будить ктулху^W OOM killer. А на 32-битных архитектурах
   упрётся в лимит адресного пространства.

> Кроме того, люди хотят, чтобы им всё объяснили и спросили их мнения даже
> тогда, когда выбора по сути нет.

Даже если тебя съели, у тебя всё еще есть два выхода (C)

Re: [devel] I: LTO in %optflags by default

[Dmitry V. Levin]

On Fri, Aug 27, 2021 at 02:00:08PM +0400, Alexey Sheplyakov wrote:
> On 27.08.2021 04:37, Dmitry V. Levin wrote:
> 
> > Люди, как правило, не замечают пользы, но замечают дополнительную работу,
> > которую приходится делать, пусть даже тривиальную.
> 
> Полегче, пожалуйста, с квантором общности.
> Люди прекрасно понимают преимущества cross-module/whole program optimization.
> Но и отрицательные последствия тоже знают:
> 
> 1) Дополнительные оптимизации часто вскрывают баги, причину которых достаточно
>    сложно выяснить, а как чинить - вообще не ясно [1]
> 
>    [1] Пример: https://www.ginac.de/pipermail/cln-list/2020-September/000772.html
> 
> 2) Глобальная оптимизация жрёт память, как не в себя.
>    Потому на машинах с "небольшим" (8 ГБ) объёмом памяти сборка чего-то сложнее
>    "hello, world" будет будить ктулху^W OOM killer. А на 32-битных архитектурах
>    упрётся в лимит адресного пространства.

Всё верно.  Когда оптимизация не подходит, её можно выключить.


-- 
ldv

[devel] Статические библиотеки и thin LTO (Was: I: LTO in %optflags by default)

[Alexey Sheplyakov]

Добрый вечер!

On 24.08.2021 22:22, Dmitry V. Levin wrote:
> On Tue, Aug 24, 2021 at 09:20:50PM +0300, Dmitry V. Levin wrote:
>> * 382 пакета перестанут пересобираться с диагностикой следующего вида:
>> process-lto: ERROR: ./usr/lib64/libtcb.a: contains __gnu_lto_slim only.
>> Perhaps, you need to %define optflags_lto %optflags_lto -ffat-lto-objects

Странно это. GCC прекрасно умеет создавать и использовать архивы
из thin LTO объектов:

cat > add.c <<-EOF
int add(int x, int y) { return x + y; }
EOF
cat > main.c <<-EOF
extern int add(int x, int y);
int main(int argc, char **argv) {
	volatile int a = 1;
        volatile int b = 2;
        return add(a, b);
}
EOF

gcc -c -flto -fno-fat-lto-objects -O2 -g add.c
gcc-ar rcs libadd.a add.o
gcc -c -flto -fno-fat-lto-objects -O2 -g main.c
gcc -flto -O2 -o main main.o libadd.a
objdump -j .text --disassemble=main main

Получаю:

main:     file format elf64-x86-64

Disassembly of section .text:

0000000000001040 <main>:
    1040:	f3 0f 1e fa          	endbr64 
    1044:	c7 44 24 fc 01 00 00 	movl   $0x1,-0x4(%rsp)
    104b:	00 
    104c:	c7 44 24 f8 02 00 00 	movl   $0x2,-0x8(%rsp)
    1053:	00 
    1054:	8b 44 24 f8          	mov    -0x8(%rsp),%eax
    1058:	8b 54 24 fc          	mov    -0x4(%rsp),%edx
    105c:	01 d0                	add    %edx,%eax
    105e:	c3                   	ret    

Re: [devel] Статические библиотеки и thin LTO

[Vitaly Chikunov]

Hi,

On Fri, Aug 27, 2021 at 11:43:17PM +0400, Alexey Sheplyakov wrote:
> Добрый вечер!
> 
> On 24.08.2021 22:22, Dmitry V. Levin wrote:
> > On Tue, Aug 24, 2021 at 09:20:50PM +0300, Dmitry V. Levin wrote:
> >> * 382 пакета перестанут пересобираться с диагностикой следующего вида:
> >> process-lto: ERROR: ./usr/lib64/libtcb.a: contains __gnu_lto_slim only.
> >> Perhaps, you need to %define optflags_lto %optflags_lto -ffat-lto-objects
> 
> Странно это. GCC прекрасно умеет создавать и использовать архивы
> из thin LTO объектов:

Нельзя запаковывать GIMPLE в репозиторий, так как он не переносимый
между версиями GCC. Иначе после каждого обновления GCC пришлось бы
пересобирать все эти пакеты.

  "The bytecode files are versioned and there is a strict version
  check, so bytecode files generated in one version of GCC do not
  work with an older or newer version of GCC." -- gcc(1)

Re: [devel] Статические библиотеки и thin LTO

[Alexey Sheplyakov]

Здравствуйте!

On 28.08.2021 02:18, Vitaly Chikunov wrote:
> Hi,
> 
> On Fri, Aug 27, 2021 at 11:43:17PM +0400, Alexey Sheplyakov wrote:
>> Добрый вечер!
>>
>> On 24.08.2021 22:22, Dmitry V. Levin wrote:
>>> On Tue, Aug 24, 2021 at 09:20:50PM +0300, Dmitry V. Levin wrote:
>>>> * 382 пакета перестанут пересобираться с диагностикой следующего вида:
>>>> process-lto: ERROR: ./usr/lib64/libtcb.a: contains __gnu_lto_slim only.
>>>> Perhaps, you need to %define optflags_lto %optflags_lto -ffat-lto-objects
>>
>> Странно это. GCC прекрасно умеет создавать и использовать архивы
>> из thin LTO объектов:
> 
> Нельзя запаковывать GIMPLE в репозиторий, так как он не переносимый
> между версиями GCC. Иначе после каждого обновления GCC пришлось бы
> пересобирать все эти пакеты.

Тогда почему бы не написать об этом прямо, например:

process-lto: ERROR: ./usr/lib64/libfoo.a: contains GIMPLE bytecode only.
Bytecode should NOT be packaged since its format can change between GCC versions.
To package the machine code in static libraries use -ffat-lto-objects option:
%define optflags_lto %optflags_lto -ffat-lto-object
Alternatively you might want to stop packaging static libraries.

А не говорить загадками -- "contains __gnu_lto_slim only".
"Perhaps you need" - а как понять, таки нужно, или не нужно?

Re: [devel] Статические библиотеки и thin LTO

[Dmitry V. Levin]

On Sun, Aug 29, 2021 at 10:34:49AM +0400, Alexey Sheplyakov wrote:
> On 28.08.2021 02:18, Vitaly Chikunov wrote:
> > On Fri, Aug 27, 2021 at 11:43:17PM +0400, Alexey Sheplyakov wrote:
> >> On 24.08.2021 22:22, Dmitry V. Levin wrote:
> >>> On Tue, Aug 24, 2021 at 09:20:50PM +0300, Dmitry V. Levin wrote:
> >>>> * 382 пакета перестанут пересобираться с диагностикой следующего вида:
> >>>> process-lto: ERROR: ./usr/lib64/libtcb.a: contains __gnu_lto_slim only.
> >>>> Perhaps, you need to %define optflags_lto %optflags_lto -ffat-lto-objects
> >>
> >> Странно это. GCC прекрасно умеет создавать и использовать архивы
> >> из thin LTO объектов:
> > 
> > Нельзя запаковывать GIMPLE в репозиторий, так как он не переносимый
> > между версиями GCC. Иначе после каждого обновления GCC пришлось бы
> > пересобирать все эти пакеты.
> 
> Тогда почему бы не написать об этом прямо, например:
> 
> process-lto: ERROR: ./usr/lib64/libfoo.a: contains GIMPLE bytecode only.
> Bytecode should NOT be packaged since its format can change between GCC versions.
> To package the machine code in static libraries use -ffat-lto-objects option:
> %define optflags_lto %optflags_lto -ffat-lto-object
> Alternatively you might want to stop packaging static libraries.
> 
> А не говорить загадками -- "contains __gnu_lto_slim only".
> "Perhaps you need" - а как понять, таки нужно, или не нужно?

Предлагаю компромиссный вариант: в диагностике написать короткую формально
корректную фразу для скриптов, которая будет меняться редко, после которой
длинный текст для людей с описанием, которое может меняться чаще.
Например, так:

process-lto: ERROR: ./usr/lib64/libfoo.a: contains __gnu_lto_slim
Most likely this file contains GIMPLE bytecode that should NOT be packaged
since its format can change between GCC versions.
Use -ffat-lto-objects option to package machine code in static libraries, e.g.
%{?optflags_lto:%global optflags_lto %optflags_lto -ffat-lto-objects}
Alternatively, you might want to stop packaging static libraries.


-- 
ldv

Re: [devel] Статические библиотеки и thin LTO

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 2822 bytes --]

On Mon, 30 Aug 2021 12:18:18 +0300 Dmitry V. Levin wrote:
> On Sun, Aug 29, 2021 at 10:34:49AM +0400, Alexey Sheplyakov wrote:
> > On 28.08.2021 02:18, Vitaly Chikunov wrote:
> > > On Fri, Aug 27, 2021 at 11:43:17PM +0400, Alexey Sheplyakov wrote:
> > >> On 24.08.2021 22:22, Dmitry V. Levin wrote:
> > >>> On Tue, Aug 24, 2021 at 09:20:50PM +0300, Dmitry V. Levin wrote:
> > >>>> * 382 пакета перестанут пересобираться с диагностикой следующего вида:
> > >>>> process-lto: ERROR: ./usr/lib64/libtcb.a: contains __gnu_lto_slim only.
> > >>>> Perhaps, you need to %define optflags_lto %optflags_lto -ffat-lto-objects
> > >>
> > >> Странно это. GCC прекрасно умеет создавать и использовать архивы
> > >> из thin LTO объектов:
> > > 
> > > Нельзя запаковывать GIMPLE в репозиторий, так как он не переносимый
> > > между версиями GCC. Иначе после каждого обновления GCC пришлось бы
> > > пересобирать все эти пакеты.
> > 
> > Тогда почему бы не написать об этом прямо, например:
> > 
> > process-lto: ERROR: ./usr/lib64/libfoo.a: contains GIMPLE bytecode only.
> > Bytecode should NOT be packaged since its format can change between GCC versions.
> > To package the machine code in static libraries use -ffat-lto-objects option:
> > %define optflags_lto %optflags_lto -ffat-lto-object
> > Alternatively you might want to stop packaging static libraries.
> > 
> > А не говорить загадками -- "contains __gnu_lto_slim only".
> > "Perhaps you need" - а как понять, таки нужно, или не нужно?
> 
> Предлагаю компромиссный вариант: в диагностике написать короткую формально
> корректную фразу для скриптов, которая будет меняться редко, после которой
> длинный текст для людей с описанием, которое может меняться чаще.
> Например, так:
> 
> process-lto: ERROR: ./usr/lib64/libfoo.a: contains __gnu_lto_slim
> Most likely this file contains GIMPLE bytecode that should NOT be packaged
> since its format can change between GCC versions.
> Use -ffat-lto-objects option to package machine code in static libraries, e.g.
> %{?optflags_lto:%global optflags_lto %optflags_lto -ffat-lto-objects}
> Alternatively, you might want to stop packaging static libraries.

s/to stop packaging static libraries/to disable LTO for this package/

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] Статические библиотеки и thin LTO

[Dmitry V. Levin]

On Mon, Aug 30, 2021 at 12:30:00PM +0300, Andrey Savchenko wrote:
> On Mon, 30 Aug 2021 12:18:18 +0300 Dmitry V. Levin wrote:
> > On Sun, Aug 29, 2021 at 10:34:49AM +0400, Alexey Sheplyakov wrote:
[...]
> > > Тогда почему бы не написать об этом прямо, например:
> > > 
> > > process-lto: ERROR: ./usr/lib64/libfoo.a: contains GIMPLE bytecode only.
> > > Bytecode should NOT be packaged since its format can change between GCC versions.
> > > To package the machine code in static libraries use -ffat-lto-objects option:
> > > %define optflags_lto %optflags_lto -ffat-lto-object
> > > Alternatively you might want to stop packaging static libraries.
> > > 
> > > А не говорить загадками -- "contains __gnu_lto_slim only".
> > > "Perhaps you need" - а как понять, таки нужно, или не нужно?
> > 
> > Предлагаю компромиссный вариант: в диагностике написать короткую формально
> > корректную фразу для скриптов, которая будет меняться редко, после которой
> > длинный текст для людей с описанием, которое может меняться чаще.
> > Например, так:
> > 
> > process-lto: ERROR: ./usr/lib64/libfoo.a: contains __gnu_lto_slim
> > Most likely this file contains GIMPLE bytecode that should NOT be packaged
> > since its format can change between GCC versions.
> > Use -ffat-lto-objects option to package machine code in static libraries, e.g.
> > %{?optflags_lto:%global optflags_lto %optflags_lto -ffat-lto-objects}
> > Alternatively, you might want to stop packaging static libraries.
> 
> s/to stop packaging static libraries/to disable LTO for this package/

Или обе альтернативы, например:
Alternatively, you might want to stop packaging static libraries
or disable link-time optimization for this package.


-- 
ldv

Re: [devel] Статические библиотеки и thin LTO

[Arseny Maslennikov]

[-- Attachment #1: Type: text/plain, Size: 3323 bytes --]

On Mon, Aug 30, 2021 at 12:18:18PM +0300, Dmitry V. Levin wrote:
> On Sun, Aug 29, 2021 at 10:34:49AM +0400, Alexey Sheplyakov wrote:
> > On 28.08.2021 02:18, Vitaly Chikunov wrote:
> > > On Fri, Aug 27, 2021 at 11:43:17PM +0400, Alexey Sheplyakov wrote:
> > >> On 24.08.2021 22:22, Dmitry V. Levin wrote:
> > >>> On Tue, Aug 24, 2021 at 09:20:50PM +0300, Dmitry V. Levin wrote:
> > >>>> * 382 пакета перестанут пересобираться с диагностикой следующего вида:
> > >>>> process-lto: ERROR: ./usr/lib64/libtcb.a: contains __gnu_lto_slim only.
> > >>>> Perhaps, you need to %define optflags_lto %optflags_lto -ffat-lto-objects
> > >>
> > >> Странно это. GCC прекрасно умеет создавать и использовать архивы
> > >> из thin LTO объектов:
> > > 
> > > Нельзя запаковывать GIMPLE в репозиторий, так как он не переносимый
> > > между версиями GCC. Иначе после каждого обновления GCC пришлось бы
> > > пересобирать все эти пакеты.
> > 
> > Тогда почему бы не написать об этом прямо, например:
> > 
> > process-lto: ERROR: ./usr/lib64/libfoo.a: contains GIMPLE bytecode only.
> > Bytecode should NOT be packaged since its format can change between GCC versions.
> > To package the machine code in static libraries use -ffat-lto-objects option:
> > %define optflags_lto %optflags_lto -ffat-lto-object
> > Alternatively you might want to stop packaging static libraries.
> > 
> > А не говорить загадками -- "contains __gnu_lto_slim only".
> > "Perhaps you need" - а как понять, таки нужно, или не нужно?
> 
> Предлагаю компромиссный вариант: в диагностике написать короткую формально
> корректную фразу для скриптов, которая будет меняться редко, после которой
> длинный текст для людей с описанием, которое может меняться чаще.

Логично.
Не лучше ли к каждой строчке длинного текста дописать, какой компонент
его породил, как и к формальному сообщению? И вообще взять за правило
приписывать префикс к выводу.
Например, так:

> process-lto: ERROR: ./usr/lib64/libfoo.a: contains __gnu_lto_slim
> process-lto:   Most likely this file contains GIMPLE bytecode that should NOT be packaged
> process-lto:   since its format can change between GCC versions.
> process-lto:   Use -ffat-lto-objects option to package machine code in static libraries, e.g.
> process-lto:   %{?optflags_lto:%global optflags_lto %optflags_lto -ffat-lto-objects}
> process-lto:   Alternatively, you might want to stop packaging static libraries.

Сборочный лог является продуктом более десятка компонентов, читателю
будет удобнее пропускать ненужное.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] Статические библиотеки и thin LTO

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 2229 bytes --]

On Mon, 30 Aug 2021 12:39:54 +0300 Dmitry V. Levin wrote:
> On Mon, Aug 30, 2021 at 12:30:00PM +0300, Andrey Savchenko wrote:
> > On Mon, 30 Aug 2021 12:18:18 +0300 Dmitry V. Levin wrote:
> > > On Sun, Aug 29, 2021 at 10:34:49AM +0400, Alexey Sheplyakov wrote:
> [...]
> > > > Тогда почему бы не написать об этом прямо, например:
> > > > 
> > > > process-lto: ERROR: ./usr/lib64/libfoo.a: contains GIMPLE bytecode only.
> > > > Bytecode should NOT be packaged since its format can change between GCC versions.
> > > > To package the machine code in static libraries use -ffat-lto-objects option:
> > > > %define optflags_lto %optflags_lto -ffat-lto-object
> > > > Alternatively you might want to stop packaging static libraries.
> > > > 
> > > > А не говорить загадками -- "contains __gnu_lto_slim only".
> > > > "Perhaps you need" - а как понять, таки нужно, или не нужно?
> > > 
> > > Предлагаю компромиссный вариант: в диагностике написать короткую формально
> > > корректную фразу для скриптов, которая будет меняться редко, после которой
> > > длинный текст для людей с описанием, которое может меняться чаще.
> > > Например, так:
> > > 
> > > process-lto: ERROR: ./usr/lib64/libfoo.a: contains __gnu_lto_slim
> > > Most likely this file contains GIMPLE bytecode that should NOT be packaged
> > > since its format can change between GCC versions.
> > > Use -ffat-lto-objects option to package machine code in static libraries, e.g.
> > > %{?optflags_lto:%global optflags_lto %optflags_lto -ffat-lto-objects}
> > > Alternatively, you might want to stop packaging static libraries.
> > 
> > s/to stop packaging static libraries/to disable LTO for this package/
> 
> Или обе альтернативы, например:
> Alternatively, you might want to stop packaging static libraries
> or disable link-time optimization for this package.

Да, так лучше.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

[devel] debugedit DWARF version 0

[Denis Medvedev]

Добрый день всем!
Как вот с этим бороться и отчего такое бывает?
x86_64

/usr/lib/rpm/debugedit: ./usr/lib/ruby/gems/2.5.0/extensions/x86_64-linux/2.5.0/eventmachine-1.2.7/fastfilereaderext.so:
DWARF version 0 unhandled Failed to update file: invalid section
alignment

Re: [devel] debugedit DWARF version 0

[Denis Medvedev]

В Wed, 13 Oct 2021 12:51:53 +0300
"Dmitry V. Levin" <ldv@altlinux.org> пишет:

> On Wed, Oct 13, 2021 at 12:16:15PM +0300, Denis Medvedev wrote:
> > Добрый день всем!
> > Как вот с этим бороться и отчего такое бывает?
> > x86_64
> > 
> > /usr/lib/rpm/debugedit: ./usr/lib/ruby/gems/2.5.0/extensions/x86_64-linux/2.5.0/eventmachine-1.2.7/fastfilereaderext.so:
> > DWARF version 0 unhandled Failed to update file: invalid section
> > alignment  
> 
> $ rpmquery -f /usr/lib/rpm/debugedit
> error: file /usr/lib/rpm/debugedit: No such file or directory
> 
> В rpm-build >= 4.0.4-alt167 такого файла нет.  Это не Сизиф?
> 

Это не сизиф.

Re: [devel] debugedit DWARF version 0

[Dmitry V. Levin]

On Wed, Oct 13, 2021 at 12:16:15PM +0300, Denis Medvedev wrote:
> Добрый день всем!
> Как вот с этим бороться и отчего такое бывает?
> x86_64
> 
> /usr/lib/rpm/debugedit: ./usr/lib/ruby/gems/2.5.0/extensions/x86_64-linux/2.5.0/eventmachine-1.2.7/fastfilereaderext.so:
> DWARF version 0 unhandled Failed to update file: invalid section alignment

$ rpmquery -f /usr/lib/rpm/debugedit
error: file /usr/lib/rpm/debugedit: No such file or directory

В rpm-build >= 4.0.4-alt167 такого файла нет.  Это не Сизиф?


-- 
ldv