Re: [Boost-build] exelinkflags

Subject: Re: [Boost-build] exelinkflags
From: Vladimir Prus (ghost_at_[hidden])
Date: 2010-01-06 14:53:44

On Monday 21 December 2009 23:33:22 David Deakins wrote:

> 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,

thanks for explanation. I don't think it actually make my plan infeasible.
We can:

1. add 'wince' is new value of the 'target-os' feature
2. add this line in msvc.jam:

        flags msvc.link.exe LINKFLAGS <user-interface>console : /ENTRY:mainACRTStartup ;

3. rename 'link' action/rule to 'link.exe' so that the above actually works.

So, unless (1) sounds crazy to you I can make a patch and post for testing.

- Volodya