Summary: | dev-libs/libclc-0.2.0_pre20160209 fails to build - ./ptx-nvidiacl/lib/workitem/get_group_id.cl:5:19: error: use of unknown builtin '__builtin_ptx_read_ctaid_x' [-Wimplicit-function-declaration] | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Graham Young <gcyoung> |
Component: | Current packages | Assignee: | Gentoo X packagers <x11> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | chain, jano.vesely, jason.mours, kuenstler, llvm, O01eg, Philippe.PERET, r.emanuel.eriksson, tb, tsmksubc |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 536984 | ||
Attachments: | result of broken off compilation |
Description
Graham Young
2017-03-10 21:53:09 UTC
I am seeing an almost-identical set of errors on a current stable AMD64 system with GCC 5.4.0. Same, 3 different machines, roughly speaking the same set of errors, encountered when updating to gcc 5.4.0 Same bug. gcc-5.4.0-r3 Same here x86_64 kernel 4.9.16 - newly migrated to gcc 5.4.0. Although the package is compiled with clang. I am also getting this error on AMD64 and GCC 5.4.0-r3. Seems to be fixed in dev-libs/libclc-0.2.0_pre20160921 though, because I can compile that without errors. According to this: https://github.com/voidlinux/void-packages/issues/4721 later versions should compile ok. I tested with dev-libs/libclc-0.2.0_pre20160921, and it actually works. Since 0.2.0_pre20160209 is the latest stable, and it currently does not compile within the "latest stable" environment, I suggest to stabilize a newer release which does compile (eg: 0.2.0_pre20160921). If it helps to get moving on:--I masked the program and keyworded version *-0.2.0-pre20160921 which compliled OK I agree with Lazlo's comments in "comment #6" regarding standardizing on the build version that he says works for him. I have also tried that build as part of assembling a Gentoo-based "zoneminder" server. It got me past unresolved issues compiling "libclc" that prevented "zoneminder" from building for my specific setup. Same bug here with gcc 6.3. I wonder how I got this built before... This system has been running on 5.x. for quite a while. Like Emanuel said in comment #5 dev-libs/libclc-0.2.0_pre20160921 works. This has nothing to do with GCC version. libclc is always compiled using llvm/clang. The ptx builtin names were changed in in clang r274770 (present in latest 3.9, 4.0, and 5.0). you need libclc version that includes 3d39fb557be2e349ded2d2055211b2757627f40b ("ptx: Fix builtin names after clang r274770") in order to compile. (In reply to Jan Vesely from comment #10) > This has nothing to do with GCC version. libclc is always compiled using > llvm/clang. > > The ptx builtin names were changed in in clang r274770 (present in latest > 3.9, 4.0, and 5.0). > you need libclc version that includes > 3d39fb557be2e349ded2d2055211b2757627f40b ("ptx: Fix builtin names after > clang r274770") in order to compile. Thanks for the clarification Jan. I'm maintaining Mesa by myself these days, and I don't have the hardware, time, or energy to maintain the OpenCL bits. Would you be interested in taking those portions (dev-libs/libclc most notably) on as a maintainer by proxy? I'd be happy to get something in tree that works. Pull requests on GitHub are easiest, but bugs with patches are most welcome as well. I've been thinking of package.use.mask'ing Mesa's opencl USE flag and package.masking dev-libs/libclc unless someone can maintain it... (In reply to Matt Turner from comment #11) > (In reply to Jan Vesely from comment #10) > > This has nothing to do with GCC version. libclc is always compiled using > > llvm/clang. > > > > The ptx builtin names were changed in in clang r274770 (present in latest > > 3.9, 4.0, and 5.0). > > you need libclc version that includes > > 3d39fb557be2e349ded2d2055211b2757627f40b ("ptx: Fix builtin names after > > clang r274770") in order to compile. > > Thanks for the clarification Jan. > > I'm maintaining Mesa by myself these days, and I don't have the hardware, > time, or energy to maintain the OpenCL bits. Would you be interested in > taking those portions (dev-libs/libclc most notably) on as a maintainer by > proxy? I'd be happy to get something in tree that works. Pull requests on > GitHub are easiest, but bugs with patches are most welcome as well. > > I've been thinking of package.use.mask'ing Mesa's opencl USE flag and > package.masking dev-libs/libclc unless someone can maintain it... I can try, but I'm not sure if I'm the right person for this. I don't know much about ebuilds, and I don't have a gentoo box that could use mesa opencl. FWIW, the last commit that worked with llvm-3.9 is r282106. starting from r309820 the build script works with python3. other than that, latest master is always the best bet and it should work with llvm-4,5,6. NVPTX/NVVM isn't really that useful, you can probably use it with clang to have OCL wrapper around CUDA, but I don't think anyone does that, at least not using the upstream componenets. clover GCN needs libclc: amgcn-mesa-mesa3d if (LLVM >=4 && mesa>=13.0) else amdgcn-- clover r600 needs libclc: r600-- Bug has been referenced in the following commit: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=87929d9f6bfe62770cb13547583425e6f2755a59 commit 87929d9f6bfe62770cb13547583425e6f2755a59 Author: Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> AuthorDate: 2017-09-08 12:38:21 +0000 Commit: Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> CommitDate: 2017-09-08 12:38:21 +0000 dev-libs/libclc: depend on compatible llvm versions Bug: https://bugs.gentoo.org/show_bug.cgi?id=612258 Package-Manager: Portage-2.3.6, Repoman-2.3.1 dev-libs/libclc/libclc-0.2.0_pre20160209.ebuild | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) The commit which fixes the compile failure is present in 0.2.0_pre20160921 and later. The dependencies on 0.2.0_pre20160209 have been updated. Marking this bug as fixed. *** Bug 618928 has been marked as a duplicate of this bug. *** *** Bug 614476 has been marked as a duplicate of this bug. *** |