Skip to content
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

Can this create libboost_thread-mt.dylib for OS X systems? #48

Closed
grisaitis opened this issue Dec 5, 2017 · 8 comments
Closed

Can this create libboost_thread-mt.dylib for OS X systems? #48

grisaitis opened this issue Dec 5, 2017 · 8 comments

Comments

@grisaitis
Copy link

I'm trying to compile a program (caffe) that expects libboost_thread-mt in addition to libboost_thread. Installing boost with brew creates this library, but not with conda-forge.

How can I get this package to include the -mt library as well?

@grisaitis
Copy link
Author

This person seemed to have the same issue... also with caffe on Mac with conda (though not conda-forge): BVLC/caffe#4926 (comment)

I'd love to avoid brew and just use a conda-forge-installed boost and get all required libraries from that, if possible :)

@grisaitis grisaitis reopened this Dec 5, 2017
@jschueller
Copy link
Contributor

it's likely this is picked up by some dependency outside conda-forge
caffe builds fine on osx on conda-forge where all the dependencies are consistent

@jakirkham
Copy link
Member

We don't currently build Caffe on macOS. So it may not work fine.

That said, the actual C++ libraries referenced in this issue come from another package called boost-cpp. On all platforms it builds multithreaded libraries (hence -mt ;) ). However on Unix IIUC Boost prefers to leave the -mt off of the library names. This SO question is relevant here. Our options would be start tagging them as -mt, which is pretty easy to do, or symlink the -mt library names back to the non--mt library name. The latter is less likely to break existing Boost dependent packages. Thoughts?

@grisaitis
Copy link
Author

Thanks John and Julien!

As John suggested, using symlinks fixed my problem.

What would be the downsides to adding these symlinks to the boost-cpp recipe?

Should I have raised this issue in that feedstock repo?

$ ls -l ~/anaconda2/lib/libboost_thread*
...      Dec  5 00:33 libboost_thread-mt.a -> libboost_thread.a
...      Dec  5 00:33 libboost_thread-mt.dylib -> libboost_thread.dylib
...      Nov 15 12:34 libboost_thread.a
...      Dec  5 00:15 libboost_thread.dylib
$ conda list | grep boost
boost                     1.65.1                   py27_0    conda-forge
boost-cpp                 1.65.1                        1    conda-forge
libboost                  1.65.1               h8182a68_3  
py-boost                  1.65.1           py27h75ca4b9_3  

@scopatz
Copy link
Member

scopatz commented Dec 5, 2017

Should I have raised this issue in that feedstock repo?

Yes, probably :)

Please feel free to open an issue or a PR there!

@jakirkham
Copy link
Member

Glad that solved the issue.

I think adding the symlinks should be fine. The only slightly tricky thing is doing this systematically for all the Boost libraries, but we can discuss further in a PR.

Yeah it should have, but I can understand how that is not at all obvious. IOW don't worry about it. :) Welcome suggestions about how to better inform people of the purposes of these two packages.

@grisaitis
Copy link
Author

Thanks John :)

So is this package kind of like boost-python? How is it different from boost-cpp?

@jakirkham
Copy link
Member

np. Glad to help. :)

So is this package kind of like boost-python?

Basically.

How is it different from boost-cpp?

Historically this package did have all the Boost content (C++ and Python) much like the original boost package in defaults. However we decided to split out the C++ content from the Python content for various reasons, which became boost-cpp. To preserve compatibility, the Python content stayed here and this package became dependent on boost-cpp. Thus downstream packages requiring boost get the same behavior even though the C++ content doesn't live in this package any more. Hope that clarifies it.

Side note: We may look at better naming in the future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants