Can this create libboost_thread-mt.dylib for OS X systems? about boost-feedstock HOT 8 CLOSED

Should I have raised this issue in that feedstock repo?

Yes, probably :)

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

from boost-feedstock.

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 :)

from boost-feedstock.

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

from boost-feedstock.

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?

from boost-feedstock.

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  

from boost-feedstock.

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.

from boost-feedstock.

Thanks John :)

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

from boost-feedstock.

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.

from boost-feedstock.