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

List:       boost-build
Subject:    Re: [Boost-build] exelinkflags
From:       David Deakins <ddeakins () veeco ! com>
Date:       2009-12-21 20:33:22
Message-ID: hgom2j$u8u$1 () ger ! gmane ! org
[Download RAW message or body]

Vladimir Prus wrote:
> 
> I think I have follow-up questions:
> 
> - Is this option always needed for CE?
> - Is it safe to assume that CE and normal windows are basically two
> different operating systems, even if similar
> - If so, can we have <target-os>ce (or 'wm', or whatever) and have that
> add the option automatically?
> 

This option is not always present for WinCE.  Here's where the 
complication comes in: My user-config.jam file includes the 
/SUBSYSTEM:WINDOWSCE linker option for the WinCE builds since this 
properly marks the binary files as WinCE binaries.  However, many of the 
regression test executables are what MSVC considers 'console' style 
executables and use 'main' as the entry point (rather than the WinMain 
entry point that 'standard' Windows/WinCE executables use).  These test 
executables will specify <user-interface>console (which translates into 
the /SUBSYSTEM:CONSOLE option) and which would select the correct 'main' 
entry point.  However, the /SUBSYSTEM:WINDOWSCE option will override 
SUBSYSTEM:CONSOLE (which is good, because then it makes WinCE binaries) 
but this has the side-effect of changing the default entry point back to 
WinMain.  So when you build the regression tests with Boost.Build, the 
link step will always fail with an 'unresolved external symbol WinMain'. 
  To work around this, I want to specify the /ENTRY:mainACRTStartup 
linker option when the executable has the <user-interface>console 
property to make sure the correct entry point is selected.  However, if 
this were a 'standard' executable, like when I build some of my real 
Windows CE applications (no <user-interface>console property), I don't 
want this ENTRY link option, because my entry point is actually the 
normal WinMainCRTStartup entry point.  In addition, in situations where 
a regression test needs to build a DLL along with the test, sometimes 
the <user-interface>console property migrates to the build of the DLL as 
well, so if I just used the standard 
<user-interface>console:<linkflags>/ENTRY:mainACRTStartup conditional 
method, then the DLLs fail to build because they need the 
DLLMainCRTStartup entry point.  So after all of that, I ended up adding 
the <exelinkflags> property and doing 
<user-interface>console:<exelinkflags>/ENTRY:mainACRTStartup.  I think 
there might be other ways to solve the problem, but that was the easiest 
one at the time.

Hopefully that all makes sense,
-Dave

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
[prev in list] [next in list] [prev in thread] [next in thread]