telegram-desktop starting from 3.1.8 can only be compiled with GCC 10.X.X gcc 9.X.X /usr/include/range/v3/utility/semiregular_box.hpp:142:51: internal compiler error: Segmentation fault 142 | explicit(!convertible_to<U, T>) constexpr semiregular_box(U && u) | ^~~~~~~~~~~~~~~ gcc gcc 11.X.X /usr/include/range/v3/utility/semiregular_box.hpp:142:51: internal compiler error: Segmentation fault 142 | explicit(!convertible_to<U, T>) constexpr semiregular_box(U && u) | ^~~~~~~~~~~~~~~ gcc 10.X.X is fine compiling it Reproducible: Always
Created attachment 777593 [details] gcc-9.3.0 build log gcc-9.3.0 segfaults with telegram desktop 3.5.2-r1
Created attachment 777596 [details] gcc-11.2.0 build log gcc-11.2.0 segfaults building tdesktop-3.5.2
/usr/include/range/v3 is part of the dev-cpp/range-v3 package. You also seem to be getting errors for /usr/include/glibmm-2.4, which is dev-cpp/glibmm. I will be removing 3.5.2-r1 from the tree soon, as I just don't see the purpose of keeping multiple stabilized packages around, though I'm fairly sure it built fine with gcc-11 back when I last built it. GCC 11.x support was introduced with net-im/telegram-desktop-2.7.4, after all... Can you make sure net-im/telegram-desktop-3.6.1-r1 builds correctly with gcc 11 on your end? And just to make sure, using dev-cpp/range-v3-0.11.0 and dev-cpp/glibmm-2.66.2? If you care about supporting gcc 9 then you're free to build with that, too. I cannot reproduce this issue by building net-im/telegram-desktop-3.6.1-r1 with gcc 11.
Internal compiler errors (ICEs) are always bugs in the compiler, not the respective packages. If it's reproducible, please: 1. do a memtest (please don't skip this) 2. then follow https://wiki.gentoo.org/wiki/Gcc-ICE-reporting-guide (we can help as needed).
compilation of /telegram-desktop-3.6.1-r1 crashes with the same segmentation fault with gcc 9.X.X and gcc 11.X.X but would succeed with 10.X.X, it's possible that upgrading glibmm from the installed 2.64.2 to a higher version can solve the segfault, but this only means that ebuild has a wrong dependency. I've not tried upgrading glibmm - to not spoil the bug although this was the next thing to try. The latest telegram-desktop version that builds with gcc 9.X.X and glibmm 2.64.2 is telegram-desktop-3.0.1-r1 - the rest would segfault with 9.X.X and 11.X.X, but will succeed with 10.X.X (as stated) Try downgrading glibmm to 2.64.2 - and compile - I believe it would segfault. (In reply to Esteve Varela Colominas from comment #3) > /usr/include/range/v3 is part of the dev-cpp/range-v3 package. You also seem > to be getting errors for /usr/include/glibmm-2.4, which is dev-cpp/glibmm. > > I will be removing 3.5.2-r1 from the tree soon, as I just don't see the > purpose of keeping multiple stabilized packages around, though I'm fairly > sure it built fine with gcc-11 back when I last built it. GCC 11.x support > was introduced with net-im/telegram-desktop-2.7.4, after all... > > Can you make sure net-im/telegram-desktop-3.6.1-r1 builds correctly with gcc > 11 on your end? And just to make sure, using dev-cpp/range-v3-0.11.0 and > dev-cpp/glibmm-2.66.2? If you care about supporting gcc 9 then you're free > to build with that, too. > > I cannot reproduce this issue by building net-im/telegram-desktop-3.6.1-r1 > with gcc 11.
Created attachment 777626 [details] gcc related info GCC related info, including march
(In reply to Igor Franchuk from comment #6) > Created attachment 777626 [details] > gcc related info > > GCC related info, including march Can you do the testing with 9.4.0 and 11.3.0 as they're the latest in each series, and for 10.x, 10.3.1_p*?
Unlikely memory problem, the box is stable and the segfault is always at the same place, with gcc 9.X.X 11.X.X but not there with gcc 10.X.X with the memory stick going bad the segfaults are very likely to be random depending on box load/memory consumption. Nothing like that happens, but just for the record I will run the memtest. I've compiled a few packages on this box since I reported this segfault - no segfaults. It only happens with the particular telegram-desktop. Versions above 3.0.X - below are fine, 3.0.X - fine - but newer version would fail. I've not tried them all but at least these: telegram-desktop-3.1.8.ebuild telegram-desktop-3.5.2-r1.ebuild telegram-desktop-3.6.1.ebuild are all going to fail with gcc 9.X.X and gcc 11.X.X at the same place with the similar segfault. But gcc 10.X.X is unaffected. I've attached gcc related info according to Gcc-ICE-reporting-guide I agree that it is likely related to glibmm. If you want to reproduce that problem - try downgrading glibmm to 2.64.2 (In reply to Sam James from comment #4) > Internal compiler errors (ICEs) are always bugs in the compiler, not the > respective packages. > > If it's reproducible, please: > 1. do a memtest (please don't skip this) > 2. then follow https://wiki.gentoo.org/wiki/Gcc-ICE-reporting-guide (we can > help as needed).
OK, I'm going to build gcc-10.3.1_p20211126 first and try what is known at this point that of : gcc-config -l [1] avr-10.2.0 * [2] x86_64-pc-linux-gnu-9.3.0 * [3] x86_64-pc-linux-gnu-9.4.0 [4] x86_64-pc-linux-gnu-10.3.0 [5] x86_64-pc-linux-gnu-11.2.0 at the very same place in teglegram-desktop 3.6.1-r1 & 3.5.2-r1 (with glibmm-2.4) : 9.3.0 -> segfaults 9.4.0 -> segfaults 10.3.0 -> compiles 11.2.0 -> segfaults (In reply to Sam James from comment #7) > (In reply to Igor Franchuk from comment #6) > > Created attachment 777626 [details] > > gcc related info > > > > GCC related info, including march > > Can you do the testing with 9.4.0 and 11.3.0 as they're the latest in each > series, and for 10.x, 10.3.1_p*?
gcc-10.3.1_p20211126.ebuild won't build because gcc-10.3.1.tar.xz is unavailable I could use rename 10.3.0 to 10.3.1 instead but not sure if the experiment is going to be correct. (In reply to Sam James from comment #7) > (In reply to Igor Franchuk from comment #6) > > Created attachment 777626 [details] > > gcc related info > > > > GCC related info, including march > > Can you do the testing with 9.4.0 and 11.3.0 as they're the latest in each > series, and for 10.x, 10.3.1_p*?
(In reply to Igor Franchuk from comment #10) > gcc-10.3.1_p20211126.ebuild > > won't build because gcc-10.3.1.tar.xz is unavailable > I think you're doing something manually that you shouldn't be. It should grab gcc-10-20211126.tar.xz from gentoo's mirrors. Do you have GENTOO_MIRRORS set?
How comes gcc-10-20211126.tar.xz? The ebuild name is gcc-10.3.1_p20211126.ebuild May be eclass was changed... then again EAPI=7 means that all EAPI7 eclasses should be supported. I can't fetch it. I tried to access https://gentoo-mirror.alexxy.name/distfiles/f5/gcc-10-20211126.tar.xz - NOT FOUND ebuild /var/db/repos/local/sys-devel/gcc/gcc-10.3.1_p20211126.ebuild manifest >>> Downloading 'https://gentoo-mirror.alexxy.name/distfiles/f5/gcc-10.3.1.tar.xz' --2022-05-09 15:32:17-- https://gentoo-mirror.alexxy.name/distfiles/f5/gcc-10.3.1.tar.xz Resolving gentoo-mirror.alexxy.name... 79.173.84.186, 2001:470:1f15:106:e2d5:5eff:fe42:7ae5 Connecting to gentoo-mirror.alexxy.name|79.173.84.186|:443... connected. HTTP request sent, awaiting response... 404 Not Found 2022-05-09 15:32:17 ERROR 404: Not Found. # Copyright 1999-2022 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 EAPI=7 PATCH_VER="5" PATCH_GCC_VER="12.0.0" MUSL_VER="4" MUSL_GCC_VER="12.0.0" inherit toolchain #KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~riscv ~s390 ~sparc ~x86" KEYWORDS="~loong" # Technically only if USE=hardened *too* right now, but no point in complicating it further. # If GCC is enabling CET by default, we need glibc to be built with support for it. # bug #830454 RDEPEND="elibc_glibc? ( sys-libs/glibc[cet(-)?] )" DEPEND="${RDEPEND}" BDEPEND="${CATEGORY}/binutils[cet(-)?]" src_prepare() { toolchain_src_prepare if tc-is-cross-compiler ; then # bug #803371 eapply "${FILESDIR}"/gcc-11.2.0-cross-compile-include.patch fi eapply_user } (In reply to Sam James from comment #11) > (In reply to Igor Franchuk from comment #10) > > gcc-10.3.1_p20211126.ebuild > > > > won't build because gcc-10.3.1.tar.xz is unavailable > > > > I think you're doing something manually that you shouldn't be. It should > grab gcc-10-20211126.tar.xz from gentoo's mirrors. Do you have > GENTOO_MIRRORS set?
Sorry, the pasted ebuild from the previous post was from gcc-12.0.1_pre20220430.ebuild gcc-10.3.1_p20211126.ebuild is: # Copyright 1999-2022 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 EAPI=7 PATCH_VER="0" PATCH_GCC_VER="10.4.0" MUSL_VER="1" MUSL_GCC_VER="10.3.0" inherit toolchain KEYWORDS="~alpha amd64 arm arm64 hppa ~ia64 ~m68k ~mips ppc ppc64 ~riscv ~s390 sparc x86" RDEPEND="" BDEPEND="${CATEGORY}/binutils" src_prepare() { if has_version '>=sys-libs/glibc-2.32-r1'; then rm -v "${WORKDIR}/patch/23_all_disable-riscv32-ABIs.patch" || die fi toolchain_src_prepare eapply_user } (In reply to Sam James from comment #11) > (In reply to Igor Franchuk from comment #10) > > gcc-10.3.1_p20211126.ebuild > > > > won't build because gcc-10.3.1.tar.xz is unavailable > > > > I think you're doing something manually that you shouldn't be. It should > grab gcc-10-20211126.tar.xz from gentoo's mirrors. Do you have > GENTOO_MIRRORS set? the manifest paste is correct, I'll extend it... but the idea is that 10.3.1.tar.xz is failing to be fetched... BTW it is so much misleading sometimes when you call ebuild /var/db/repos/local/sys-devel/gcc/gcc-10.3.1_p20211126.ebuild manifest it tries to re-build manifest for others ebuilds not listed in manifest... ebuild /var/db/repos/local/sys-devel/gcc/gcc-10.3.1_p20211126.ebuild manifest >>> Downloading 'https://gentoo-mirror.alexxy.name/distfiles/f5/gcc-10.3.1.tar.xz' --2022-05-09 15:59:24-- https://gentoo-mirror.alexxy.name/distfiles/f5/gcc-10.3.1.tar.xz Resolving gentoo-mirror.alexxy.name... 79.173.84.186, 2001:470:1f15:106:e2d5:5eff:fe42:7ae5 Connecting to gentoo-mirror.alexxy.name|79.173.84.186|:443... connected. HTTP request sent, awaiting response... 404 Not Found 2022-05-09 15:59:24 ERROR 404: Not Found. >>> Downloading 'https://mirror.yandex.ru/gentoo-distfiles/distfiles/f5/gcc-10.3.1.tar.xz' --2022-05-09 15:59:24-- https://mirror.yandex.ru/gentoo-distfiles/distfiles/f5/gcc-10.3.1.tar.xz Resolving mirror.yandex.ru... 213.180.204.183, 2a02:6b8::183 Connecting to mirror.yandex.ru|213.180.204.183|:443... connected. HTTP request sent, awaiting response... 404 Not Found 2022-05-09 15:59:24 ERROR 404: Not Found. >>> Downloading 'ftp://mirror.yandex.ru/gentoo-distfiles/distfiles/f5/gcc-10.3.1.tar.xz' pathconf: Permission denied --2022-05-09 15:59:24-- ftp://mirror.yandex.ru/gentoo-distfiles/distfiles/f5/gcc-10.3.1.tar.xz => ‘/var/db/distfiles/gcc-10.3.1.tar.xz.__download__’ Resolving mirror.yandex.ru... 213.180.204.183, 2a02:6b8::183 Connecting to mirror.yandex.ru|213.180.204.183|:21... connected. Logging in as anonymous ... Logged in! ==> SYST ... done. ==> PWD ... done. ==> TYPE I ... done. ==> CWD (1) /gentoo-distfiles/distfiles/f5 ... done. ==> SIZE gcc-10.3.1.tar.xz ... done. ==> PASV ... done. ==> RETR gcc-10.3.1.tar.xz ... No such file ‘gcc-10.3.1.tar.xz’. another try to make sure we're fetching the ebuild data ebuild /var/db/repos/local/sys-devel/gcc/gcc-10.3.1_p20211126.ebuild fetch !!! Fetched file: gcc-10.3.1.tar.xz VERIFY FAILED! !!! Reason: Insufficient data for checksum verification !!! Got: !!! Expected: BLAKE2B BLAKE2S MD5 RMD160 SHA1 SHA256 SHA3_256 SHA3_512 SHA512 WHIRLPOOL
I think you're using an outdated GENTOO_MIRRORS. I tested fetching from Gentoo's mirrors last night.
Unlikely they're the same as stated here: https://www.gentoo.org/downloads/mirrors/ could you try: ebuild /var/db/repos/gentoo/sys-devel/gcc/gcc-10.3.1_p20211126.ebuild fetch and paste the source and file name of the fetched source (console output)? (In reply to Sam James from comment #14) > I think you're using an outdated GENTOO_MIRRORS. I tested fetching from > Gentoo's mirrors last night.
(In reply to Igor Franchuk from comment #15) > Unlikely they're the same as stated here: > > https://www.gentoo.org/downloads/mirrors/ > > could you try: > > ebuild /var/db/repos/gentoo/sys-devel/gcc/gcc-10.3.1_p20211126.ebuild fetch > > and paste the source and file name of the fetched source (console output)? > > > (In reply to Sam James from comment #14) > > I think you're using an outdated GENTOO_MIRRORS. I tested fetching from > > Gentoo's mirrors last night. $ ebuild /var/db/repos/gentoo/sys-devel/gcc/gcc-10.3.1_p20211126.ebuild fetch >>> Downloading 'https://mirror.init7.net/gentoo/distfiles/b3/gcc-10-20211126.tar.xz' --2022-05-09 16:18:21-- https://mirror.init7.net/gentoo/distfiles/b3/gcc-10-20211126.tar.xz Resolving mirror.init7.net... 2001:1620::1620, 109.202.202.202 Connecting to mirror.init7.net|2001:1620::1620|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 71674848 (68M) [application/octet-stream] Saving to: ‘/var/cache/distfiles/gcc-10-20211126.tar.xz.__download__’ /var/cache/distfiles/gcc-10-20211126.tar.xz.__d 100%[=====================================================================================================>] 68,35M 28,1MB/s in 2,4s 2022-05-09 16:18:24 (28,1 MB/s) - ‘/var/cache/distfiles/gcc-10-20211126.tar.xz.__download__’ saved [71674848/71674848] * gcc-10-20211126.tar.xz BLAKE2B SHA512 size ;-) ... [ ok ] * gcc-10.4.0-patches-0.tar.bz2 BLAKE2B SHA512 size ;-) ... [ ok ] * gcc-10.3.0-musl-patches-1.tar.bz2 BLAKE2B SHA512 size ;-) ... works fine here
Thank you. Your fetch is for a different file. That can only happen if we have different /eclass/ in /gentoo/ tree. Mine portage: Portage 3.0.28 (python 3.9.0-final-0, default/linux/amd64/17.1/desktop/plasma, gcc-9.3.0, glibc-2.32-r2, 4.14.209-gentoo-x86_64 x86_64) could you please datail on: /var/db/repos/gentoo/eclass/toolchain.eclass Mine is 73799.00 bytes, 2376.00 lines (no version inside sorry) (13.10.2021) and it has : get_gcc_src_uri() { export PATCH_GCC_VER=${PATCH_GCC_VER:-${GCC_RELEASE_VER}} export UCLIBC_GCC_VER=${UCLIBC_GCC_VER:-${PATCH_GCC_VER}} export PIE_GCC_VER=${PIE_GCC_VER:-${GCC_RELEASE_VER}} export HTB_GCC_VER=${HTB_GCC_VER:-${GCC_RELEASE_VER}} export SPECS_GCC_VER=${SPECS_GCC_VER:-${GCC_RELEASE_VER}} # Set where to download gcc itself depending on whether we're using a # live git tree, snapshot, or release tarball. if tc_is_live ; then : # Nothing to do w/git snapshots. elif [[ -n ${GCC_TARBALL_SRC_URI} ]] ; then # pull gcc tarball from another location. Frequently used by gnat-gpl. GCC_SRC_URI="${GCC_TARBALL_SRC_URI}" elif [[ -n ${SNAPSHOT} ]] ; then GCC_SRC_URI="ftp://gcc.gnu.org/pub/gcc/snapshots/${SNAPSHOT}/gcc-${SNAPSHOT}.tar.xz" else if tc_version_is_between 5.5 6 || tc_version_is_between 6.4 7 || tc_version_is_at_least 7.2 ; then GCC_SRC_URI="mirror://gnu/gcc/gcc-${GCC_PV}/gcc-${GCC_RELEASE_VER}.tar.xz" else GCC_SRC_URI="mirror://gnu/gcc/gcc-${GCC_PV}/gcc-${GCC_RELEASE_VER}.tar.bz2" fi fi [[ -n ${UCLIBC_VER} ]] && \ GCC_SRC_URI+=" $(gentoo_urls gcc-${UCLIBC_GCC_VER}-uclibc-patches-${UCLIBC_VER}.tar.bz2)" [[ -n ${PATCH_VER} ]] && \ GCC_SRC_URI+=" $(gentoo_urls gcc-${PATCH_GCC_VER}-patches-${PATCH_VER}.tar.bz2)" [[ -n ${PIE_VER} ]] && \ PIE_CORE=${PIE_CORE:-gcc-${PIE_GCC_VER}-piepatches-v${PIE_VER}.tar.bz2} && \ GCC_SRC_URI+=" $(gentoo_urls ${PIE_CORE})" # gcc minispec for the hardened gcc 4 compiler [[ -n ${SPECS_VER} ]] && \ GCC_SRC_URI+=" $(gentoo_urls gcc-${SPECS_GCC_VER}-specs-${SPECS_VER}.tar.bz2)" if tc_has_feature gcj ; then if tc_version_is_at_least 4.5 ; then GCC_SRC_URI+=" gcj? ( ftp://sourceware.org/pub/java/ecj-4.5.jar )" elif tc_version_is_at_least 4.3 ; then GCC_SRC_URI+=" gcj? ( ftp://sourceware.org/pub/java/ecj-4.3.jar )" fi fi # Cygwin patches from https://github.com/cygwinports/gcc [[ -n ${CYGWINPORTS_GITREV} ]] && \ GCC_SRC_URI+=" elibc_Cygwin? ( https://github.com/cygwinports/gcc/archive/${CYGWINPORTS_GITREV}.tar.gz -> gcc-cygwinports-${CYGWINPORTS_GITREV}.tar.gz )" echo "${GCC_SRC_URI}" } I guess yours is different and that's how fetch is for a different file with both of us. Not sure if it could be called a bug in toolchain.eclass but certainly inconsistency. > * gcc-10-20211126.tar.xz BLAKE2B SHA512 size ;-) ... > [ ok ] > * gcc-10.4.0-patches-0.tar.bz2 BLAKE2B SHA512 size ;-) ... > [ ok ] > * gcc-10.3.0-musl-patches-1.tar.bz2 BLAKE2B SHA512 size ;-) ... > > works fine here
The eclass has changed a huge number of times since October. Why is yours different?
(In reply to Sam James from comment #18) > The eclass has changed a huge number of times since October. Why is yours > different? I don't know what the "last" repository is but it's clearly out of date and is not ::gentoo.
The portage was not synced since then. That is a stabilization box, it was built/tested and not going to change any time soon to make sure it performs. Just going to work till it's outdated and trashed with the hardware. If somebody else experience the same problem someday he will find this bug and comment on that. If none experience the same then it's probably for the future reporters to fix as it's likely present in the new gcc too but needs special conditions. (In reply to Sam James from comment #18) > The eclass has changed a huge number of times since October. Why is yours > different?
(In reply to Igor Franchuk from comment #21) > The portage was not synced since then. That is a stabilization box, it was > built/tested and not going to change any time soon to make sure it performs. > Just going to work till it's outdated and trashed with the hardware. > > If somebody else experience the same problem someday he will find this bug > and comment on that. If none experience the same then it's probably for the > future reporters to fix as it's likely present in the new gcc too but needs > special conditions. > > (In reply to Sam James from comment #18) > > The eclass has changed a huge number of times since October. Why is yours > > different? How do you expect this to scale for a rolling distribution like Gentoo? Sorry, we won't support this configuration, you're on your own here.
The assumption with bugs, unless otherwise stated, is that you're operating on an up to date system. We are sometimes happy to try handle odd situations (but not necessarily going to have the time/motivation to do so), *but you have to tell us*. It's impolite/rude not to as we're going to assume all sorts of things. You need to tell us what's unusual abuot your system from the beginning. Guessing games help nobody. I could've immediately told you the problem with fetching if you'd been clear about this. We also would've/do need a list of all installed packages and versions (qlop could help) to debug this. In any case, ICEs shouldn't be happening, and to only get it with 9.x and 11.x is weird. Hard to say any more unless you can test modern versions of GCC so we can debug it and report it upstream.
Segfaults in gcc are abnormal. I'll update the box (portage) but will not upgrade the libraries. The current telegram-desktop ebuild allows this set of libraries to compile telegram-desktop anyway, so technically speaking it's a correct configuration. Then I'll try the latest gcc versions and get back with the results. Probably a regression in GCC, happens now and then. Thanks! (In reply to Sam James from comment #23) > The assumption with bugs, unless otherwise stated, is that you're operating > on an up to date system. > > We are sometimes happy to try handle odd situations (but not necessarily > going to have the time/motivation to do so), *but you have to tell us*. It's > impolite/rude not to as we're going to assume all sorts of things. You need > to tell us what's unusual abuot your system from the beginning. Guessing > games help nobody. > > I could've immediately told you the problem with fetching if you'd been > clear about this. We also would've/do need a list of all installed packages > and versions (qlop could help) to debug this. > > In any case, ICEs shouldn't be happening, and to only get it with 9.x and > 11.x is weird. Hard to say any more unless you can test modern versions of > GCC so we can debug it and report it upstream.
I'd like to note that the dependency version specifications are a best effort when it comes to versions of software that aren't available in ::gentoo anymore (and never were since the ebuild's creation). While you're free to test these versions and contribute to the version information of dependencies, you shouldn't assume these are correct for packages and versions that aren't in the tree. It's simply infeasible to test all combinations a user might end up with if they don't do a deep update.
follow up : memetest86+ is OK while updating the portage I hit the bug : https://bugs.gentoo.org/815216 gcc-9.4.1_p20220317 is building, when complete I'll test it with telegram-desktop from the current gentoo
Created attachment 778535 [details] gcc-9.4.1 build log latest gcc-9.4.1 fails with the same segfault
the latest gcc-9.4.1 fails with the same segfault, I submitted the new attachment with the last gcc-9.4.1 - same segfault at the same place /usr/include/range/v3/utility/semiregular_box.hpp:142:51: internal compiler error: Segmentation fault 142 | explicit(!convertible_to<U, T>) constexpr semiregular_box(U && u) | ^~~~~~~~~~~~~~~ # gcc --version gcc (Gentoo 9.4.1_p20220317 p1) 9.4.1 20220317 Copyright (C) 2019 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
I guess this bug was in gcc for quite a while, take a look: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93387
(In reply to Igor Franchuk from comment #29) > I guess this bug was in gcc for quite a while, take a look: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93387 Good find, thanks. We should really be disabling PCH where possible, it's masked in profiles for a reason too. Hopefully Telegram has a way to disable it.
I'm confused. How does using a precompiled header affect compilation issues when both the header and the rest of the code are built with the same compiler? Doesn't a precompiled header speed up compilation pretty dramatically? Does adding -fpch-preprocess to CXXFLAGS fix this issue? I'm a bit iffy about bugs I can't really reproduce...
Created attachment 778802 [details] gcc-11.3.0 build log gcc 11.3.0 build log
follow up: I installed gcc-11.3.0 and it failed to build too but no segmentation fault this time, see the attachment : gcc-11.3.0 build log Looks like the next logical step is to try is to upgrade glibmm from the installed 2.64.2 to 2.70.0 (In reply to Sam James from comment #30) > (In reply to Igor Franchuk from comment #29) > > I guess this bug was in gcc for quite a while, take a look: > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93387 > > Good find, thanks. We should really be disabling PCH where possible, it's > masked in profiles for a reason too. Hopefully Telegram has a way to disable > it.
likely related : https://github.com/telegramdesktop/tdesktop/issues/7054
(In reply to Esteve Varela Colominas from comment #31) > I'm confused. How does using a precompiled header affect compilation issues > when both the header and the rest of the code are built with the same > compiler? Doesn't a precompiled header speed up compilation pretty > dramatically? Does adding -fpch-preprocess to CXXFLAGS fix this issue? > I'm a bit iffy about bugs I can't really reproduce... We don't support PCH in Gentoo because of the history of breaking compilations in odd ways or, often, ICEing the compiler. It's hard-disabled in Meson and the flag is masked for GCC itself. We disable it in every package where possible.
I'm currently building telegram-desktop against glibmm-2.66.2 (upgraded) if you look here: https://github.com/desktop-app/cmake_helpers/commit/67cf2a5abdb01658c1cf852b29e25808dcc02c56 and then look here: /var/tmp/portage/net-im/telegram-desktop-3.5.2-r1/work/tdesktop-3.5.2-full/cmake/init_target.cmake you'll notice that this patch is gone. May be it's possible to disable PCH by adding if PCH is off in the profile if (CMAKE_CXX_COMPILER_ID STREQUAL "GNU") set(MAXIMUM_CXX_STANDARD cxx_std_17) endif() to /var/tmp/portage/net-im/telegram-desktop-3.5.2-r1/work/tdesktop-3.5.2-full/cmake/init_target.cmake if the build fails with glibmm-2.66.2 I will try set(MAXIMUM_CXX_STANDARD cxx_std_17) and see if it helps/builds (In reply to Esteve Varela Colominas from comment #31) > I'm confused. How does using a precompiled header affect compilation issues > when both the header and the rest of the code are built with the same > compiler? Doesn't a precompiled header speed up compilation pretty > dramatically? Does adding -fpch-preprocess to CXXFLAGS fix this issue? > I'm a bit iffy about bugs I can't really reproduce...
I've finished testing telegram-desktop with glibmm-2.66.2 The conclusions: 1. both: telegram-desktop-3.6.1-r1.ebuild and telegram-desktop-3.5.2-r1.ebuild are behaving the same in the tests 2. the patch if (CMAKE_CXX_COMPILER_ID STREQUAL "GNU") set(MAXIMUM_CXX_STANDARD cxx_std_17) endif() that was valid for telegram-desktop 2.x.x is no longer working, no way to turn off PCH for telegram-desktop as stated by Sam earlier (no segfaults but compilation will fail with gcc-9.3.0 at least 3. with glibmm-2.4 gcc 9.3.0 -> compilation segfaults at the same place gcc 9.4.1 -> compilation segfaults at the same place gcc 10.3.0 -> compilation successful gcc 11.2.0 -> compilation segfaults at the same place gcc 11.3.0 -> compilation fails, but no segfaults 4. with glibmm-2.66.2 gcc 9.3.0 -> compilation segfaults at the same place gcc 9.4.1 -> compilation segfaults at the same place gcc 10.3.0 -> compilation successful as with the previous glibmm version gcc 11.2.0 -> compilation segfaults at the same place gcc 11.3.0 -> compilation successful At least in my case for both ebuilds the correct dependencies would be: a. glibmm version >= 2.66.2 b. gcc version = 10.3.0 (may be other 10.X.X) or gcc version = 11.3.0 It looks safe to start from dependency on glibmm version >= 2.66.2 I didn't test it with the latest glibmm 2.70 but I think 9.3.0 and 9.4.1 will segfault with it the same and 10.3.0 would work. May be adding dependency on gcc version >= 10.3.0 is safe too as I didn't find any configuration to compile the ebuilds with 9.X.X Another conclusion is that gcc 10.3.0 and 11.3.0 at least with these tests look stable, if you choose between 11.3.0 and 10.3.0, gcc-10.3.0 is the best working gcc as it worked with both glibmm for both ebuilds, no segfaults, no compilation errors. gcc 9.3.0, gcc 9.4.1, gcc 11.2.0 seems to share the same problems (In reply to Esteve Varela Colominas from comment #25) > I'd like to note that the dependency version specifications are a best > effort when it comes to versions of software that aren't available in > ::gentoo anymore (and never were since the ebuild's creation). While you're > free to test these versions and contribute to the version information of > dependencies, you shouldn't assume these are correct for packages and > versions that aren't in the tree. It's simply infeasible to test all > combinations a user might end up with if they don't do a deep update.
Hello everyone, Today there are no versions of glibmm below 2.66.6 in the Portage tree and there is `<sys-devel/gcc-11` in the profiles/package.mask, so I believe this bug might be closed. Best regards!
