Re: [Boost-build] Problem with wchar_t

From: Vladimir Prus (ghost_at_[hidden])
Date: 2008-06-22 01:17:22

On Friday 20 June 2008 13:26:25 Tavares, Pedro (London) wrote:
> First, thanks for the earlier help in building boost 1.35.0 in msvc 7.1
> with STLport 5.1.5. I'm already using some of the libraries and all
> seems to be working well. However I'm now trying to build python but run
> into two related problems:
> 
> 1) I can only build static versions of python and several other libs
> and, as far as I can understand it, the problem is down to the native
> wchar issue as I get missing symbols that all seem to involve this type
> - STLport defaults to off and boost defaults to on

I don't know if that native wchar mismatch is the problem, or not. But if
that's a problem, then static versions of python and several other libs
will not actually work -- they will refer to the same missing symbols and
you'll get a link error when trying to use those static libraries (as opposed
to shared libraries, were you get error when linking the libraries themself)

> 
> 2) when I try to set "<native-wchar_t>on" 

You really mean <native-wchar_t>off, right? In any case, I don't see a feature
of that name defined anywhere.

> in the top level Jamroot I get 
> an error stating that the feature is not supported. I use the
> --build-type option defined in Jamroot to set this and other options -
> example below (somewhere around line 135 of Jamroot):
> 
> 		# Specify the build variants keyed on the build-type.
> 		local default-build,stlp-static-debug =
> 		    debug
> 		    <toolset>msvc-7.1
> 		    <stdlib>stlport-5.1.5
> 		    <threading>multi
> 		    <link>static
> 		    <runtime-link>static
> 		    <native-wchar_t>off

I'd suggest <cxxflags>-msvc-specific-option-to-mess-with-wchar-t
instead of this non-existent feature.

> 		    <define>_STLP_DEBUG
> 		    <define>_STLP_USE_STATIC_LIB
> 
> Finally, and I think this is unrelated, when I build a python extension
> dll (compiled against STLport 5.1.5 and boost 1.35.0) I am somehow
> forced to use shared libraries. 

Details please. I don't think a man with a gun breaks into your appartment
and say "use shared libraries or die"? The kind of libraries that are used
depend on the value of the 'link' feature, and this feature is set to 'shared'
when building python extensions, naturally, so you get shared linking to
boost.python. You can override this by copy-pasting the python-extension rule
and explicitly requesting static build of boost.python here. I don't think
anything "forces" shared build; but I don't know if using static will work,
especially if you have more than one extension loaded in one interpreter.
The runtime is completely different matter, it's controlled by 'runtime-link'
feature which is 'shared' by default for everything.
I don't actually remember how shared/static linkage is controlled for STLPort.

- Volodya