Re: [Boost-build] bjam - win - ordering of obj files

Subject: Re: [Boost-build] bjam - win - ordering of obj files
From: Anant Rao (arao_at_[hidden])
Date: 2009-12-21 15:50:02

-----Original Message-----
From: boost-build-bounces_at_[hidden] [mailto:boost-build-bounces_at_[hidden]] On Behalf Of Phillip Seaver
Sent: Monday, December 21, 2009 8:38 AM
To: Boost.Build developer's and user's list
Subject: Re: [Boost-build] bjam - win - ordering of obj files

Anant Rao wrote:
>
> Hi,
>
>  
>
> My jamfile is like this on Windows to generate a dll.
>
>  
>
> lib  blah
>
> :   aprwrapper.cpp
>
>      file1.cpp
>
>      file2.cpp
>
> ;
>
>  
>
> The bjam-generated .rsp file is like this:
>
>  
>
> file1.obj
>
> file2.obj
>
> aprwrapper.obj
>
>  
>
> The generated DLL gives an 'Invalid access to memory' at run-time,
> whereas that generated with MSVC IDE works fine. (This is because of
> ordering of global statics).
>
> If I move aprwrapper.obj to the top in the .rsp file and just run the
> link command, then the bjam-generated DLL is fine.
>
>  
>
> My questions:
>
>    1. Is there a way to force bjam to place the obj files in a
>       particular order or at least in the same order as given by the
>       src file list - for the link step?
>    2. Assuming Microsoft published how it orders the obj files in its
>       IDE's link step, can bjam follow the same? This is the most
>       preferable way so that there's no discrepancy in output between
>       bjam and MSVC IDE.
>
>  
>
> Thanks in advance,
>
> Anant Rao
>

> As an aside, relying on the order of initialization of static objects is
> a bad idea.  I've run into cases where it worked fine for a while, then
> suddenly stopped working (usually crashing), even when compiling with
> msvc (IIRC - I've been using boost.build so long it's hard to remember
> for sure).  See What's the "static initialization order fiasco"?
> <http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.12>

> Phillip

Philip,
Thanks for taking time to respond to my email!
I agree 120% with you. C++ global static's are a pain in the you-know-where when it comes to their init ordering.

I 'fixed' the problem on MSVC by adding 
#pragma init_seg(lib)

But, a bigger issue for me is folks at my place saying that bjam is generating output diff from MSVC IDE and that they don't know what else it's doing differently.

I put a lot of effort to get 'bjam' work on Linux port and am now doing it on MSVC. I hate to see that work and more importantly, a beautiful tool like bjam, not used here on Windows.

Hence, my email was to understand and assert, hopefully with certainty, my co-workers that bjam does exactly generate the same output as MSVC.

Cheers,
Anant