Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 786462 - dev-db/percona-server-8.0.22.13 fails to compile with gcc-11: error: ‘uintptr_t’ in namespace ‘std’ does not name a type
Summary: dev-db/percona-server-8.0.22.13 fails to compile with gcc-11: error: ‘uintptr...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Linux MySQL bugs team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: gcc-11
  Show dependency tree
 
Reported: 2021-04-28 14:43 UTC by Agostino Sarubbo
Modified: 2021-04-28 19:57 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments
build.log (build.log,516.94 KB, text/plain)
2021-04-28 14:43 UTC, Agostino Sarubbo
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Agostino Sarubbo gentoo-dev 2021-04-28 14:43:32 UTC
https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/

Issue: dev-db/percona-server-8.0.22.13 fails to compile with gcc-11.
Discovered on: amd64 (internal ref: ci)

NOTE:
This machine uses GCC-11: https://gcc.gnu.org/gcc-11/porting_to.html
Comment 1 Agostino Sarubbo gentoo-dev 2021-04-28 14:43:35 UTC
Created attachment 703263 [details]
build.log

build log and emerge --info
Comment 2 Agostino Sarubbo gentoo-dev 2021-04-28 14:43:37 UTC
Possible context of error(s):

  Could not find SASL
  Could not find LDAP
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE) 
/var/tmp/portage/dev-db/percona-server-8.0.22.13/work/mysql/include/my_alloc.h:161:40: error: ‘uintptr_t’ in namespace ‘std’ does not name a type
Comment 3 Thomas Deutschmann gentoo-dev Security 2021-04-28 15:21:35 UTC

*** This bug has been marked as a duplicate of bug 786393 ***
Comment 4 Agostino Sarubbo gentoo-dev 2021-04-28 15:32:58 UTC
https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ point 7
Comment 5 Thomas Deutschmann gentoo-dev Security 2021-04-28 15:36:36 UTC
You filed this bug against gcc-11 tracker, i.e. package fails to build against gcc-11. This has been resolved via bug 786393.

If you believe there is another bug, update your repository, build again and file new bug with new build.log and explain your finding.

But this bug which is about gcc-11 is a duplicate which was resolved.

*** This bug has been marked as a duplicate of bug 786393 ***
Comment 6 Agostino Sarubbo gentoo-dev 2021-04-28 15:52:32 UTC
(In reply to Thomas Deutschmann from comment #5)
> You filed this bug against gcc-11 tracker, i.e. package fails to build
> against gcc-11. This has been resolved via bug 786393.
> 
> If you believe there is another bug, update your repository, build again and
> file new bug with new build.log and explain your finding.
> 
> But this bug which is about gcc-11 is a duplicate which was resolved.
> 
> *** This bug has been marked as a duplicate of bug 786393 ***


I really don't understand your behavior.

Your commit has been done on:
CommitDate: 2021-04-28 13:19:20 +0000

This build log reports:
https://github.com/gentoo/gentoo/commit/df9692779fe7c9242d92ea9508312e18411a8e38  (Wed Apr 28 13:30:48 UTC 2021)

Means that my portage has your commit and percona-server fails in the same way. So in my opinion it still fails with gcc-11
Comment 7 Thomas Deutschmann gentoo-dev Security 2021-04-28 18:23:46 UTC
Your automated bug reports are really painful in comparison to other CI/tinderboxes because you drop the failure on the maintainer ("Possible context" is often wrong) and maintainer should figure out why build failed whereas bug reports from toralf for example are at the point.

As maintainer I am thankful for bug reports but I don't want to spend much time on them just to understand why this bug was filed.

Anyway, sorry for being harsh.

Reproduced as described, incoming fix.
Comment 8 Larry the Git Cow gentoo-dev 2021-04-28 18:26:26 UTC
The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ec859df7ec975ea0c31195ea336293675a22d840

commit ec859df7ec975ea0c31195ea336293675a22d840
Author:     Thomas Deutschmann <whissi@gentoo.org>
AuthorDate: 2021-04-28 18:24:18 +0000
Commit:     Thomas Deutschmann <whissi@gentoo.org>
CommitDate: 2021-04-28 18:26:22 +0000

    dev-db/percona-server: fix building against GCC 11
    
    Closes: https://bugs.gentoo.org/786462
    Package-Manager: Portage-3.0.18, Repoman-3.0.3
    Signed-off-by: Thomas Deutschmann <whissi@gentoo.org>

 dev-db/percona-server/Manifest                        | 2 +-
 dev-db/percona-server/percona-server-8.0.22.13.ebuild | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
Comment 9 Agostino Sarubbo gentoo-dev 2021-04-28 19:57:33 UTC
(In reply to Thomas Deutschmann from comment #7)
> Your automated bug reports are really painful in comparison to other
> CI/tinderboxes because you drop the failure on the maintainer ("Possible
> context" is often wrong) and maintainer should figure out why build failed
> whereas bug reports from toralf for example are at the point.
> 
> As maintainer I am thankful for bug reports but I don't want to spend much
> time on them just to understand why this bug was filed.
> 
> Anyway, sorry for being harsh.
> 
> Reproduced as described, incoming fix.

Hi, don't worry, no problem :)

CI is running for a while and the scope is to catch issues after commit. Said that the first thing to think after see the bug is that the bug exists.

The possible context of errors comes for an automatic grep about the common errors, so in this case:
"Could not find"
" error: "

I don't know where your stats about "is often wrong" comes, but you need to do make the stats considering the total amount of the bugs.

I understand that maintainer has to figure out what is happening if possible context of error does not help, but afterall the bug comes from a pretty-common system and the developer has the knowledge to understand the issue.
The bugs form CI are just a preview of what users will hit in a while.

Atm, since the amount of the bugs I do not have the time for doing it manually and I don't know if an automated solution will come at some point.

If, anyway, there is a need to be excluded from reports, I support this functionality. Everyone can choose from get 10 automated bugs or 2 full-explained bugs and do not know the existence of the other 8.