Re: [boost] Program Options failures (and fixes)

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-07-14 06:41:25

Hi John,

> I have some fixes for the program_options library on Win32 for you, first
> off here's the problem:
>
> On Win32 you must use the a dynamic runtime if you are building or using a
> dll: if you don't do this then separate runtimes/memory managers etc get
> linked to each module and the result is almost always a runtime crash some
> point.  

And the tests themself must be build with dynamic runtime, right? It would 
took me a lot of time to figure out.

> However you are also using std::locale and so have added 
> std::facet-support std::locale-support to your build requirements.  Doing
> so however, causes the static runtime to be used, so you're in a bit of a
> catch-22 situation here I'm afraid.  

Ah... that's troublesome.

> You've also failed to define 
> BOOST_ALL_DYN_LINK when *using* your dll - this is causing the mscv link
> failures.

Thanks for figuring this out. But... how comes that *everything* works except 
for importing a variable. I recall reading that __declspec(dllimport) on 
functions is just an optimization -- maybe this is the explanation.

> The patches below address both of these issues, tested with:
>
> VC7.1: everything passes.

Great. Once I'll have all-pass in main regression results, I'll switch all 
tests to use dynamic linking, to reduce the testing overhead.

> VC7.0: everything passes except the tests that use \u (unsupported).
>
> Intel 8 on vc7.1: everything passes.
>
> Intel 7.1 on vc7.1 everything pases except the tests that use \u
> (unsupported).
>
> Borland 5.6.4: all tests pass.
>
> Borland 5.5.1: Internal compiler error in function from_8bit, haven't
> investigated further yet.
>
> The fact that these tests do pass with Intel, possibly means that
> std::facet-support could be deprecated - it looks like Intel have fixed
> that problem with their recent patches.  However, you may still experience
> problems with Metrowerks - I think there is any way around this - the dll
> version of the library is going to be unusable with that compiler.

That's not good, but anyway, I think dropping DLL on one compiler is not so 
terrible.

> One final thing: you declare the environ variable in your sources, which is
> leading to warnings from MSVC and Intel about conflicting
> dll-specifications for that variable, perhaps you should include the header
> required rather than defining the variable yourself (unistd.h when
> BOOST_HAS_UNISTD_H is defined, or stdlib.h on WIN32)?

Yes, though my man pages say that on Linux, this variable must be defined in 
user program. I'll make an attempt to define it only when not on windows.

> Index: build/Jamfile

Thanks for helping out! I've comitted the modification you've suggested.

- Volodya