[wince] Building Boost for Windows CE... some progress and problems...

[Andy Schweitzer]

I've been trying to build boost for windows CE. I've made some progress,
      but it's not really working yet. I was asked off-list about it, so
I thought I'd post a report and some questions.

Summary:
Basically, I managed to build STLport libs/dlls for CE, using vc8 and
vc9, with minor mods to STLport. STLport test program runs, apparently
successfully on the CE emulator. A test program can link to STLport libs
and use them successfully.

Then, with a modified user-config.jam (based on VeecoFTC's), and the
proper bjam command line. I was able to build some of the boost
libraries. I have only gotten static link and vc8 building. My dlls fail
to link to STL. My vc9 has include problems. I haven't really
investigated either of these. Compiler errors result from parts of the
standard C++ libraries that are missing from CE (and not provided by
STLport). I have satisfied the compiler by providing stub
implementations - which of course wouldn't actually work, but do build.

I linked a test program to some of the built libraries and ran it
successfully in the emulator. I would like to run boost::test on the
emulator to see what works and what doesn't. So far I have been able to
build boost::test, but not the first individual test case I tried,
libs/system/test. I got an ARM vs THUMB link error which I have yet to
investigate.

Questions:
-- Any suggestions C++ standard functions missing from CE?
    -- Has anyone tried wcelibex? It looks appropriate. All its
functions start with "wce_", and I think for it to work with well with
boost and STLport, those would have to be wrapped into calls with the
standard names and put into STL namespace.

-- Any idea why vc9 would have problems finding the right include
directories when vc8 does not? I diffed the setup batch files and they
appear to be indentical.

-- Any ideas on why machine conflicts (X86 vs ARM and ARM vs THUMB) seem
to occur in some cases but not others?

====================================================
Details (for reference - comments welcome from anyone
          who wants to pore through details):
====================================================
Tools:

* vc8, vc9
     I had to un-install IE8 before I could create
     Smart Device projects. Based on web searches
     there seems to be an on-going problem with
     some solutions that didn't work for me.

* CE SDKs
     STANDARDSDK_500

* Ran code from WM5 emulator

* bjam

====================================================
Code (modifications included in attached zip file):

--STLport-5.2.1--

* added batchfiles to setup and build STL
     They assume an env var STL_ROOT pointing
     to, STLport-5.2.1 dir.
     if you put them there and run
     STL_evc8_ARMV4I_WCE500.bat or
     STL_evc9_ARMV4I_WCE500.bat, they
     might "just work"

* build/Makefiles/nmake/evc4.mak - added define of
     ARMV4I and use of THUMB

* src/details/fstream_win32io.cpp - open() failed
     until I hacked in code to ignore failing
     call to SetFilePointer. Not sure what is
     going on here, or if hack is appropriate.

* stlport/using/cstring - hacked in stub of strerror
     (boost::system needs it)


--Boost--

* used svn to download trunk a couple weeks ago

* tools/build/v2/tools/user-config.jam - adds toolsets
     for vc8+CE+STLport and vc9+CE+STLport

* libs/system/test/error_code_user_test.cpp - stubs
     errno and call to std::remove.

* libs/program_options/src/parsers.cpp
     stubbed environ

* libs/iostreams/src/file_descriptor.cpp
     hacked out some includes
     stubbed _get_osfhandle

* libs/iostreams/src/mapped_file.cpp
     added TEXT macro to get wider chars
     hacked out try_may_file

* libs/filesystem/src/operations.cpp
     hacked out some includes
     stubbed in Get/SetCurrentDirectory,
     GetFullPathName, GetShortPathName

* boost/test/impl/cpp_main.ipp
     stubbed in getenv

* These built at least enough successfully that static link succeeded.
     static-link successfully built:
         system
         filesystem
         iostreams
         program_options
         test
         thread
         signals
         date_time
     I could not link to them from an emulator test-program until I used
     --build-type=complete (which nevertheless reported erors).
     I actually tried and successfully linked to:
         system
         filesystem
         program_options
         iostreams

* build command, that at least succeeded with static link:

bjam --with-system --with-thread --with-signals --with-date_time^
  --with-filesystem --with-program_options --with-iostreams^
  --with-test --build-type=complete^
  toolset=msvc-8.0~wm5~stlport5.2^
  stdlib=stlport-5.2~evc8~arm > bjam.txt 2>&1

* failures:
     regex - fails on strxfrm
     serialization
     graph - fails on iswalnum


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

[Andy Schweitzer]

Andy Schweitzer wrote:
> -- Any ideas on why machine conflicts (X86 vs ARM and ARM vs THUMB) seem
> to occur in some cases but not others?

Elaborating on that specific question, I'm trying to build individual
libraries' tests, but I get link errors:

fatal error LNK1112: module machine type 'X86' conflicts with target
machine type 'THUMB'


I think that means that the test library is built as x86, which
complains when it links against STLport's THUMB. It's as if my toolset
wasn't being seen. Any idea what is going on here?

I do this:

cd %BOOST_ROOT%\libs\system\test
bjam link=static toolset=msvc-8.0~wm5~stlport5.2
stdlib=stlport-5.2~evc8~arm > %BOOST_ROOT%\bjam.txt

and I get:
...patience...
...found 479 targets...
...updating 24 targets...
msvc.link
..\..\..\bin.v2\libs\system\test\error_code_test.test\msvc-8.0~wm5~stlport5.2^
\debug\asynch-exceptions-on\link-static\stdlib-stlport-5.2~evc8~arm\^
threading-multi\error_code_test.exe
stlportstld.5.2.lib(stlportstld.5.2.dll) : fatal error LNK1112: ^
module machine type 'X86' conflicts with target machine type 'THUMB'

I *think* I typed toolset correctly because if I just add --with-system
and cd %BOOST_ROOT%, and call it, I get no errors.

bjam --with-system link=static toolset=msvc-8.0~wm5~stlport5.2
stdlib=stlport-5.2~evc8~arm > %BOOST_ROOT%\bjam.txt

I got the same thing with the 'any' library, which made me wonder if it
is something about how I am interacting with test jamfiles.

thanks

Andy

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

[Juergen Hunold-2]

Hi Andy,

On Monday 15 June 2009, Andy Schweitzer wrote:
> Andy Schweitzer wrote:

> \debug\asynch-exceptions-on\link-static\stdlib-stlport-5.2~evc8~arm\^
> threading-multi\error_code_test.exe
> stlportstld.5.2.lib(stlportstld.5.2.dll) : fatal error LNK1112: ^
> module machine type 'X86' conflicts with target machine type 'THUMB'

Are you sure that you really have a cross build of STlport ? This
message indicates that the STLport dll is x86 instead of THUMB.

and please post the complete linker command line next time.

Yours,

Jürgen
--
* Dipl.-Math. Jürgen Hunold       ! Ingenieurgesellschaft für
* voice: ++49 511 262926 57       ! Verkehrs- und Eisenbahnwesen mbH  
* fax  : ++49 511 262926 99       ! Lister Straße 15
* juergen.hunold@...        ! www.ivembh.de
*
* Geschäftsführer:                ! Sitz des Unternehmens: Hannover
* Prof. Dr.-Ing. Thomas Siefer    ! Amtsgericht Hannover, HRB 56965
* PD Dr.-Ing. Alfons Radtke       !

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

[Andy Schweitzer]

Juergen Hunold wrote:

> Hi Andy,
>
> On Monday 15 June 2009, Andy Schweitzer wrote:
>> Andy Schweitzer wrote:
>
>> \debug\asynch-exceptions-on\link-static\stdlib-stlport-5.2~evc8~arm\^
>> threading-multi\error_code_test.exe
>> stlportstld.5.2.lib(stlportstld.5.2.dll) : fatal error LNK1112: ^
>> module machine type 'X86' conflicts with target machine type 'THUMB'
>
> Are you sure that you really have a cross build of STlport ? This
> message indicates that the STLport dll is x86 instead of THUMB.
>
> and please post the complete linker command line next time.
>

link command is:
link /NOLOGO /INCREMENTAL:NO /DEBUG /subsystem:console
/out:"..\..\..\bin.v2\libs\system\test\error_code_test.test\^
msvc-8.0~wm5~stlport5.2\debug\asynch-exceptions-on\link-static^
\stdlib-stlport-5.2~evc8~arm\threading-multi\error_code_test.exe"
/LIBPATH:"C:\nan\stl\STLport-5.2.1\lib\vc9" /subsystem:windowsce,5.01
/machine:THUMB /NODEFAULTLIB:oldnames.lib /NODEFAULTLIB:libc.lib
/STACK:262144,4096 coredll.lib corelibc.lib ole32.lib oleaut32.lib
uuid.lib commctrl.lib /VERBOSE:LIB

user-config.jam says:
using stlport : 5.2.1 : "C:/nan/stl/STLport-5.2.1" :
                 "C:/nan/stl/STLport-5.2.1/lib/vc9" ;
using stlport : 5.2~evc8~arm :
                 C:/nan/stl/STLport-5.2.1/stlport :
                 C:/nan/stl/STLport-5.2.1/lib/evc8-arm  ;

bjam command line says ... stdlib=stlport-5.2~evc8~arm
... but bjam seems to be picking up the first one, which is in fact X86.
This doesn't happen for bjam of system lib itself but it does for
system\test. Is this intentional? Does the test jamefile need to be
explicitly extended to support other toolsets?

Commenting out the stlport statement makes it pick up the second one...
but then that fails to link to WinMain. In fact it just has main, not
WinMain. it seems like other extensions might be necessary to make the
test work in CE. Is this a known issue?

> Yours,
>
> Jürgen

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

[David Deakins]

Andy Schweitzer wrote:
>
> Commenting out the stlport statement makes it pick up the second one...
> but then that fails to link to WinMain. In fact it just has main, not
> WinMain. it seems like other extensions might be necessary to make the
> test work in CE. Is this a known issue?
>

In order to get the console tests to link properly for WinCE, some
additional machinery is required.  You want the link command line to
include the additional /entry:mainACRTStartup option to say that it
should look for main and not WinMain as the entry point.  I do this with
the following statement at the end of my user-config.jam:

project
: requirements
<toolset>msvc-9.0~wm5~stlport5.2,<user-interface>console:<linkflags>/entry:mainACRTStartup
;

-Dave

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

[Andy Schweitzer]

David Deakins wrote:

>
> In order to get the console tests to link properly for WinCE, some
> additional machinery is required.  You want the link command line to
> include the additional /entry:mainACRTStartup option to say that it
> should look for main and not WinMain as the entry point.  I do this with
> the following statement at the end of my user-config.jam:
>
> project
> : requirements
> <toolset>msvc-9.0~wm5~stlport5.2,<user-interface>console:<linkflags>/entry:mainACRTStartup
>
> ;

 >
 > -Dave
 >

Thanks, that worked!

The build runs to completion, and tries to execute the resulting exes,
which fails, since they are Windows CE exes. I think the other lines in
VeecoFTC's user-config.jam somehow plug the WM5TestLauncher into the
boost test infrastructure so that it downloads the exes to an actual CE
device (or maybe an emulator).

I manually copied the files to my emulator and called CreateProcess on
them. That fails with GetLastError 126, "The specified module could not
be found". "dumpbin /imports system_error_test.exe" shows that
system_error_test.exe links to msvcr80d.dll. Do you know of a way to fix
this?

Andy

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

[willem hengeveld]

Andy Schweitzer <a.schweitzer.grps <at> gmail.com> writes:

> I manually copied the files to my emulator and called CreateProcess on
> them. That fails with GetLastError 126, "The specified module could not
> be found". "dumpbin /imports system_error_test.exe" shows that
> system_error_test.exe links to msvcr80d.dll. Do you know of a way to fix
> this?


if you build with -D_DEBUG, CrtDbgReport is used in "C:/Program Files/Microsoft
Visual Studio 8/VC/ce/include/altcecrt.h", which is in msvcr80d.dll


you can copy "C:/Program Files/Microsoft Visual Studio
8/VC/ce/Dll/armv4i/msvcr80d.dll"
manually to the \windows directory on your device / emulator.

it is used to print exception information when a microsoft STL assert fails.

willem


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