From: Vladimir Prus (ghost_at_[hidden])
Date: 2008-06-22 05:06:39
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.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk