Boost logo

Boost-Build :

Subject: Re: [Boost-build] exelinkflags
From: David Deakins (ddeakins_at_[hidden])
Date: 2009-12-21 15:33:22


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


Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk