include/pybind11/numpy.h: gcc 4.8.4 does not have is_trivially_copyable #3270
Conversation
| @@ -319,7 +319,7 @@ template <typename T> using remove_all_extents_t = typename array_info<T>::type; | |||
|
|
|||
| template <typename T> using is_pod_struct = all_of< | |||
| std::is_standard_layout<T>, // since we're accessing directly in memory we need a standard layout type | |||
| #if defined(__GLIBCXX__) && (__GLIBCXX__ < 20150422 || __GLIBCXX__ == 20150623 || __GLIBCXX__ == 20150626 || __GLIBCXX__ == 20160803) | |||
| #if defined(__GLIBCXX__) && (__GLIBCXX__ < 20150422 || __GLIBCXX__ == 20150426 || __GLIBCXX__ == 20150623 || __GLIBCXX__ == 20150626 || __GLIBCXX__ == 20160803) | |||
There was a problem hiding this comment.
Yikes. Disappointed there isn't a better way to query this information.
There was a problem hiding this comment.
+1 but I'll merge this now to get us back to normal.
Question, to maybe do something different later in another PR: would there anything be lost if we simply made this
#if defined(__GLIBCXX__) && __GLIBCXX__ < 20160803
There was a problem hiding this comment.
I think the dates are the release dates, even if they are not sequential?
|
TBH: I missed that this was against v2.7 (I assumed master). |
Yep. |
|
Also, @mkoeppe it's best to target master, and then ask for it to be backported. If you do target a branch, I'd start the PR title with the branch name (usually in |
|
Not exactly practical to ask downstream projects to test with your master branch -- we are using a release and our concern is to fix that. By the way, I noticed that the directory layout of an sdist of the project differs from the directory layout of your repo, forcing me to hand-edit the patch. That's a bit unusual and something that you may want to fix in the medium term. |
|
This will not fix the release unless we make a new release. Generally, either make a PR against master or clearly note you are doing something non-standard. You are welcome to ask for a backport, we will do it if we can. If you make a patch to an upstream project, you should try to target the active development branch first. And clearly note if you don't. If someone hadn't caught this, 2.8 would be missing this fix, even if there is a 2.7.3 (or whatever is next). Not a huge criticism, and very happy for the patch, just a recommendation. The SDist has the CMake install instead of the source, so that the SDist is installable without requiring CMake. However the directory structure should be somewhat close, the main (only?) difference is the includes are already placed where they need to go for Python. |
|
Thanks for the explanations. |
henryiii
added
needs changelog
Description
Proposed fix for (#3269), tested on
ubuntu-trusty.Suggested changelog entry: