-
Notifications
You must be signed in to change notification settings - Fork 18.6k
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
MacOS: NVCC builds crashed after updating boost #1009
Comments
There was a boost / NVCC conflict in the past in #165 that we dealt with in 19bcf2b. Perhaps the merge of #1000 has brought it back. The previous solution was to hide the boost RNG through a facade. There should be a similar workaround for threads. The quickest fix would be to revert the migration from pthread to boost::thread if that is in fact the problem, but ideally we can reconcile it with CUDA. |
@jowens has found out the root cause of the problem. There is a work around trick that has been used in Caffe. |
@shelhamer @kloudkl Thanks for the comments! They confirm my research on this issue and the workaround I considered. I'll leave this open for now, and find a time to try implementing this workaround. |
Open source development rocks. |
Submitting PR #1010 , closing this thread. |
This means that Caffe::Get has to be moved to common.cpp, and loses its "inline" (but there are no real performance implications).
This means that Caffe::Get has to be moved to common.cpp, and loses its "inline" (but there are no real performance implications).
Recently I pulled the latest
dev
fromorigin
, which seemed to require boost 1.56 features that I didn't have on my boost 1.55 (homebrew version).After upgrading, all nvcc builds failed with some nvcc compatibility issue with boost (seems to be a known issue to nVidia).
I managed to solve one obvious issue with __int128, but still nvcc seems unhappy about a lot of boost header files in head_traits, hash, atomic, etc. Here's a (partial) snippet of the errors:
These seem to have been caused by the boost references in common.hpp (and/or some headers it included) which is indirectly included by all
.cu
files. Does anyone have a (quick and dirty, at least) solution to this?From the Googling I've done (and things I've tried that didn't work), the best solution so far seems to be that we separate all CUDA compilations from anything that's related to boost, and let only the host compiler care about boost related stuff -- which hopefully someone more familiar with the project structure would come up with a good workaround.
Thanks in advance!
The text was updated successfully, but these errors were encountered: