Linking to bcrypt creates problems (i.e. for CMake users)

[boostorg]

Linking to bcrypt creates problems (i.e. for CMake users)

[Lastique]

I'm not the maintainer, but linking with bcrypt is essential. The alternative is wincrypt, but it is deprecated and I don't think is universally available.

I also don't think introducing a dummy compiled library is an adequate solution, as this creates a bunch of other problems. For example, it affects packaging and downstream dependencies for no good reason.

IMHO, this should be solved entirely in CMake and headers. One option is stop defining BOOST_ALL_NO_LIB. Another is ignore it for linking non-Boost libraries.

[pdimov]

Relying on autolink to hide the problem doesn't seem correct; it doesn't work for GCC. But assuming we don't care about GCC, we've had the discussion of whether BOOST_ALL_NO_LIB should apply to non-Boost libraries more than once now, without any results.

I wouldn't be in support of enabling autolink for Boost libraries when using the CMake config files; this causes nothing but trouble (even if it does help to hide errors occasionally.)

[Lastique]

Yes, enabling auto-link is just a workaround, something we could consider for 1.78. The proper solution is to find a way to generate CMake config files for header-only libraries while keeping them header-only.

[Leon0402]

he proper solution is to find a way to generate CMake config files for header-only libraries while keeping them header-only

I would love to see this, so I can use Boost::uuid and others to correctly link all targets. In case of other libraries like Boost libraries, I also need to link other boost libraries explicitly like filesystem, which is confusing.

Should this maybe tracked in a separate issue? Perhaps in boost_install?

[jeking3]

I'm guessing someone has a workaround for this, for now - it might be useful to share that to help others in the same situation.

[pdimov]

I changed the CMake config files to only define the corresponding library-specific _NO_LIB macro instead of BOOST_ALL_NO_LIB, which takes care of this and similar issues on compilers that support autolinking. (boostorg/boost_install@258f786)

[jeking3]

@pdimov is there anything that needs to be done here as a result of that?

[pdimov]

I don't think we can do anything in practice, short of switching to a compiled library, which is unacceptable for many. So, closing.

[jeking3]

Thanks, worked hard to keep this header-only.