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

Alternatives to "copy every dll" for windows boost dynamic linking #10

Open
qqiangwu opened this issue Apr 1, 2015 · 3 comments
Open

Comments

@qqiangwu
Copy link

qqiangwu commented Apr 1, 2015

This line of code works unexpectedly when using clion layout. It copy dlls to the parent dir's bin rather than my project bin.

In addition, could you please just copy dlls we requested to bin, or a whole bunch of dlls are copied since I have many dlls of difference toolsets. I deem this will be quite easy since we can only copy dlls in ${Boost_LIBRARIES}

Thank you!

@Manu343726
Copy link
Contributor

I deem this will be quite easy since we can only copy dlls in ${Boost_LIBRARIES}

Sadly is not that easy, Boost has interdependencies to itself. That's why I picked the dumb approach of just copying all the dlls. You are right, this is a mess when having multiple boost toolchains. I'm open to any idea you have.

About the layout issue, this is probably a bug of mine. Boost support was released before clion compatible layout. Thanks for pointing out.

@Manu343726 Manu343726 changed the title file(COPY ${dll} DESTINATION ${CMAKE_SOURCE_DIR}/../bin/) Alternatives to "copy every dll" for windows boost dynamic linking Apr 1, 2015
@qqiangwu
Copy link
Author

qqiangwu commented Apr 2, 2015

@Manu343726 Indeed, It's quite upset to configure boost. Even Stroustrup complaint about this.

But in my case, when I use boost::filesystem, if I failed to specify boost::system in BII_FIND_BOOST, the linker will bark, so I know I have to write BII_FIND_BOOST(COMPONENTS filesystem system REQUIRED) rather than BII_FIND_BOOST(COMPONENTS filesystem REQUIRED). Then it's enough to merely copy filesystem.dll and system.dll.

In addition, even if we have to copy all dlls, at lease we should only copy dlls of the same toolset, the same boost version, the same thread model, and the same build type(debug or release). It will be way better than copy all dlls in boost/stage/lib.

@Manu343726
Copy link
Contributor

I'm on it. The problem with boost is that when you use dynamic linking that internal dependencies become dll dependencies. And some libs have dependencies to dlls that do not appear as boost components (Those we put on the find_package()/bii_find_boost() calls). In many cases is not as easy as:

for(component in ${BOOST_COMPONENTS})
    file(COPY ${component}.dll)
endfor()

That's pseudocode, of course

In addition, even if we have to copy all dlls, at lease we should only copy dlls of the same toolset, the same boost version, the same thread model, and the same build type(debug or release). It will be way better than copy all dlls in boost/stage/lib.

Completely agree. That should be easy: Make a folder on boost/stage/lib/ for each toolset, change b2call to point to the output folder of the toolset. Etc.

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

No branches or pull requests

2 participants