You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi,
I've left a comment in #95 (comment) about the same kind of bad behavior with BOOST_AUTO_LINK_TAGGED or BOOST_AUTO_LINK_SYSTEM enabled.
Regards,
Colin Chargy
I agree with you completely, as noted in my comment of #95, that it would be better not to use boost autolink for non-boost libraries.
Did not want to go down that path myself, but left that to original developers, because I wasn't sure what was the initial reason to use boost autolinking on non-boost libraries.
However, I'd suggest you open new issue since this one is closed.
In addition please note that, although source of the problem is the same, the problem itself would be different (prior to my fix) when using BOOST_AUTO_LINK_NOMANGLE compared to using BOOST_AUTO_LINK_TAGGED or BOOST_AUTO_LINK_SYSTEM.
If BOOST_AUTO_LINK_NOMANGLE was defined, it would become undefined and all subsequent linking of boost libraries would start behaving differently (as if BOOST_AUTO_LINK_NOMANGLE was not defined).
On the other hand if BOOST_AUTO_LINK_TAGGED or BOOST_AUTO_LINK_SYSTEM, linking of external libraries in uuid would fail but other boost libs would not be affected.
Hence, due to difference in problem manifestation, BOOST_AUTO_LINK_TAGGED or BOOST_AUTO_LINK_SYSTEM, probably deserve separate issue :).
Undefining BOOST_AUTO_LINK_NOMANGLE, if it was previously defined, breaks desired behavior of all the boost libraries included after uuid.
Suddenly you will get situation where half of headers link against libname.lib and other half to "fully qualified library name".lib.
The text was updated successfully, but these errors were encountered: