* Re: [devel] I: LTO in %optflags by default
2021-08-24 18:20 [devel] I: LTO in %optflags by default Dmitry V. Levin
@ 2021-08-24 18:21 ` Dmitry V. Levin
2021-08-24 18:22 ` Dmitry V. Levin
` (7 subsequent siblings)
8 siblings, 0 replies; 75+ messages in thread
From: Dmitry V. Levin @ 2021-08-24 18:21 UTC (permalink / raw)
To: devel
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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-24 18:20 [devel] I: LTO in %optflags by default Dmitry V. Levin
2021-08-24 18:21 ` Dmitry V. Levin
@ 2021-08-24 18:22 ` Dmitry V. Levin
2021-08-25 0:04 ` Dmitry V. Levin
2021-08-27 19:43 ` [devel] Статические библиотеки и thin LTO (Was: I: LTO in %optflags by default) Alexey Sheplyakov
2021-08-24 18:23 ` [devel] I: LTO in %optflags by default Dmitry V. Levin
` (6 subsequent siblings)
8 siblings, 2 replies; 75+ messages in thread
From: Dmitry V. Levin @ 2021-08-24 18:22 UTC (permalink / raw)
To: devel
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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-24 18:22 ` Dmitry V. Levin
@ 2021-08-25 0:04 ` Dmitry V. Levin
2021-08-25 8:18 ` Vitaly Lipatov
2021-08-27 19:43 ` [devel] Статические библиотеки и thin LTO (Was: I: LTO in %optflags by default) Alexey Sheplyakov
1 sibling, 1 reply; 75+ messages in thread
From: Dmitry V. Levin @ 2021-08-25 0:04 UTC (permalink / raw)
To: devel
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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-25 0:04 ` Dmitry V. Levin
@ 2021-08-25 8:18 ` Vitaly Lipatov
2021-08-25 8:28 ` Ivan A. Melnikov
0 siblings, 1 reply; 75+ messages in thread
From: Vitaly Lipatov @ 2021-08-25 8:18 UTC (permalink / raw)
To: ALT Linux Team development discussions
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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-25 8:18 ` Vitaly Lipatov
@ 2021-08-25 8:28 ` Ivan A. Melnikov
2021-08-25 8:38 ` Vitaly Lipatov
0 siblings, 1 reply; 75+ messages in thread
From: Ivan A. Melnikov @ 2021-08-25 8:28 UTC (permalink / raw)
To: ALT Linux Team development discussions
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.
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-25 8:28 ` Ivan A. Melnikov
@ 2021-08-25 8:38 ` Vitaly Lipatov
2021-08-25 9:18 ` Andrey Savchenko
0 siblings, 1 reply; 75+ messages in thread
From: Vitaly Lipatov @ 2021-08-25 8:38 UTC (permalink / raw)
To: ALT Linux Team development discussions
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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-25 8:38 ` Vitaly Lipatov
@ 2021-08-25 9:18 ` Andrey Savchenko
2021-08-25 17:14 ` [devel] devel-static Dmitry V. Levin
0 siblings, 1 reply; 75+ messages in thread
From: Andrey Savchenko @ 2021-08-25 9:18 UTC (permalink / raw)
To: ALT Linux Team development discussions
[-- 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 --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] devel-static
2021-08-25 9:18 ` Andrey Savchenko
@ 2021-08-25 17:14 ` Dmitry V. Levin
2021-08-25 17:25 ` Alexey Sheplyakov
2021-08-25 19:14 ` Andrey Savchenko
0 siblings, 2 replies; 75+ messages in thread
From: Dmitry V. Levin @ 2021-08-25 17:14 UTC (permalink / raw)
To: devel
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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] devel-static
2021-08-25 17:14 ` [devel] devel-static Dmitry V. Levin
@ 2021-08-25 17:25 ` Alexey Sheplyakov
2021-08-25 19:19 ` Andrey Savchenko
2021-08-25 19:14 ` Andrey Savchenko
1 sibling, 1 reply; 75+ messages in thread
From: Alexey Sheplyakov @ 2021-08-25 17:25 UTC (permalink / raw)
To: devel
On 25.08.2021 21:14, Dmitry V. Levin wrote:
>> А почему не наоборот?
>>
>> Динамическая линковка лишь создаёт иллюзию безопасности за счёт
>> исправления проблемы в одной библиотеке сразу для всех. Но проблема
>> может быть в хедерах, а C++ библиотеки всё больше переходят
>> в хедеры. В итоге может получится, что CVE исправлен, библиотека
>> обновлена без изменения ABI, а непересобранные приложения всё ещё
>> уязвимы.
>
> А безопаснее всего публиковать только исходники, и пусть пользователи
> сами пересобирают, как сочтут нужным, правда же?
>
Вы, Дмитрий, можете сколько угодно оскорблять людей, но C++ шаблоны
всё равно останутся устроены так, как они устроены.
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] devel-static
2021-08-25 17:25 ` Alexey Sheplyakov
@ 2021-08-25 19:19 ` Andrey Savchenko
0 siblings, 0 replies; 75+ messages in thread
From: Andrey Savchenko @ 2021-08-25 19:19 UTC (permalink / raw)
To: ALT Linux Team development discussions
[-- 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 --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] devel-static
2021-08-25 17:14 ` [devel] devel-static Dmitry V. Levin
2021-08-25 17:25 ` Alexey Sheplyakov
@ 2021-08-25 19:14 ` Andrey Savchenko
2021-08-25 19:58 ` Vitaly Lipatov
1 sibling, 1 reply; 75+ messages in thread
From: Andrey Savchenko @ 2021-08-25 19:14 UTC (permalink / raw)
To: ALT Linux Team development discussions
[-- 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 --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] devel-static
2021-08-25 19:14 ` Andrey Savchenko
@ 2021-08-25 19:58 ` Vitaly Lipatov
2021-08-25 20:52 ` Andrey Savchenko
0 siblings, 1 reply; 75+ messages in thread
From: Vitaly Lipatov @ 2021-08-25 19:58 UTC (permalink / raw)
To: ALT Linux Team development discussions
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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] devel-static
2021-08-25 19:58 ` Vitaly Lipatov
@ 2021-08-25 20:52 ` Andrey Savchenko
2021-08-25 21:06 ` Vitaly Lipatov
0 siblings, 1 reply; 75+ messages in thread
From: Andrey Savchenko @ 2021-08-25 20:52 UTC (permalink / raw)
To: ALT Linux Team development discussions
[-- 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 --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] devel-static
2021-08-25 20:52 ` Andrey Savchenko
@ 2021-08-25 21:06 ` Vitaly Lipatov
2021-08-25 21:36 ` Andrey Savchenko
0 siblings, 1 reply; 75+ messages in thread
From: Vitaly Lipatov @ 2021-08-25 21:06 UTC (permalink / raw)
To: ALT Linux Team development discussions
Andrey Savchenko писал 25.8.21 23:52:
> On Wed, 25 Aug 2021 22:58:03 +0300 Vitaly Lipatov wrote:
...
> Некоторые апстримы ушли по-умолчанию целиком в хедеры и отдельно не
> выделяют такие ситуации, например, cgal.
Безусловно, нужно отмечать такие пакеты, и при их изменении пересобирать
всё, что от них зависит. Иначе смысла в их изменении нет :)
Сейчас это могут делать и делают мантейнеры вручную (через rebuild
зависящих по сборке пакетов), но вполне возможно, что когда-нибудь в
сборочницу будет добавлена такая проверка и проверка будет выполняться
автоматически.
>> Также, как я понимаю, достаточно сложно создать уязвимость именно в
>> том
>> коде, который генерируется при сборке приложения, а не библиотеки.
>> Разве
>> известны такие случаи?
>
> Я отдельно не искал. Но почему ошибка в реализации шаблона
> представляется невероятной?
Представляется очень маловероятной. Потенциальная проблема может
возникнуть у нескольких пакетов среди десятков тысяч в репозитории,
поэтому особо никого не волнует — в смысле никто не готов ради этого
переходить на статику, например.
--
С уважением,
Виталий Липатов,
ALT Linux Team
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] devel-static
2021-08-25 21:06 ` Vitaly Lipatov
@ 2021-08-25 21:36 ` Andrey Savchenko
0 siblings, 0 replies; 75+ messages in thread
From: Andrey Savchenko @ 2021-08-25 21:36 UTC (permalink / raw)
To: ALT Linux Team development discussions
[-- 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 --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* [devel] Статические библиотеки и thin LTO (Was: I: LTO in %optflags by default)
2021-08-24 18:22 ` Dmitry V. Levin
2021-08-25 0:04 ` Dmitry V. Levin
@ 2021-08-27 19:43 ` Alexey Sheplyakov
2021-08-27 22:18 ` [devel] Статические библиотеки и thin LTO Vitaly Chikunov
1 sibling, 1 reply; 75+ messages in thread
From: Alexey Sheplyakov @ 2021-08-27 19:43 UTC (permalink / raw)
To: devel
Добрый вечер!
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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] Статические библиотеки и thin LTO
2021-08-27 19:43 ` [devel] Статические библиотеки и thin LTO (Was: I: LTO in %optflags by default) Alexey Sheplyakov
@ 2021-08-27 22:18 ` Vitaly Chikunov
2021-08-29 6:34 ` Alexey Sheplyakov
0 siblings, 1 reply; 75+ messages in thread
From: Vitaly Chikunov @ 2021-08-27 22:18 UTC (permalink / raw)
To: ALT Linux Team development discussions
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)
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] Статические библиотеки и thin LTO
2021-08-27 22:18 ` [devel] Статические библиотеки и thin LTO Vitaly Chikunov
@ 2021-08-29 6:34 ` Alexey Sheplyakov
2021-08-30 9:18 ` Dmitry V. Levin
0 siblings, 1 reply; 75+ messages in thread
From: Alexey Sheplyakov @ 2021-08-29 6:34 UTC (permalink / raw)
To: devel
Здравствуйте!
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" - а как понять, таки нужно, или не нужно?
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] Статические библиотеки и thin LTO
2021-08-29 6:34 ` Alexey Sheplyakov
@ 2021-08-30 9:18 ` Dmitry V. Levin
2021-08-30 9:30 ` Andrey Savchenko
2021-08-30 9:50 ` Arseny Maslennikov
0 siblings, 2 replies; 75+ messages in thread
From: Dmitry V. Levin @ 2021-08-30 9:18 UTC (permalink / raw)
To: devel
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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] Статические библиотеки и thin LTO
2021-08-30 9:18 ` Dmitry V. Levin
@ 2021-08-30 9:30 ` Andrey Savchenko
2021-08-30 9:39 ` Dmitry V. Levin
2021-08-30 9:50 ` Arseny Maslennikov
1 sibling, 1 reply; 75+ messages in thread
From: Andrey Savchenko @ 2021-08-30 9:30 UTC (permalink / raw)
To: ALT Linux Team development discussions
[-- 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 --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] Статические библиотеки и thin LTO
2021-08-30 9:30 ` Andrey Savchenko
@ 2021-08-30 9:39 ` Dmitry V. Levin
2021-08-30 14:36 ` Andrey Savchenko
0 siblings, 1 reply; 75+ messages in thread
From: Dmitry V. Levin @ 2021-08-30 9:39 UTC (permalink / raw)
To: devel
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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] Статические библиотеки и thin LTO
2021-08-30 9:39 ` Dmitry V. Levin
@ 2021-08-30 14:36 ` Andrey Savchenko
0 siblings, 0 replies; 75+ messages in thread
From: Andrey Savchenko @ 2021-08-30 14:36 UTC (permalink / raw)
To: ALT Linux Team development discussions
[-- 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 --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] Статические библиотеки и thin LTO
2021-08-30 9:18 ` Dmitry V. Levin
2021-08-30 9:30 ` Andrey Savchenko
@ 2021-08-30 9:50 ` Arseny Maslennikov
1 sibling, 0 replies; 75+ messages in thread
From: Arseny Maslennikov @ 2021-08-30 9:50 UTC (permalink / raw)
To: ALT Linux Team development discussions
[-- 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 --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-24 18:20 [devel] I: LTO in %optflags by default Dmitry V. Levin
2021-08-24 18:21 ` Dmitry V. Levin
2021-08-24 18:22 ` Dmitry V. Levin
@ 2021-08-24 18:23 ` Dmitry V. Levin
2021-08-24 19:19 ` Dmitry V. Levin
` (5 subsequent siblings)
8 siblings, 0 replies; 75+ messages in thread
From: Dmitry V. Levin @ 2021-08-24 18:23 UTC (permalink / raw)
To: devel
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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-24 18:20 [devel] I: LTO in %optflags by default Dmitry V. Levin
` (2 preceding siblings ...)
2021-08-24 18:23 ` [devel] I: LTO in %optflags by default Dmitry V. Levin
@ 2021-08-24 19:19 ` Dmitry V. Levin
2021-08-25 0:33 ` Dmitry V. Levin
2021-08-25 5:27 ` [devel] I: LTO in %optflags by default Ivan A. Melnikov
` (4 subsequent siblings)
8 siblings, 1 reply; 75+ messages in thread
From: Dmitry V. Levin @ 2021-08-24 19:19 UTC (permalink / raw)
To: devel
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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-24 19:19 ` Dmitry V. Levin
@ 2021-08-25 0:33 ` Dmitry V. Levin
2021-08-26 6:00 ` [devel] I: LTO in %optflags by defaulta (top-level asm) Vitaly Chikunov
0 siblings, 1 reply; 75+ messages in thread
From: Dmitry V. Levin @ 2021-08-25 0:33 UTC (permalink / raw)
To: devel
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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by defaulta (top-level asm)
2021-08-25 0:33 ` Dmitry V. Levin
@ 2021-08-26 6:00 ` Vitaly Chikunov
0 siblings, 0 replies; 75+ messages in thread
From: Vitaly Chikunov @ 2021-08-26 6:00 UTC (permalink / raw)
To: ALT Linux Team development discussions
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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-24 18:20 [devel] I: LTO in %optflags by default Dmitry V. Levin
` (3 preceding siblings ...)
2021-08-24 19:19 ` Dmitry V. Levin
@ 2021-08-25 5:27 ` Ivan A. Melnikov
2021-08-25 5:46 ` Denis Medvedev
2021-08-25 17:48 ` Dmitry V. Levin
2021-08-25 7:37 ` Alexey Sheplyakov
` (3 subsequent siblings)
8 siblings, 2 replies; 75+ messages in thread
From: Ivan A. Melnikov @ 2021-08-25 5:27 UTC (permalink / raw)
To: ALT Linux Team development discussions
On Tue, Aug 24, 2021 at 09:20:50PM +0300, Dmitry V. Levin wrote:
> Hi,
>
> Пришло время включить в Сизифе LTO (link-time optimization).
> К сожалению, ещё не все пакеты собираются с этой оптимизацией,
> некоторые предстоит исправить.
Скажите, а как это влияет на время сборки пакетов?
Это тестировалось только на основных архитектурах? На всех?
--
wbr,
iv m.
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-25 5:27 ` [devel] I: LTO in %optflags by default Ivan A. Melnikov
@ 2021-08-25 5:46 ` Denis Medvedev
2021-08-25 5:50 ` Denis Medvedev
` (3 more replies)
2021-08-25 17:48 ` Dmitry V. Levin
1 sibling, 4 replies; 75+ messages in thread
From: Denis Medvedev @ 2021-08-25 5:46 UTC (permalink / raw)
To: devel
В 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
readonly (E.g. the GOT).
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-25 5:46 ` Denis Medvedev
@ 2021-08-25 5:50 ` Denis Medvedev
2021-08-25 6:53 ` Andrey Savchenko
` (2 subsequent siblings)
3 siblings, 0 replies; 75+ messages in thread
From: Denis Medvedev @ 2021-08-25 5:50 UTC (permalink / raw)
To: devel
В 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
> readonly (E.g. the GOT).
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-25 5:46 ` Denis Medvedev
2021-08-25 5:50 ` Denis Medvedev
@ 2021-08-25 6:53 ` Andrey Savchenko
2021-08-25 7:03 ` Denis Medvedev
` (2 more replies)
2021-08-25 7:12 ` Alexey Sheplyakov
2021-08-25 16:28 ` Dmitry V. Levin
3 siblings, 3 replies; 75+ messages in thread
From: Andrey Savchenko @ 2021-08-25 6:53 UTC (permalink / raw)
To: ALT Linux Team development discussions
[-- 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
> readonly (E.g. the GOT).
С точки зрения безопасности это хорошо, а вот тормоза даёт дикие,
особенно на тяжёлых приложениях типа LO. Возможно, в этом есть смысл
в специальных ветках, но в Сизиф такое не нужно тянуть.
Best regards,
Andrew Savchenko
[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-25 6:53 ` Andrey Savchenko
@ 2021-08-25 7:03 ` Denis Medvedev
2021-08-25 7:32 ` Andrey Savchenko
2021-08-26 18:43 ` Michael Shigorin
2021-08-25 7:12 ` Ivan A. Melnikov
2021-08-25 8:14 ` Alexey Tourbin
2 siblings, 2 replies; 75+ messages in thread
From: Denis Medvedev @ 2021-08-25 7:03 UTC (permalink / raw)
To: devel
В 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
> > readonly (E.g. the GOT).
>
> С точки зрения безопасности это хорошо, а вот тормоза даёт дикие,
> особенно на тяжёлых приложениях типа LO. Возможно, в этом есть смысл
> в специальных ветках, но в Сизиф такое не нужно тянуть.
В таком случае как мне правильно сделать дефолты для особых веток?
Сделать свою версию какого пакета?
>
> Best regards,
> Andrew Savchenko
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-25 7:03 ` Denis Medvedev
@ 2021-08-25 7:32 ` Andrey Savchenko
2021-08-26 18:43 ` Michael Shigorin
1 sibling, 0 replies; 75+ messages in thread
From: Andrey Savchenko @ 2021-08-25 7:32 UTC (permalink / raw)
To: ALT Linux Team development discussions
[-- 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
> > > readonly (E.g. the GOT).
> >
> > С точки зрения безопасности это хорошо, а вот тормоза даёт дикие,
> > особенно на тяжёлых приложениях типа LO. Возможно, в этом есть смысл
> > в специальных ветках, но в Сизиф такое не нужно тянуть.
> В таком случае как мне правильно сделать дефолты для особых веток?
> Сделать свою версию какого пакета?
rpmbuild, нужно править макрос(ы) %optflags_* в platform.in; думаю,
%optflags_default должно хватить.
Best regards,
Andrew Savchenko
[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-25 7:03 ` Denis Medvedev
2021-08-25 7:32 ` Andrey Savchenko
@ 2021-08-26 18:43 ` Michael Shigorin
1 sibling, 0 replies; 75+ messages in thread
From: Michael Shigorin @ 2021-08-26 18:43 UTC (permalink / raw)
To: devel
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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-25 6:53 ` Andrey Savchenko
2021-08-25 7:03 ` Denis Medvedev
@ 2021-08-25 7:12 ` Ivan A. Melnikov
2021-08-25 8:14 ` Alexey Tourbin
2 siblings, 0 replies; 75+ messages in thread
From: Ivan A. Melnikov @ 2021-08-25 7:12 UTC (permalink / raw)
To: ALT Linux Team development discussions
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.
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-25 6:53 ` Andrey Savchenko
2021-08-25 7:03 ` Denis Medvedev
2021-08-25 7:12 ` Ivan A. Melnikov
@ 2021-08-25 8:14 ` Alexey Tourbin
2021-08-25 8:39 ` Andrey Savchenko
2 siblings, 1 reply; 75+ messages in thread
From: Alexey Tourbin @ 2021-08-25 8:14 UTC (permalink / raw)
To: ALT Linux Team development discussions
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
> > readonly (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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-25 8:14 ` Alexey Tourbin
@ 2021-08-25 8:39 ` Andrey Savchenko
0 siblings, 0 replies; 75+ messages in thread
From: Andrey Savchenko @ 2021-08-25 8:39 UTC (permalink / raw)
To: ALT Linux Team development discussions
[-- 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
> > > readonly (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 --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-25 5:46 ` Denis Medvedev
2021-08-25 5:50 ` Denis Medvedev
2021-08-25 6:53 ` Andrey Savchenko
@ 2021-08-25 7:12 ` Alexey Sheplyakov
2021-08-25 16:28 ` Dmitry V. Levin
3 siblings, 0 replies; 75+ messages in thread
From: Alexey Sheplyakov @ 2021-08-25 7:12 UTC (permalink / raw)
To: devel
Добрый день!
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 более безопасным.
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-25 5:46 ` Denis Medvedev
` (2 preceding siblings ...)
2021-08-25 7:12 ` Alexey Sheplyakov
@ 2021-08-25 16:28 ` Dmitry V. Levin
3 siblings, 0 replies; 75+ messages in thread
From: Dmitry V. Levin @ 2021-08-25 16:28 UTC (permalink / raw)
To: devel
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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-25 5:27 ` [devel] I: LTO in %optflags by default Ivan A. Melnikov
2021-08-25 5:46 ` Denis Medvedev
@ 2021-08-25 17:48 ` Dmitry V. Levin
1 sibling, 0 replies; 75+ messages in thread
From: Dmitry V. Levin @ 2021-08-25 17:48 UTC (permalink / raw)
To: ALT Linux Team development discussions
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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-24 18:20 [devel] I: LTO in %optflags by default Dmitry V. Levin
` (4 preceding siblings ...)
2021-08-25 5:27 ` [devel] I: LTO in %optflags by default Ivan A. Melnikov
@ 2021-08-25 7:37 ` Alexey Sheplyakov
2021-08-25 18:07 ` [devel] Administrivia Dmitry V. Levin
2021-08-25 19:27 ` [devel] I: LTO in %optflags by default Andrey Savchenko
2021-08-25 10:45 ` Vitaly Lipatov
` (2 subsequent siblings)
8 siblings, 2 replies; 75+ messages in thread
From: Alexey Sheplyakov @ 2021-08-25 7:37 UTC (permalink / raw)
To: devel
Здравствуйте!
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
Ничего так списочек, внушает.
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] Administrivia
2021-08-25 7:37 ` Alexey Sheplyakov
@ 2021-08-25 18:07 ` Dmitry V. Levin
2021-08-25 19:25 ` Alexey Sheplyakov
2021-08-25 19:27 ` [devel] I: LTO in %optflags by default Andrey Savchenko
1 sibling, 1 reply; 75+ messages in thread
From: Dmitry V. Levin @ 2021-08-25 18:07 UTC (permalink / raw)
To: devel
[-- 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 --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] Administrivia
2021-08-25 18:07 ` [devel] Administrivia Dmitry V. Levin
@ 2021-08-25 19:25 ` Alexey Sheplyakov
2021-08-25 20:03 ` Alexey V. Vissarionov
0 siblings, 1 reply; 75+ messages in thread
From: Alexey Sheplyakov @ 2021-08-25 19:25 UTC (permalink / raw)
To: devel
On 25.08.2021 22:07, Dmitry V. Levin wrote:
> Эту тему можно было бы обсудить по-существу, если бы вы не написали то,
> что вы написали дальше.
>
>> А "я тут всё сломал, а вы теперь - чините" - это прямое вредительство.
Простите, погорячился. Это я зря. Постараюсь в дальнейшем аккуратнее подбирать формулировки.
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] Administrivia
2021-08-25 19:25 ` Alexey Sheplyakov
@ 2021-08-25 20:03 ` Alexey V. Vissarionov
2021-08-26 19:02 ` [devel] Administrivii Michael Shigorin
0 siblings, 1 reply; 75+ messages in thread
From: Alexey V. Vissarionov @ 2021-08-25 20:03 UTC (permalink / raw)
To: ALT Linux Team development discussions
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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] Administrivii
2021-08-25 20:03 ` Alexey V. Vissarionov
@ 2021-08-26 19:02 ` Michael Shigorin
2021-08-26 19:18 ` [devel] debugedit Dmitry V. Levin
0 siblings, 1 reply; 75+ messages in thread
From: Michael Shigorin @ 2021-08-26 19:02 UTC (permalink / raw)
To: devel
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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] debugedit
2021-08-26 19:02 ` [devel] Administrivii Michael Shigorin
@ 2021-08-26 19:18 ` Dmitry V. Levin
2021-10-13 9:16 ` [devel] debugedit DWARF version 0 Denis Medvedev
0 siblings, 1 reply; 75+ messages in thread
From: Dmitry V. Levin @ 2021-08-26 19:18 UTC (permalink / raw)
To: devel
On Thu, Aug 26, 2021 at 10:02:55PM +0300, Michael Shigorin wrote:
[...]
> Просто для протокола, так-то я Диму люблю не менее всех
> и Виталику за труды благодарен (хотя пока что не понял,
> debugedit в итоге починили или всё так же падает).
На обычных архитектурах debugedit не падает (и вроде бы никогда не падал),
а на e2k тебе виднее.
--
ldv
^ permalink raw reply [flat|nested] 75+ messages in thread
* [devel] debugedit DWARF version 0
2021-08-26 19:18 ` [devel] debugedit Dmitry V. Levin
@ 2021-10-13 9:16 ` Denis Medvedev
2021-10-13 9:51 ` Dmitry V. Levin
0 siblings, 1 reply; 75+ messages in thread
From: Denis Medvedev @ 2021-10-13 9:16 UTC (permalink / raw)
To: ALT Linux Team development discussions
Добрый день всем!
Как вот с этим бороться и отчего такое бывает?
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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] debugedit DWARF version 0
2021-10-13 9:16 ` [devel] debugedit DWARF version 0 Denis Medvedev
@ 2021-10-13 9:51 ` Dmitry V. Levin
2021-10-13 9:51 ` Denis Medvedev
0 siblings, 1 reply; 75+ messages in thread
From: Dmitry V. Levin @ 2021-10-13 9:51 UTC (permalink / raw)
To: ALT Devel discussion list
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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] debugedit DWARF version 0
2021-10-13 9:51 ` Dmitry V. Levin
@ 2021-10-13 9:51 ` Denis Medvedev
0 siblings, 0 replies; 75+ messages in thread
From: Denis Medvedev @ 2021-10-13 9:51 UTC (permalink / raw)
To: Dmitry V. Levin; +Cc: ALT Linux Team development discussions
В 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 такого файла нет. Это не Сизиф?
>
Это не сизиф.
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-25 7:37 ` Alexey Sheplyakov
2021-08-25 18:07 ` [devel] Administrivia Dmitry V. Levin
@ 2021-08-25 19:27 ` Andrey Savchenko
2021-08-25 23:54 ` Dmitry V. Levin
1 sibling, 1 reply; 75+ messages in thread
From: Andrey Savchenko @ 2021-08-25 19:27 UTC (permalink / raw)
To: ALT Linux Team development discussions
[-- 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 --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-25 19:27 ` [devel] I: LTO in %optflags by default Andrey Savchenko
@ 2021-08-25 23:54 ` Dmitry V. Levin
2021-08-26 9:35 ` Alexey V. Vissarionov
2021-08-26 19:33 ` Andrey Savchenko
0 siblings, 2 replies; 75+ messages in thread
From: Dmitry V. Levin @ 2021-08-25 23:54 UTC (permalink / raw)
To: devel
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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-25 23:54 ` Dmitry V. Levin
@ 2021-08-26 9:35 ` Alexey V. Vissarionov
2021-08-26 19:33 ` Andrey Savchenko
1 sibling, 0 replies; 75+ messages in thread
From: Alexey V. Vissarionov @ 2021-08-26 9:35 UTC (permalink / raw)
To: ALT Linux Team development discussions
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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-25 23:54 ` Dmitry V. Levin
2021-08-26 9:35 ` Alexey V. Vissarionov
@ 2021-08-26 19:33 ` Andrey Savchenko
2021-08-27 0:37 ` Dmitry V. Levin
1 sibling, 1 reply; 75+ messages in thread
From: Andrey Savchenko @ 2021-08-26 19:33 UTC (permalink / raw)
To: ALT Linux Team development discussions
[-- 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 --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-26 19:33 ` Andrey Savchenko
@ 2021-08-27 0:37 ` Dmitry V. Levin
2021-08-27 8:07 ` Sergey V Turchin
` (2 more replies)
0 siblings, 3 replies; 75+ messages in thread
From: Dmitry V. Levin @ 2021-08-27 0:37 UTC (permalink / raw)
To: ALT Devel discussion list
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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-27 0:37 ` Dmitry V. Levin
@ 2021-08-27 8:07 ` Sergey V Turchin
2021-08-27 9:11 ` Alexey V. Vissarionov
2021-08-27 10:00 ` Alexey Sheplyakov
2 siblings, 0 replies; 75+ messages in thread
From: Sergey V Turchin @ 2021-08-27 8:07 UTC (permalink / raw)
To: ALT Linux Team development discussions
On Friday, 27 August 2021 03:37:45 MSK Dmitry V wrote:
[...]
> Люди, как правило, не замечают пользы, но замечают дополнительную работу,
> которую приходится делать, пусть даже тривиальную.
> Кроме того, люди хотят, чтобы им всё объяснили и спросили их мнения даже
> тогда, когда выбора по сути нет.
> Такое поведение людей сложно назвать рациональным.
Так, о том и разговор, что как бы кому-то не хотелось, а корректнее всегда
будет попытка улаживать эти 3 вышеуказанных пункта, иначе по факту это лишние
провокации негативного отношения со стороны тех самых "людей".
--
Regards, Sergey.
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-27 0:37 ` Dmitry V. Levin
2021-08-27 8:07 ` Sergey V Turchin
@ 2021-08-27 9:11 ` Alexey V. Vissarionov
2021-08-27 10:00 ` Alexey Sheplyakov
2 siblings, 0 replies; 75+ messages in thread
From: Alexey V. Vissarionov @ 2021-08-27 9:11 UTC (permalink / raw)
To: ALT Linux Team development discussions
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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-27 0:37 ` Dmitry V. Levin
2021-08-27 8:07 ` Sergey V Turchin
2021-08-27 9:11 ` Alexey V. Vissarionov
@ 2021-08-27 10:00 ` Alexey Sheplyakov
2021-08-27 12:54 ` Dmitry V. Levin
2 siblings, 1 reply; 75+ messages in thread
From: Alexey Sheplyakov @ 2021-08-27 10:00 UTC (permalink / raw)
To: devel
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)
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-27 10:00 ` Alexey Sheplyakov
@ 2021-08-27 12:54 ` Dmitry V. Levin
0 siblings, 0 replies; 75+ messages in thread
From: Dmitry V. Levin @ 2021-08-27 12:54 UTC (permalink / raw)
To: ALT Devel discussion list
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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-24 18:20 [devel] I: LTO in %optflags by default Dmitry V. Levin
` (5 preceding siblings ...)
2021-08-25 7:37 ` Alexey Sheplyakov
@ 2021-08-25 10:45 ` Vitaly Lipatov
2021-08-25 16:20 ` Dmitry V. Levin
2021-08-25 21:24 ` Dmitry V. Levin
2021-08-26 0:26 ` Dmitry V. Levin
8 siblings, 1 reply; 75+ messages in thread
From: Vitaly Lipatov @ 2021-08-25 10:45 UTC (permalink / raw)
To: ALT Linux Team development discussions
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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-25 10:45 ` Vitaly Lipatov
@ 2021-08-25 16:20 ` Dmitry V. Levin
2021-08-25 20:23 ` Vitaly Lipatov
0 siblings, 1 reply; 75+ messages in thread
From: Dmitry V. Levin @ 2021-08-25 16:20 UTC (permalink / raw)
To: devel
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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-25 16:20 ` Dmitry V. Levin
@ 2021-08-25 20:23 ` Vitaly Lipatov
2021-08-25 20:30 ` Dmitry V. Levin
0 siblings, 1 reply; 75+ messages in thread
From: Vitaly Lipatov @ 2021-08-25 20:23 UTC (permalink / raw)
To: ALT Linux Team development discussions
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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-25 20:23 ` Vitaly Lipatov
@ 2021-08-25 20:30 ` Dmitry V. Levin
0 siblings, 0 replies; 75+ messages in thread
From: Dmitry V. Levin @ 2021-08-25 20:30 UTC (permalink / raw)
To: ALT Linux Team development discussions
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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-24 18:20 [devel] I: LTO in %optflags by default Dmitry V. Levin
` (6 preceding siblings ...)
2021-08-25 10:45 ` Vitaly Lipatov
@ 2021-08-25 21:24 ` Dmitry V. Levin
2021-08-25 23:07 ` Aleksey Novodvorsky
2021-08-26 0:26 ` Dmitry V. Levin
8 siblings, 1 reply; 75+ messages in thread
From: Dmitry V. Levin @ 2021-08-25 21:24 UTC (permalink / raw)
To: devel
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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-25 21:24 ` Dmitry V. Levin
@ 2021-08-25 23:07 ` Aleksey Novodvorsky
2021-08-25 23:19 ` Dmitry V. Levin
0 siblings, 1 reply; 75+ messages in thread
From: Aleksey Novodvorsky @ 2021-08-25 23:07 UTC (permalink / raw)
To: ALT Linux Team development discussions
чт, 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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-25 23:07 ` Aleksey Novodvorsky
@ 2021-08-25 23:19 ` Dmitry V. Levin
2021-08-25 23:54 ` Andrey Savchenko
2021-08-26 4:23 ` alexei
0 siblings, 2 replies; 75+ messages in thread
From: Dmitry V. Levin @ 2021-08-25 23:19 UTC (permalink / raw)
To: ALT Devel discussion list
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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-25 23:19 ` Dmitry V. Levin
@ 2021-08-25 23:54 ` Andrey Savchenko
2021-08-26 0:04 ` Dmitry V. Levin
2021-08-26 4:23 ` alexei
1 sibling, 1 reply; 75+ messages in thread
From: Andrey Savchenko @ 2021-08-25 23:54 UTC (permalink / raw)
To: ALT Linux Team development discussions
[-- 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 --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-25 23:54 ` Andrey Savchenko
@ 2021-08-26 0:04 ` Dmitry V. Levin
2021-08-26 6:39 ` Andrey Savchenko
2021-08-26 9:40 ` Alexey V. Vissarionov
0 siblings, 2 replies; 75+ messages in thread
From: Dmitry V. Levin @ 2021-08-26 0:04 UTC (permalink / raw)
To: ALT Devel discussion list
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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-26 0:04 ` Dmitry V. Levin
@ 2021-08-26 6:39 ` Andrey Savchenko
2021-08-26 7:25 ` Vitaly Lipatov
2021-08-27 0:20 ` Dmitry V. Levin
2021-08-26 9:40 ` Alexey V. Vissarionov
1 sibling, 2 replies; 75+ messages in thread
From: Andrey Savchenko @ 2021-08-26 6:39 UTC (permalink / raw)
To: ALT Linux Team development discussions
[-- 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 --]
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-26 6:39 ` Andrey Savchenko
@ 2021-08-26 7:25 ` Vitaly Lipatov
2021-08-27 0:20 ` Dmitry V. Levin
1 sibling, 0 replies; 75+ messages in thread
From: Vitaly Lipatov @ 2021-08-26 7:25 UTC (permalink / raw)
To: ALT Linux Team development discussions
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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-26 6:39 ` Andrey Savchenko
2021-08-26 7:25 ` Vitaly Lipatov
@ 2021-08-27 0:20 ` Dmitry V. Levin
1 sibling, 0 replies; 75+ messages in thread
From: Dmitry V. Levin @ 2021-08-27 0:20 UTC (permalink / raw)
To: devel
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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-26 0:04 ` Dmitry V. Levin
2021-08-26 6:39 ` Andrey Savchenko
@ 2021-08-26 9:40 ` Alexey V. Vissarionov
1 sibling, 0 replies; 75+ messages in thread
From: Alexey V. Vissarionov @ 2021-08-26 9:40 UTC (permalink / raw)
To: ALT Linux Team development discussions
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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-25 23:19 ` Dmitry V. Levin
2021-08-25 23:54 ` Andrey Savchenko
@ 2021-08-26 4:23 ` alexei
2021-08-26 8:24 ` Dmitry V. Levin
1 sibling, 1 reply; 75+ messages in thread
From: alexei @ 2021-08-26 4:23 UTC (permalink / raw)
To: ALT Linux Team development discussions
Добрый день!
----- Исходное сообщение -----
> От: "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/ )
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-26 4:23 ` alexei
@ 2021-08-26 8:24 ` Dmitry V. Levin
0 siblings, 0 replies; 75+ messages in thread
From: Dmitry V. Levin @ 2021-08-26 8:24 UTC (permalink / raw)
To: devel
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
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [devel] I: LTO in %optflags by default
2021-08-24 18:20 [devel] I: LTO in %optflags by default Dmitry V. Levin
` (7 preceding siblings ...)
2021-08-25 21:24 ` Dmitry V. Levin
@ 2021-08-26 0:26 ` Dmitry V. Levin
8 siblings, 0 replies; 75+ messages in thread
From: Dmitry V. Levin @ 2021-08-26 0:26 UTC (permalink / raw)
To: devel
On Tue, Aug 24, 2021 at 09:20:50PM +0300, Dmitry V. Levin wrote:
[...]
> * Около 158 пакетов перестанут пересобираться с другой диагностикой,
> связанной с включением LTO. С такими пакетами можно поступить одним из
> нескольких способов:
> - обновить пакеты, весьма вероятно, что они уже исправлены в новых версиях;
> - исправить LTO самостоятельно;
> - выключить LTO, переопределив макрос optflags_lto.
Забыл добавить очевидное: большая часть необходимых исправлений доступна
в репозиториях, где LTO включили раньше нас.
--
ldv
^ permalink raw reply [flat|nested] 75+ messages in thread