Boost logo

Boost-Build :

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,


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

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at