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.