Re: [Boost-build] Problem with wchar_t

From: Tavares, Pedro \(London\) (pedro_tavares_at_[hidden])
Date: 2008-06-22 04:33:38

Thanks Volodya,

I came across <native-wchar_t> in several posts in this mailing list -
probably it applies to older versions of the build environment. I now
rebuilt STLport with wchar support and boost builds fine (although I
still need to test it all the versions are created - you are of course
correct about the missing symbols in the static libs but I'm not using
wchars in my own apps so the problem didn't arise with those).

Finally on the "being forced at gun point feature". The auto-link
feature actually fails the build if I use boost static boost and stlport
libs when building a dll with msvc 7.1. So unless I turn auto link off I
can't actually use static libs. Now, even if I turn off auto link or
disable the test in the header file, I'm left wondering why the writer
of this file would have considered this to be a significant problem...
(I guess too many hours trying to discover runtime problems that in the
end prove to be related to arcane memory options in linked in libraries
have made me paranoid!). What do you think?

Thanks again,
P

-----Original Message-----
From: boost-build-bounces_at_[hidden]
[mailto:boost-build-bounces_at_[hidden]] On Behalf Of Vladimir Prus
Sent: 22 June 2008 06:17
To: Boost.Build developer's and user's list
Subject: Re: [Boost-build] Problem with wchar_t

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
_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost-build
--------------------------------------------------------

This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing.
--------------------------------------------------------