Re: [Boost-build] Problem with wchar_t

From: Tavares, Pedro \(London\) (pedro_tavares_at_[hidden])
Date: 2008-06-23 04:19:40

The default build for stlport builds all static or all dynamic versions.
So the error I get from the auto link may in fact refer to mixing dlls
with static runtime as you suggest (thanks for the warning). It is
simple enough to build static stlport libs with dll runtime but I
remember seeing a note elsewhere in these lists stating that boost.build
doesn't know about these versions. Unfortunately, and given your info,
this is ideally is what I should be trying to do. So enabling this build
method will be tricky unless I tinker with the insides of the stlport
aware components in boost and that will probably take me some time to
get to.

If I may make a suggestion to the boost.build developers, it would be
useful to have an feature to control which version of stlport is linked
in. Maybe <stlport-link> taking values of "static-rtlstatic",
"static-rtlshared" and "shared-rtlshared". Respectively these would link
to the "static", "staticx" and shared versions of the stlport library.

P

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

On Sunday 22 June 2008 12:33:38 Tavares, Pedro (London) wrote:
> 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).

Okay, enabling native wchar_t for stlport compilation seems even better.

> 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. 

As in, you get an error from autolink headers?

> 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?

I don't know why specifically building dll with static stlport is
disallowed.
I know that dll with static C runtime is considered risky, since then
each
dll will have it's own copy of important data structures, such as memory
manager.
On windows, such dlls can work, but require special care. On Linux, I'm
not
aware of any linker magic to even create such dlls. Probably, some such
issues are present with stlport too -- say, if some allocator objects
are global.

I suspect that if we're down to a specific question "why autolink
disallows
dll + static sltport combination", then folks at boost_at_[hidden]
mailing
list might have a better chance of knowing.

HTH,
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.
--------------------------------------------------------