media-libs/opensubdiv: Allow compilation against CUDA 11 #18516
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Pull Request assignmentSubmitter: @redchillipadi media-libs/opensubdiv: @redchillipadi, @gentoo/proxy-maint Linked bugsIn order to force reassignment and/or bug reference scan, please append Docs: Code of Conduct ● Copyright policy (expl.) ● Devmanual ● GitHub PRs ● Proxy-maint guide |
gentoo-bot
added
self-maintained
Signed-off-by: Michał Górny <mgorny@gentoo.org>
Signed-off-by: Michał Górny <mgorny@gentoo.org>
Signed-off-by: Sam James <sam@gentoo.org>
Package-Manager: Portage-3.0.9, Repoman-3.0.2 Signed-off-by: Sam James <sam@gentoo.org>
Package-Manager: Portage-3.0.9, Repoman-3.0.2 Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Sam James <sam@gentoo.org>
Package-Manager: Portage-3.0.10.3-prefix, Repoman-3.0.2 Signed-off-by: Sam James <sam@gentoo.org>
Package-Manager: Portage-3.0.10.3-prefix, Repoman-3.0.2 Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Aaron Bauman <bman@gentoo.org>
Package-Manager: Portage-3.0.9, Repoman-3.0.2 Signed-off-by: Mike Pagano <mpagano@gentoo.org>
Upstream added a further unconditional sysroot include on Darwin, even if pkgconfig worked. Let's drop that. Package-Manager: Portage-3.0.10.3-prefix, Repoman-3.0.2 Signed-off-by: Sam James <sam@gentoo.org>
* Add maintainer-needed as no Git history exists for this eclass Signed-off-by: Aaron Bauman <bman@gentoo.org>
Signed-off-by: Aaron Bauman <bman@gentoo.org>
* Multiple tags and comments added * Some functions could use better @Usage * CVS shows pauldv@gentoo.org as the original committer to the tree. As such, he is now listed as the author of the eclass [1] * Assign to maintainer-needed as the eclass is still in use by several packages [1]: https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/db-use.eclass?view=log Signed-off-by: Aaron Bauman <bman@gentoo.org>
Package-Manager: Portage-3.0.11, Repoman-3.0.2 Signed-off-by: Craig Andrews <candrews@gentoo.org>
Package-Manager: Portage-3.0.11, Repoman-3.0.2 Signed-off-by: Craig Andrews <candrews@gentoo.org>
Package-Manager: Portage-3.0.11, Repoman-3.0.2 Signed-off-by: Craig Andrews <candrews@gentoo.org>
Package-Manager: Portage-3.0.11, Repoman-3.0.2 Signed-off-by: Craig Andrews <candrews@gentoo.org>
Bug: https://bugs.gentoo.org/747157 Package-Manager: Portage-3.0.11, Repoman-3.0.2 Signed-off-by: Zac Medico <zmedico@gentoo.org>
Package-Manager: Portage-3.0.10, Repoman-3.0.2 Signed-off-by: Thomas Deutschmann <whissi@gentoo.org>
This adds the @golang-rebuild set to portage to allow rebuilding all known Go software in the tree. This change only affects the live ebuild, but I will be adding it to other versions. Signed-off-by: William Hubbs <williamh@gentoo.org>
Closes: https://bugs.gentoo.org/758908 Signed-off-by: Matt Turner <mattst88@gentoo.org>
Closes: https://bugs.gentoo.org/758686 Package-Manager: Portage-3.0.11, Repoman-3.0.2 Signed-off-by: Louis Sautier <sbraz@gentoo.org>
Package-Manager: Portage-3.0.12, Repoman-3.0.1 Signed-off-by: James Le Cuirot <chewi@gentoo.org>
Package-Manager: Portage-3.0.12, Repoman-3.0.1 Signed-off-by: James Le Cuirot <chewi@gentoo.org>
Signed-off-by: Marek Szuba <marecki@gentoo.org>
Featuring proper multi-impl support including testing. Lua bindings have been confirmed to build, test and install fine for all five implementations currently listed in LUA_COMPAT. Speaking of testing, in order for it to be complete the file "test.png" produced for each enabled Lua target by rrd.graphv should be visually inspected. For obvious reasons automating this would be way more trouble than it is worth (an image recogniser as a build-time dependency???), that said I *have* inspected those images while testing whether LuaJIT as well as PUC Lua 5.2, 5.3 and 5.4 really are supported (although upstream documentation says "Lua 5.0 or newer" their build scripts only explicitly mention PUC Lua 5.0 and 5.1, and LuaJIT is not mentioned in either) and they looked fine for all five implementations. Closes: https://bugs.gentoo.org/752780 Signed-off-by: Marek Szuba <marecki@gentoo.org>
Basically just incorporating the patches we already apply to prev snapshot. Package-Manager: Portage-3.0.12, Repoman-3.0.2 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org>
Package-Manager: Portage-3.0.12, Repoman-3.0.2 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org>
Safer that way, using two different Lua implementations at build time and at run time can sometimes result in subtle problems that are a major pain in the neck to debug. Signed-off-by: Marek Szuba <marecki@gentoo.org>
This is neither allowed for compiled Lua modules nor, as demonstrated by the fact simply dropping this from linker options works just fine, actually needed in this case. Signed-off-by: Marek Szuba <marecki@gentoo.org>
Signed-off-by: Marek Szuba <marecki@gentoo.org>
Signed-off-by: Sebastian Pipping <sping@gentoo.org> Package-Manager: Portage-3.0.0, Repoman-2.3.23
This patchset includes a few upstream backports: - sh: Add sh4 fpu Implies folder - linux: Allow adjtime with NULL argument [BZ gentoo#26833] - __vfscanf_internal: fix aliasing violation (bug 26690) - iconv: Accept redundant shift sequences in IBM1364 [BZ gentoo#26224] - aarch64: Add unwind information to _start (bug 26853) - support: Provide a way to reorder responses within the DNS test server - support: Provide a way to clear the RA bit in DNS server responses - resolv: Handle transaction ID collisions in parallel queries (bug 26600) - resolv: Serialize processing in resolv/tst-resolv-txnid-collision - struct _Unwind_Exception alignment should not depend on compiler flags - Remove __warn_memset_zero_len [BZ gentoo#25399] - Remove __warndecl - aarch64: Fix DT_AARCH64_VARIANT_PCS handling [BZ gentoo#26798] Two of them are specual (noticed by Gentoo users): - "linux: Allow adjtime with NULL argument [BZ gentoo#26833]" fixes openntpd startup failure. - "__vfscanf_internal: fix aliasing violation (bug 26690)" fixes gcc-11 compatibility. Reported-by: Tobias Leupold Bug: https://bugs.gentoo.org/756316 Bug: https://sourceware.org/PR26833 Reported-by: andy Bug: https://bugs.gentoo.org/750992 Bug: https://sourceware.org/PR26690 Package-Manager: Portage-3.0.11, Repoman-3.0.2 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
EVBACKEND_LINUXAIO was added to libev-4.24
EVBACKEND_IOURING was added in libev-4.31
```
src/gevent/libev/corecext.c: In function '__pyx_pymod_exec_corecext':
src/gevent/libev/corecext.c:24279:36: error: 'EVBACKEND_LINUXAIO' undeclared (first use in this function)
24279 | __pyx_t_1 = __Pyx_PyInt_From_int(EVBACKEND_LINUXAIO); if (unlikely(!__pyx_t_1)) __PYX_ERR(0, 113, __pyx_L1_error)
| ^~~~~~~~~~~~~~~~~~
src/gevent/libev/corecext.c:24279:36: note: each undeclared identifier is reported only once for each function it appears in
src/gevent/libev/corecext.c:24284:36: error: 'EVBACKEND_IOURING' undeclared (first use in this function); did you mean 'EVBACKEND_PORT'?
24284 | __pyx_t_1 = __Pyx_PyInt_From_int(EVBACKEND_IOURING); if (unlikely(!__pyx_t_1)) __PYX_ERR(0, 114, __pyx_L1_error)
| ^~~~~~~~~~~~~~~~~
```
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
Signed-off-by: Brian Evans <grknight@gentoo.org>
Signed-off-by: Brian Evans <grknight@gentoo.org>
Signed-off-by: Brian Evans <grknight@gentoo.org>
Signed-off-by: Brian Evans <grknight@gentoo.org>
Includes PHP 8 support Signed-off-by: Brian Evans <grknight@gentoo.org>
Signed-off-by: Brian Evans <grknight@gentoo.org>
|
I tried rebasing this as was suggested to fix the too many broken packages warning. but now there are 524 extra commits that I don't need. My two commits for opensubdiv work fine here. Sometimes I think it is easier just to start again. |
|
I don't think you did the rebasing right... your pull request should only have a few commits, not 526. |
|
Yes please do start over. I guess you merged into your branch, not rebased? (Obviously you probably can still do a hard reset or rebase and drop those 526 commits, then wget your work from github and re-commit) |
|
I will close and recreate this PR |
Closes: https://bugs.gentoo.org/758944 Signed-off-by: Brian Evans <grknight@gentoo.org>
Signed-off-by: Brian Evans <grknight@gentoo.org>
This ebuild contains two changes which support compilation against nvidia-cuda-toolkit-11 Compared to nvidia-cuda-toolkit-10 which was gcc < 9 only, version 11 can be compiled with later versions of gcc. Currently the supported versions are <=nvidia-cuda-toolkit-9.0 ( <=sys-devel/gcc-5.4 ) nvidia-cuda-toolkit-9.1 ( <=sys-devel/gcc-6.4 ) nvidia-cuda-toolkit-9.2 to 10.1 ( <=sys-devel/gcc-7.3 ) nvidia-cuda-toolkit 10.1 to 10.2 ( <=sys-devel/gcc-8.4 ) nvidia-cuda-toolkit-11.0 ( <=sys-devel/gcc-9.3 ) nvidia-cuda-toolkit-11.1 ( <=sys-devel/gcc-10.4 ) Putting this testing in every ebuild that uses nvcc at build time is fragile and will be easily broken by updates to nvidia-cuda-toolkit. This version removes the gcc version checks in pkg_pretend, and the cuda eclass is used to obtain the permitted versions of gcc. If a non-supported version is selected a warning is displayed which gives instructions to the user on how to change their gcc and which version to use. An environment variable OSD_CUDA_COMPUTE_CAPABILITIES is used to obtain the desired GPU architecture, which is passed to cmake. If it is not set, a warning is displayed and the default 2.0 is chosen, which will probably fail unless the user has a Fermi card and is still using nvidia-cuda-toolkit-8. The value supplied by the environment variable is not currently checked against the allowed values. These vary with nvidia-cuda-toolkit versions but may include: 'compute_20','compute_30','compute_32','compute_35','compute_37', 'compute_50','compute_52','compute_53','compute_60','compute_61', 'compute_62','compute_70','compute_72','compute_75','compute_80', 'sm_20','sm_30','sm_32','sm_35','sm_37','sm_50','sm_52','sm_53', 'sm_60','sm_61','sm_62','sm_70','sm_72','sm_75'. The compute_XX use a virtual architecture and produce bytecode for JIT compilation, while the sm_XX compile against a real architecture immediately. It is not possible to choose a value to suit everybody as the lowest version of compute would support the largest range of graphics cards, but this prevents using features provided by later versions. As the user has chosen the appropriate compute value for their system, the CUDA 9 patch is no longer required. Signed-off-by: Adrian Grigo <agrigo2001@yahoo.com.au> Closes: https://bugs.gentoo.org/751382 Bug: https://bugs.gentoo.org/744517 Package-Manager: Portage-3.0.9, Repoman-3.0.2
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This ebuild contains two changes which support compilation against
nvidia-cuda-toolkit-11
Compared to nvidia-cuda-toolkit-10 which was gcc < 9 only, version 11
can be compiled with later versions of gcc.
Currently the supported versions are
<=nvidia-cuda-toolkit-9.0 ( <=sys-devel/gcc-5.4 )
nvidia-cuda-toolkit-9.1 ( <=sys-devel/gcc-6.4 )
nvidia-cuda-toolkit-9.2 to 10.1 ( <=sys-devel/gcc-7.3 )
nvidia-cuda-toolkit 10.1 to 10.2 ( <=sys-devel/gcc-8.4 )
nvidia-cuda-toolkit-11.0 ( <=sys-devel/gcc-9.3 )
nvidia-cuda-toolkit-11.1 ( <=sys-devel/gcc-10.4 )
Putting this testing in every ebuild that uses nvcc at build time is
fragile and will be easily broken by updates to nvidia-cuda-toolkit.
This version removes the gcc version checks in pkg_pretend, as
the user has already been warned about selecting appropriate versions
of gcc in a message that appears when installing nvidia-cuda-toolkit.
The second change is that nvidia-cuda-toolkit 11 removed support for
cards supporting compute_30. A patch is included that builds opensubdiv
against compute_35 when nvidia-cuda-toolkit 11 is used.
This is only a workaround as a proper solution would be a USE_EXPAND
variable to allow the user to select their exact compute version
supported, and compile optimised cuda binary files for their specific
card.
In particular this version chooses the lowest version of compute to
support the largest range of graphics cards, but this prevents using
features provided by later versions.
Signed-off-by: Adrian Grigo agrigo2001@yahoo.com.au
Closes: https://bugs.gentoo.org/751382
Bug: https://bugs.gentoo.org/744517
Package-Manager: Portage-3.0.9, Repoman-3.0.2