[prev in list] [next in list] [prev in thread] [next in thread] 

List:       boost-build
Subject:    Re: [Boost-build] bjam - win - ordering of obj files
From:       Anant Rao <arao () stratify ! com>
Date:       2009-12-21 20:50:02
Message-ID: 304CCAD472F6A84BB8F03EAA142CD80E2782EB0837 () corpmail11 ! calpurnia ! com
[Download RAW message or body]



-----Original Message-----
From: boost-build-bounces@lists.boost.org \
                [mailto:boost-build-bounces@lists.boost.org] 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build


[prev in list] [next in list] [prev in thread] [next in thread]