11:13 a.m.
Due to an unplanned ABI break that I caused in libstdc++, I will soon
start to rebuild the packages listed below. This rebuild will remove
references to some symbols in libstdc++.so which do not work as
intended, and so will not be present in the final gcc-11.1.0 release.
See https://bugzilla.redhat.com/show_bug.cgi?id=1937698 for reference.
Package maintainers should not need to do anything, but will see a
%release bump and a rebuild.
----------------------------
OpenImageIO
PDAL
SoapySDR
audacious
audacity
blender
boost
botan2
ceph
chromium
clang
cockatrice
community-mysql
cpprest
date
davix
deepin-file-manager
deepin-image-viewer
dolphin-emu
domoticz
dotnet3.1
doxygen
dyninst
et
fawkes
firefox
fish
folly
freecad
freeopcua
gazebo
gdb
gnome-sudoku
gnuradio
godot
heaptrack
hidviz
hpx
icecat
icu
insight
julia
kdevelop-php
kernelshark
kf5-kio
kicad
kio-extras
kismet
libarcus
libarcus-lulzbot
libdigidocpp
libixion
libmodsecurity
libomp
librealsense
libreoffice
librime
lld
lldb
llvm
llvm7.0
lnav
log4cplus
logiops
luxcorerender
mame
mapnik
mariadb
mingw-llvm
mir
mlir
mmapper
movit
mozc
mozjs78
mypaint
mysql-connector-odbc
nghttp2
nodejs
oidn
ompl
onednn
opencv
openshadinglanguage
openvdb
osm2pgsql
osmium-tool
paraview
parzip
pdns
poedit
polly
poppler
primesieve
protobuf
protobuf-c
proxysql
prusa-slicer
pulseeffects
pyosmium
python-pynest2d
qgis
qmasterpassword
qpid-proton
qt-creator
qt5-qtlocation
qt5-qtwebengine
qt5-qtwebkit
qtcurve
rdkit
re2
rlottie
root
rstudio
scipy
seqan2
spirv-llvm-translator
sqlitebrowser
srt
supercollider
swift-lang
thunderbird
tkrzw
uhd
usbguard
vapoursynth
vigra
warzone2100
watchman
webextension-token-signing
webkit2gtk3
wesnoth
worker
wsjtx
xrdcl-http
xrootd
yacreader
zimlib
zynaddsubfx
5:24 p.m.
Hi,
Jonathan Wakely <jwakely(a)fedoraproject.org> writes:
Due to an unplanned ABI break that I caused in libstdc++, I will
soon
start to rebuild the packages listed below. This rebuild will remove
references to some symbols in libstdc++.so which do not work as
intended, and so will not be present in the final gcc-11.1.0 release.
See https://bugzilla.redhat.com/show_bug.cgi?id=1937698 for reference.
Package maintainers should not need to do anything, but will see a
%release bump and a rebuild.
dotnet3.1
I am bit surprised that dotnet3.1 is in that list but not dotnet5.0.
Is there some way I can confirm whether a package (like dotnet5.0) is
affected or not?
Thanks,
Omair
--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108 E7BD DF99 7AF8 B157 A9F0
4:41 a.m.
On 30/03/21 18:24 -0400, Omair Majid wrote:
Hi,
Jonathan Wakely <jwakely(a)fedoraproject.org> writes:
> Due to an unplanned ABI break that I caused in libstdc++, I will soon
> start to rebuild the packages listed below. This rebuild will remove
> references to some symbols in libstdc++.so which do not work as
> intended, and so will not be present in the final gcc-11.1.0 release.
>
> See https://bugzilla.redhat.com/show_bug.cgi?id=1937698 for reference.
>
> Package maintainers should not need to do anything, but will see a
> %release bump and a rebuild.
> dotnet3.1
I am bit surprised that dotnet3.1 is in that list but not dotnet5.0.
If that's a new-ish package it might not be present in Florian's
database of packages that he searched for uses of the bad symbols.
Another possibility is that it wasn't rebuilt during the window when
those symbols were in libstdc++.so, or it has already been rebuilt
with the new GCC that fixes the problem.
Or maybe it just doesn't use std::call_once in the new version.
Is there some way I can confirm whether a package (like dotnet5.0) is
affected or not?
You can check if any binaries in your package depend on either ofthe
two symbols listed in the bugzilla report above:
_ZNSt9once_flag11_M_activateEv
_ZNSt9once_flag9_M_finishEb
You can use objdump -T or nm -D on the binary and grep for the
symbols, e.g. nm -D libfoo.so | grep _ZNSt9once_flag
If it should have been in my list then please let me know, or just
bump+build it yourself.
4:46 a.m.
* Omair Majid:
Hi,
Jonathan Wakely <jwakely(a)fedoraproject.org> writes:
> Due to an unplanned ABI break that I caused in libstdc++, I will soon
> start to rebuild the packages listed below. This rebuild will remove
> references to some symbols in libstdc++.so which do not work as
> intended, and so will not be present in the final gcc-11.1.0 release.
>
> See https://bugzilla.redhat.com/show_bug.cgi?id=1937698 for reference.
>
> Package maintainers should not need to do anything, but will see a
> %release bump and a rebuild.
> dotnet3.1
I am bit surprised that dotnet3.1 is in that list but not dotnet5.0.
Is there some way I can confirm whether a package (like dotnet5.0) is
affected or not?
For dotnet3.1, I see
/usr/lib64/dotnet/host/fxr/3.1.13/libhostfxr.so
/usr/lib64/dotnet/shared/Microsoft.NETCore.App/3.1.13/libhostpolicy.so
as affected. They contain references to _ZNSt9once_flag11_M_activateEv
or _ZNSt9once_flag9_M_finishEb. These two symbols are the critical
symbols to check for; they indicate a need for a rebuild.
I do not see such symbol references for dotnet5.0. I have
double-checked that dotnet5.0 is part of the scanned set.
Thanks,
Florian
5:24 a.m.
On 31/03/21 11:46 +0200, Florian Weimer wrote:
* Omair Majid:
> Hi,
>
> Jonathan Wakely <jwakely(a)fedoraproject.org> writes:
>
>> Due to an unplanned ABI break that I caused in libstdc++, I will soon
>> start to rebuild the packages listed below. This rebuild will remove
>> references to some symbols in libstdc++.so which do not work as
>> intended, and so will not be present in the final gcc-11.1.0 release.
>>
>> See https://bugzilla.redhat.com/show_bug.cgi?id=1937698 for reference.
>>
>> Package maintainers should not need to do anything, but will see a
>> %release bump and a rebuild.
>
>> dotnet3.1
>
> I am bit surprised that dotnet3.1 is in that list but not dotnet5.0.
>
> Is there some way I can confirm whether a package (like dotnet5.0) is
> affected or not?
For dotnet3.1, I see
/usr/lib64/dotnet/host/fxr/3.1.13/libhostfxr.so
/usr/lib64/dotnet/shared/Microsoft.NETCore.App/3.1.13/libhostpolicy.so
as affected. They contain references to _ZNSt9once_flag11_M_activateEv
or _ZNSt9once_flag9_M_finishEb. These two symbols are the critical
symbols to check for; they indicate a need for a rebuild.
I do not see such symbol references for dotnet5.0. I have
Agreed, I downloaded dotnet-runtime-5.0-5.0.4-1.fc34.x86_64.rpm and
checked it too (although not the other subpackages in that build).
double-checked that dotnet5.0 is part of the scanned set.
Great, thanks!
8:19 a.m.
Hi,
Jonathan Wakely <jwakely(a)fedoraproject.org> writes:
On 31/03/21 11:46 +0200, Florian Weimer wrote:
>I do not see such symbol references for dotnet5.0. I have
Agreed, I downloaded dotnet-runtime-5.0-5.0.4-1.fc34.x86_64.rpm and
checked it too (although not the other subpackages in that build).
>double-checked that dotnet5.0 is part of the scanned set.
Great, thanks!
Agreed: thanks for looking into this!
Omair
--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108 E7BD DF99 7AF8 B157 A9F0
2:10 a.m.
Le mar. 30 mars 2021 à 18:13, Jonathan Wakely
<jwakely(a)fedoraproject.org> a écrit :
Due to an unplanned ABI break that I caused in libstdc++, I will soon
start to rebuild the packages listed below. This rebuild will remove
references to some symbols in libstdc++.so which do not work as
intended, and so will not be present in the final gcc-11.1.0 release.
See https://bugzilla.redhat.com/show_bug.cgi?id=1937698 for reference.
Can you explain why only the f34 branch would be affected ?
Also this is a problem if you only bump the f34 branch and not the
rawhide one, as package EVR will be lower on rawhide...
Thanks.
4:43 a.m.
* Nicolas Chauvet:
Le mar. 30 mars 2021 à 18:13, Jonathan Wakely
<jwakely(a)fedoraproject.org> a écrit :
>
> Due to an unplanned ABI break that I caused in libstdc++, I will soon
> start to rebuild the packages listed below. This rebuild will remove
> references to some symbols in libstdc++.so which do not work as
> intended, and so will not be present in the final gcc-11.1.0 release.
>
> See https://bugzilla.redhat.com/show_bug.cgi?id=1937698 for reference.
Can you explain why only the f34 branch would be affected ?
Both rawhide and f34 branches need to be rebuilt.
Thanks,
Florian
4:45 a.m.
On 31/03/21 09:10 +0200, Nicolas Chauvet wrote:
Le mar. 30 mars 2021 à 18:13, Jonathan Wakely
<jwakely(a)fedoraproject.org> a écrit :
>
> Due to an unplanned ABI break that I caused in libstdc++, I will soon
> start to rebuild the packages listed below. This rebuild will remove
> references to some symbols in libstdc++.so which do not work as
> intended, and so will not be present in the final gcc-11.1.0 release.
>
> See https://bugzilla.redhat.com/show_bug.cgi?id=1937698 for reference.
Can you explain why only the f34 branch would be affected ?
Rawhide is also affected. I'm going to do it for rawhide too, I
should have said that, sorry.
Also this is a problem if you only bump the f34 branch and not the
rawhide one, as package EVR will be lower on rawhide...
F34 is more urgent, as it's close to release and we don't want
dependencies on those symbols present in the final release. For that
reason, I was planning to do all the F34 rebuilds first, then rawhide.
But I can start the same rebuilds in rawhide now to avoid the version
skew.
8 a.m.
On 31.03.2021 11:45, Jonathan Wakely wrote:
But I can start the same rebuilds in rawhide now to avoid the
version
skew.
Please merge your commit from f34 instead of doing another one:
fedpkg switch-branch rawhide
git merge f34
fedpkg build --nowait
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
8:25 a.m.
On 31/03/21 15:00 +0200, Vitaly Zaitsev via devel wrote:
On 31.03.2021 11:45, Jonathan Wakely wrote:
>But I can start the same rebuilds in rawhide now to avoid the version
>skew.
Please merge your commit from f34 instead of doing another one:
fedpkg switch-branch rawhide
git merge f34
Yes, obviously.
fedpkg build --nowait
8:29 a.m.
On 31/03/21 14:25 +0100, Jonathan Wakely wrote:
On 31/03/21 15:00 +0200, Vitaly Zaitsev via devel wrote:
>On 31.03.2021 11:45, Jonathan Wakely wrote:
>>But I can start the same rebuilds in rawhide now to avoid the version
>>skew.
>
>Please merge your commit from f34 instead of doing another one:
>
>fedpkg switch-branch rawhide
>git merge f34
Yes, obviously.
You need a push here, before the build.
>fedpkg build --nowait
7:54 a.m.
On 30.03.2021 18:13, Jonathan Wakely wrote:
Package maintainers should not need to do anything, but will see a
%release bump and a rebuild.
In future, please commit to rawhide branch too. I want to keep my Git
history linear to avoid any merge conflicts between branches.
Also pushing the new build to f34 will break the upgrade path.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
5:09 a.m.
On 30/03/21 17:13 +0100, Jonathan Wakely wrote:
Due to an unplanned ABI break that I caused in libstdc++, I will soon
start to rebuild the packages listed below. This rebuild will remove
references to some symbols in libstdc++.so which do not work as
intended, and so will not be present in the final gcc-11.1.0 release.
See https://bugzilla.redhat.com/show_bug.cgi?id=1937698 for reference.
Package maintainers should not need to do anything, but will see a
%release bump and a rebuild.
Most of these are done in both f34 and rawhide. I need to rebuild
godot again, because the spec tries to be too clever:
Release: %{?prerel:0.%{status}.}1%{?dist}
This confuses rpmdev-bumpspec and so we get:
Release: %{?prerel:0.%{status}.}1%{?dist}.1
e.g. godot-3.2.3-1.fc35.1.x86_64.rpm
Should rpmdev-bumpspec be able to handle this, or should maintainers
just avoid trying to be clever?
----------------------------
OpenImageIO
PDAL
SoapySDR
audacious
audacity
blender
boost
botan2
ceph
chromium
clang
cockatrice
community-mysql
cpprest
date
davix
deepin-file-manager
deepin-image-viewer
dolphin-emu
domoticz
dotnet3.1
doxygen
dyninst
et
fawkes
firefox
fish
folly
freecad
freeopcua
gazebo
gdb
gnome-sudoku
gnuradio
godot
heaptrack
hidviz
hpx
icecat
icu
insight
julia
kdevelop-php
kernelshark
kf5-kio
kicad
kio-extras
kismet
libarcus
libarcus-lulzbot
libdigidocpp
libixion
libmodsecurity
libomp
librealsense
libreoffice
librime
lld
lldb
llvm
llvm7.0
lnav
log4cplus
logiops
luxcorerender
mame
mapnik
mariadb
mingw-llvm
mir
mlir
mmapper
movit
mozc
mozjs78
mypaint
mysql-connector-odbc
nghttp2
nodejs
oidn
ompl
onednn
opencv
openshadinglanguage
openvdb
osm2pgsql
osmium-tool
paraview
parzip
pdns
poedit
polly
poppler
primesieve
protobuf
protobuf-c
proxysql
prusa-slicer
pulseeffects
pyosmium
python-pynest2d
qgis
qmasterpassword
qpid-proton
qt-creator
qt5-qtlocation
qt5-qtwebengine
qt5-qtwebkit
qtcurve
rdkit
re2
rlottie
root
rstudio
scipy
seqan2
spirv-llvm-translator
sqlitebrowser
srt
supercollider
swift-lang
thunderbird
tkrzw
uhd
usbguard
vapoursynth
vigra
warzone2100
watchman
webextension-token-signing
webkit2gtk3
wesnoth
worker
wsjtx
xrdcl-http
xrootd
yacreader
zimlib
zynaddsubfx
5:36 a.m.
* Jonathan Wakely:
On 30/03/21 17:13 +0100, Jonathan Wakely wrote:
>Due to an unplanned ABI break that I caused in libstdc++, I will soon
>start to rebuild the packages listed below. This rebuild will remove
>references to some symbols in libstdc++.so which do not work as
>intended, and so will not be present in the final gcc-11.1.0 release.
>
>See https://bugzilla.redhat.com/show_bug.cgi?id=1937698 for reference.
>
>Package maintainers should not need to do anything, but will see a
>%release bump and a rebuild.
Most of these are done in both f34 and rawhide.
FYI, I looked at the mame build failure, and it's a missing makefile
dependency on a generated file, exposed by a build that has more
parallelism than what upstream apparently expects.
Thanks,
Florian
6:30 a.m.
On 01/04/21 12:36 +0200, Florian Weimer wrote:
* Jonathan Wakely:
> On 30/03/21 17:13 +0100, Jonathan Wakely wrote:
>>Due to an unplanned ABI break that I caused in libstdc++, I will soon
>>start to rebuild the packages listed below. This rebuild will remove
>>references to some symbols in libstdc++.so which do not work as
>>intended, and so will not be present in the final gcc-11.1.0 release.
>>
>>See https://bugzilla.redhat.com/show_bug.cgi?id=1937698 for reference.
>>
>>Package maintainers should not need to do anything, but will see a
>>%release bump and a rebuild.
>
> Most of these are done in both f34 and rawhide.
FYI, I looked at the mame build failure, and it's a missing makefile
dependency on a generated file, exposed by a build that has more
parallelism than what upstream apparently expects.
Thanks for checking it.
I've cancelled those two mame builds, so that the s390x builders are
free for other packages (they already failed on aother arches, so
there's no point continuing the s390x build).
6:26 a.m.
On 01/04/21 11:09 +0100, Jonathan Wakely wrote:
On 30/03/21 17:13 +0100, Jonathan Wakely wrote:
>Due to an unplanned ABI break that I caused in libstdc++, I will soon
>start to rebuild the packages listed below. This rebuild will remove
>references to some symbols in libstdc++.so which do not work as
>intended, and so will not be present in the final gcc-11.1.0 release.
>
>See https://bugzilla.redhat.com/show_bug.cgi?id=1937698 for reference.
>
>Package maintainers should not need to do anything, but will see a
>%release bump and a rebuild.
Most of these are done in both f34 and rawhide. I need to rebuild
godot again, because the spec tries to be too clever:
godot is building again.
There are two additional packages which are only affected on rawhide:
llvm11
rocksdb
Those two are rebuilding now too.
Several packages failed to build:
clang (f34)
chromium (f34, rawhide)
freecad (f34, rawhide)
hpx (f34, rawhide)
kernelshark (f34, rawhide)
mingw-llvm (f34, rawhide)
oidn (rawhide)
openshadinglanguage (f34, rawhide)
paraview (rawhide)
qt5-qtwebengine (rawhide)
qt5-qtwebkit (f34, rawhide)
rdkit (f34, rawhide)
root (f34, rawhide)
scipy (f34, rawhide)
spirv-llvm-translator (f34, rawhide)
I've opened bugs for a couple of these, I'm going to ignore the rest
but if you own any of those, please fix them.
Once everything's finished I'll ask Florian to check the entire distro
for any remaining uses of those symbols, and do anything I've missed.
1126
days inactive
1128
days old
16 comments
5 participants
participants (5)
-
Florian Weimer -
Jonathan Wakely -
Nicolas Chauvet -
Omair Majid -
Vitaly Zaitsev