-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
C++11 use flags may need to go completely. #24
Comments
This is the logic:
|
This will cause problems for nvidia users as CUDA only plays nice with GCC 4.8. although building with 4.9 is possbile with a hack. This means that cuda users will not be able to use boost 5+ and prevent the use of osl or anything which requires c++11 in the system. |
How about a c++ use expand similar to PYTHON_SINGLE_TARGET? |
I have been in discussion with Toolchain and Boost teams about C++11. They were all in agreement that the ABI switch will need to happen as it's now in Boost. I think you saw the bit of code that showed that it will use C++11 if available. The discussion is here: They are switching on C++11 for all compilers 4.9x and above. So for now, I think we are best to have ebuilds that turn off C++11 and do a rev bump when they flip the switch. This will ensure ABI compatibility. |
Sorry, I am on holidays so won't have much time again until next week. Thanks for putting my comments forward in the discussion. This is a complex issue, so its good to have many teams involved. Turning off C++11 in OSL seems like the best option as you say, until the switch is flipped. |
@redchillipadi I ran into a slight hitch. LLVM must have C++ 11 ABI, so why they have a use flag is beyond me. So I had to make the max version of boost 1.60. I could use that patch, but that would be a temp thing and they don't like temp patches. I may try to make a patch in the ebuild itself, so it disappears on the rev bump, so to speak. Then I can have any version of Boost. They are good points you had, so I tried to find ways and put ideas forth to make sure some users don't get left behind. nVidia really needs to up the ante and get GCC 5.x working with CUDA. |
Update: Boost 1.62 will be getting C++11 support in the tree. GCC 4.9+ will all be supported. Once that happens, we will need to compile with C++11 only. The instructions to do so are here: EDIT: Meant 1.62 and not 1.61. I was hoping 1.61 would get support, but it looks like they are bypassing that and will be dropping it in favour of 1.62. |
C++11 is now default. :) @redchillipadi There is a Pull Request to get CUDA v8 in portage, which is compatible with GCC 5.3! This means great things for Blender and Depends. |
I can't wait for this! @redchillipadi There is a Pull Request to get CUDA v8 in portage, which is compatible with GCC 5.3! This means great things for Blender and Depends. — {"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/dracwyrm/gentoo-ebuilds","title":"dracwyrm/gentoo-ebuilds","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/dracwyrm/gentoo-ebuilds"}},"updates":{"snippets":[{"icon":"PERSON","message":"@dracwyrm in #24: C++11 is now default. :)\r\n\r\n@redchillipadi There is a Pull Request to get CUDA v8 in portage, which is compatible with GCC 5.3! This means great things for Blender and Depends."}],"action":{"name":"View Issue","url":"https://github.com/dracwyrm/gentoo-ebuilds/issues/24#issuecomment-253195322"}}} |
It may not be proper Gentoo standard of use flags to have one that controls C++11 enabling/disabling.
So, I was thinking about hard setting c++11 to on for GCC 5+. We can use the $(gcc-version) function from the toolchain-funcs eclass. GCC 5 by default wants to compile in C++11 standard anyways, so why not let it? I filed a bug report saying that boost should do as well. If everything GCC 5 is compiled C++11, then no incompatibilities at all with anything.
Then OSL may need more logic that if boost is enabled, then compile with C++98 instead. Then once Boost is ebuild is fixed to allow C++11 compiling, then OSL can be compiled with C++11 and Boost.
The text was updated successfully, but these errors were encountered: