Why does auto_link.hpp assume that debug versions of STLPort are built with _STLP_DEBUG?
Subj. Is there a [relatively non-invasive] way to break this dependency? As far as I can tell, STLPort itself makes no such assumption and builds in non-_STLP_DEBUG mode by default. I cannot use _STLP_DEBUG mode for other reasons... The platform is Windows Mobile 5, Visual Studio 2008 (VC9) Regards, ...Max...
Subj. Is there a [relatively non-invasive] way to break this dependency? As far as I can tell, STLPort itself makes no such assumption and builds in non-_STLP_DEBUG mode by default. I cannot use _STLP_DEBUG mode for other reasons...
The platform is Windows Mobile 5, Visual Studio 2008 (VC9)
It's to match what Boost.Build builds when you're using STLPort. If you're not using the Boost.Build built binaries then you might just as well disable auto-linking by defining BOOST_ALL_NO_LIB. HTH, John.
John Maddock wrote:
It's to match what Boost.Build builds when you're using STLPort. If you're not using the Boost.Build built binaries then you might just as well disable auto-linking by defining BOOST_ALL_NO_LIB.
Well, I did use Boost.Build (with VeecoFTC user jamfile for Windows Mobile) but apparently didn't trigger that logic. My libraries don't have "p" in their names either. Is "stdlib=stlport" the build property that triggers this? I got an error message back from bjam that the only supported value is "native"... I've got to say, Boost.Build is hard to wade through :( Especially if one tries to avoid reading the bjam code and only figure out the parameters. And it appears that my only option in avoiding _STLP_DEBUG is to forgo the automatic linking :( Regards, ...Max...
It's to match what Boost.Build builds when you're using STLPort. If you're not using the Boost.Build built binaries then you might just as well disable auto-linking by defining BOOST_ALL_NO_LIB.
Well, I did use Boost.Build (with VeecoFTC user jamfile for Windows Mobile) but apparently didn't trigger that logic. My libraries don't have "p" in their names either.
Then they're not built with STLPort.
Is "stdlib=stlport" the build property that triggers this? I got an error message back from bjam that the only supported value is "native"...
You need to add the path to STLPort to your user-config.jam file, something like: # Configure, specifying location of both headers and libraries using stlport : 5.1.4 : d:/download/open/stlport/STLport-5.1.4/stlport : d:/download/open/stlport/STLport-5.1.4/lib ;
I've got to say, Boost.Build is hard to wade through :( Especially if one tries to avoid reading the bjam code and only figure out the parameters.
And it appears that my only option in avoiding _STLP_DEBUG is to forgo the automatic linking :(
And Boost.Build. But remember that the vast majority of Boost libraries are "just a bunch of sources": you can build and link them any way you want from your IDE. HTH, John.
participants (2)
-
John Maddock -
Max Motovilov