-- Main.randomaniac777 - 14 Nov 2008

-- Main.terrencebarr - 04 Jun 2008

mt.exe -manifest romgen.exe.manifest -outputresource:romgen.exe

-- Main.michael_heinrichs - 26 Nov 2007

• Tools Setup on Windows

• Introduction

• Introduction

cp $OUTPUT/cldc/win32_i386/romgen/app/romgen.exe.manifest $OUTPUT/cldc/win32_i386/dist/bin

Update: Copying romgen.exe.manifest appears necessary on Windows XP systems but not necessary on Windows 2000.

• [[#BuildIntroduction][Introduction]

• Applying fixes to the configuration files

• Running the resulting phoneME Feature binary on Windows

Applying Fixes to the Configuration Files

Running the resulting phoneME Feature binary on Windows

Running the phoneME executable on a system that has Microsoft Visual Studio installed

Just go to the $OUTPUT/midp/bin/i386 directory and run runMidlet.exe as described in the Getting Started Guide. It should work fine.

• [[#IntroductioN][Introduction]

• Building phoneME Feature on Windows

• Build scripts

Tools Setup on Windows

Applying Fixes to the Build

Fixing javacall

Edit javacall/build/vc/rules.gmk

In lines 53 and 54, change the compiler flags definition. Add the flags _CRT_SECURE_NO_DEPRECATE and _CRT_NONSTDC_NO_DEPRECATE and change the treat-warnings-as-errors level from /W3 to /W2. It should now look something like this:

LOCAL_CFLAGS_debug = -MDd -Gm -GX -Zi -Od -D_DEBUG -D_MBCS -D_LIB -YX -FD -GZ -W2 /D_CRT_SECURE_NO_DEPRECATE /D_CRT_NONSTDC_NO_DEPRECATE
LOCAL_CFLAGS_nodebug = -MD -GX -O2 -D_MBCS -D_LIB /YX -FD -W2 /D_CRT_SECURE_NO_DEPRECATE /D_CRT_NONSTDC_NO_DEPRECATE

Fixing PCSL

Edit pcsl/makefiles/share/vc.gmk

In lines 46-50, change the compiler flags definition. Add the flags _CRT_SECURE_NO_DEPRECATE and _CRT_NONSTDC_NO_DEPRECATE and change the treat-warnings-as-errors level from /W3 to /W2. It should now look something like this:

ifeq ($(USE_DEBUG), true)
CFLAGS= /WX /c /W2 -Zi -Od -MDd /D_CRT_SECURE_NO_DEPRECATE /D_CRT_NONSTDC_NO_DEPRECATE
else
CFLAGS= /WX /c /W2 /D_CRT_SECURE_NO_DEPRECATE /D_CRT_NONSTDC_NO_DEPRECATE
endif

The PCSL build should run fine now.

Fixing CLDC

For CLDC, be sure to set the environment variable USE_VS2005 to true (as done in the build-phoneME.sh above) before starting the build. It takes care of a lot of compiler warnings.

After the CLDC build successfully completes, you may need to copy romgen.exe.manifest from $JVMBuildSpace/cldc/win32_i386/romgen/app to $JVMBuildSpace/win32_i386/cldc/dist/bin. Otherwise romgen.exe may fail during the MIDP build with a message about a missing DLL.

Update: With the latest source base copying romgen.exe.manifest does not seem to be necessary.

Update: The CLDC build failed when I attempted the SJWC JavaCall build. I get the same link error as for MIDP below. I fixed it by adding a line to cldc/build/javacall_i386_vc/javacall_i386_vc.cfg:

LINK_FLAGS+=-nodefaultlib:libcmt.lib

Note: Towards the end of the CLDC build there are still a lot of warning messages around compiler and linker options, such as /GB, /DEBUGTYPE, and multiple defined symbols regarding LIBCMT. The build should complete successfully despite these warnings.

Fixing MIDP

The MIDP link will not work unless you add a flag. Do this by adding the following line to midp/build/win32/Platform.gmk:

LD_FLAGS+=-nodefaultlib:libcmt.lib

After this, the MIDP build should proceed successfully.

You will get lots of warnings about method deprecation and an unsupported compiler option /GB, but it should stagger through to the end without errors.

Running the phoneME executable on a system that has Microsoft Visual Studio installed

Just go to the $OUTPUT/midp/bin/i386 directory and run runMidlet.exe as described in the Getting Started Guide. It should work fine.

A Working Setup

Build Scripts

Table of Contents

• [[#Introduction][Introduction]
• Tested versions of phoneME Feature
• Applying fixes to the build
• Building phoneME Feature on Windows
• A working set up

#Introduction

Applying Fixes to the Build

-- Main.emil_kvarnhammar - 26 May 2007

• The MR2 b13 as well as b20 build available via the subversion repository

• The MR2 b13 as well as b20 build available via the subversion repository (latest available version as of 28 Mar 2007)

Fixing javacall

Edit javacall/build/vc/rules.gmk

In lines 53 and 54, change the compiler flags definition. Add the flags _CRT_SECURE_NO_DEPRECATE and _CRT_NONSTDC_NO_DEPRECATE and change the treat-warnings-as-errors level from /W3 to /W2. It should now look something like this:

LOCAL_CFLAGS_debug = -MDd -Gm -GX -Zi -Od -D_DEBUG -D_MBCS -D_LIB -YX -FD -GZ -W2 /D_CRT_SECURE_NO_DEPRECATE /D_CRT_NONSTDC_NO_DEPRECATE
LOCAL_CFLAGS_nodebug = -MD -GX -O2 -D_MBCS -D_LIB /YX -FD -W2 /D_CRT_SECURE_NO_DEPRECATE /D_CRT_NONSTDC_NO_DEPRECATE

• Example 1

• Example 2

Here are example build-phoneME.sh scripts for selected configurations:

• Example 1: phoneME Feature MR2 with CLDC + MIDP, not using javacall, and without debug support. This is the most basic build configuration.

build-phoneME.sh:

• Example 2: phoneME Feature MR2 with CLDC + MIDP, using javacall, and with debug support enabled. This is a configuration that can be integrated with NetBeans^? so that you can run and debug MIDlets on phoneME Feature from within NetNeans^? as an additional emulator platform:

build-phoneME.sh:

• Your executable path in cyg4me bash should look like this: j2sdk1.4.2_13/bin, followed by cyg4me/bin, followed by the stuff defined by Visual C++ vsvargs32.bat

I have been able to mostly avoid this problem now by doing the following. Instead of:

   $TOP=<_path_>
   $OUTPUT=$TOP/output

   $TOP=<_path_>
   $OUTPUT=<_short_path_>

Building

• A build-phoneME.sh to build phoneME Feature MR2 with CLDC + MIDP, no javacall, and no debugging:

• A build-phoneME.sh to build phoneME Feature MR2 with CLDC + MIDP, with javacall, and debugging enabled:

export TOP=c:/cygwin/home/work/phoneME_feature_MR2
export OUTPUT=$TOP/output
export LOG=$TOP/log.txt
# make PCSL
cd $TOP/pcsl
make ENABLE_PCSL=true PCSL_PLATFORM=win32_i386_vc PCSL_OUTPUT_DIR=$OUTPUT/pcsl 
# make CLDC
cd $TOP/cldc/build/win32_i386
make JDK_DIR=c:/j2sdk1.4.2_13 ENABLE_PCSL=true \
JVMWorkSpace=$TOP/cldc JVMBuildSpace=$OUTPUT/cldc \
USE_VS2005=true PCSL_OUTPUT_DIR=$OUTPUT/pcsl 
# make MIDP
cd $TOP/midp/build/win32
make JDK_DIR=c:/j2sdk1.4.2_13 TOOLS_DIR=$TOP/tools \
CLDC_DIST_DIR=$OUTPUT/cldc/win32_i386/dist \
USE_VS2005=true PCSL_OUTPUT_DIR=$OUTPUT/pcsl \
MIDP_OUTPUT_DIR=$OUTPUT/midp

There appears to be an incompatibility in the Windows DLL mechanism for certain system DLLs between Windows 2000 and Windows XP.

• If you build phoneME Feature as above on a Windows 2000 system the resulting phoneME binary will work fine on another WIndows 2000 system. However, if will likely not work on a Windows XP system because of the way the Windows XP DLL loading mechanism works (at least, that is my current understanding).
• If you build phoneME Feature on a Windows XP machine the resulting phoneME binary appears to run fine on other WIndows XP systems as well as Windows 2000 systems.

-- Main.terrencebarr - 26 Apr 2007

Running the phoneME executable on a system that does not have Microsoft Visual Studio installed

Running the phoneME executable on a system that has Microsoft Visual Studio installed

Running the phoneME executable on Windows systems that do not have Microsoft Visual Studio installed

Building

Fixing PCSL

Fixing CLDC

Fixing MIDP

• cygwin.bat

• .bash_profile

• Resulting bash shell $PATH

• build-phoneME.sh

• Your executable path in cyg4me bash should look like this: j2sdk1.4.2_13/bin, followed by cyg4me/bin, followed by the stuff defined by Visual C++ vsvargs32.bat
• Make sure j2sdk1.4.2_13/bin is in your excutable path and check the correct version by running java -version from the comand line. Also, pass in JDK_DIR seperately on the make command line. Dropping either will result in failures.
• Finally, sometimes the phoneME Windows build will fail with a STATUS_ACCESS_VIOLATION something like this:

• Visual Studio C++ Express (no cost) and install the missing ml.exe MASM from here MASM tool

• Be very careful with paths within cyg4me and shells you run within cyg4me. There seems to be various flaky behavior around paths, e.g. _path_ vs. c:/cygwin/_path_ vs. \cygwin\_path_ vs. /cygdrive/c/_path_ should all be the same but depending on the stage of the build and the tools used they seem to be evaluated differently by different tools resulting in puzzling build failures. A source of much fiddling and irritation. Make sure you enter all paths as described below.

• The MR2 b13 build available via the subversion repository (latest available version as of 28 Mar 2007)

Running the build

   sh ./build-phoneME.sh

However, if you have not yet updated the build configuration files as described below the build will fail. After fixing up the configuration files the build should run all the way through and result in a completely built phoneME stack located in the $OUTPUT/midp directory.

Building PCSL

Edit pcsl/makefiles/share/vc.gmk

In lines 46-50, change the compiler flags definition. Add the flags _CRT_SECURE_NO_DEPRECATE and _CRT_NONSTDC_NO_DEPRECATE and change the treat-warnings-as-errors level from /W3 to /W2. It should now look something like this:

Building CLDC

Building MIDP

Just go to the $OUTPUT/midp directory and run runMidlet.exe as described in the Getting Started Guide. It should work fine.

--+++ Running the phoneME executable on Windows systems that do not have Microsoft Visual Studio installed

Binaries built with Microsoft Visual Studio require dynamic linking of additional libraries which come with Microsoft Visual Studio. On standard Windows installations these libraries may not be present. Here is a blog on the issue:

• Running C++ application built by VC++ Express on another computer

One solution is to download and install on the target Windows machine the Microsoft Visual Studio redestributable library package:

• Visual C++ 2005 Redistributable Package

• build-phoneME.sh

• Executables are now generated in a new way so that an executable has an associated manifest that describes its DLL dependencies. This may cause trouble with romgen.exe

• Be very careful with paths within cyg4me and shells your run within cyg4me. There seems to be various flaky behavior around paths, e.g. "_path_" vs. "c:/cygwin/_path_" vs. "\cygwin\_path_" vs. "/cygdrive/c/_path_" should all be the same but depending on the stage of the build and the tools used they seem to be evaluated differently by different tools! A source of much fiddling and irritation. Make sure you enter all paths as described below other wise you will end up with mysterious build failures.

• Finally, sometimes the phoneME Windows build will fail with a STATUS_ACCESS_VIOLATION something like this:

A Working Setup

UNIX tools (cygwin and cyg4me):

cygwin is a Linux-like environment for Windows. It consists of two parts: A DLL (cygwin1.dll) which acts as a Linux API emulation layer providing substantial Linux API functionality as well as a collection of tools which provide Linux look and feel.

For use with phoneME Feature the Sun engineering team has created a purpose-built version called cyg4me. It is highly recommended to use cyg4me as cygwin

• Description of phoneME Feature MR2

• Getting Started Guide for phoneME Feature MR2

• The MR2 b13 build available via the subversion repository (latest available version as of 28 Mar 2007)

Much more important is the tool chain used. The Windows build requires the use of Microsoft tools. The build system has been used predominantely with Microsoft Visual C/C++ 6.0 and works fine with it. Unfortunately, Visual C/C++ 6.0 is no longer available. It has been replaced by Visual Studio 2005 and Visual Studio 2005 Express (which identify the tools version as 8.0).

Unfortunately, Microsoft has made backwards-incompatible changes to the C/C++ compiler and linker so that the attempt to build the phoneME Feature sources "out-of-the-box" will fail. The phoneME sources and build system have not yet been updated fully to support Visual Studio 2005 so you will need to make a few small modifications to some build configuration files to build successfully.

Also, the phoneME build system requires various UNIX utilities such as make and sh. Therefore, a package that provides these UNIX utilities on Windows must be used. cygwin is an open source project that provides such UNIX utilities. However, cygwin has it's share of bugs and is somewhat tricky to deal with so we'll describe possible problems and workarounds here as well.

Microsoft Visual Studio 2005 Issues

You have two choices:

* Use either Visual C++ Express (no cost) and install the missing ml.exe MASM from here http://www.microsoft.com/downloads/details.aspx?familyid=7A1C9DA0-0510-44A2-B042-7EF370530C64&displaylang=en

• Or use Visual Studio 2005 Professional or above

• Standard library functions like strcpy() are now deprecated in favor of versions that accept array lengths and check for array overruns.
• Executables are now generated in a new way so that an executable has an associated manifest that describes its DLL dependencies (I think). This causes a little trouble with romgen.exe, as you'll see.

UNIX tools:

• Finally, sometimes the build will fail with a STATUS_ACCESS_VIOLATION:

         4 [main] sh 1560 handle_exceptions: Exception: 
STATUS_ACCESS_VIOLATION
       653 [main] sh 1560 open_stackdumpfile: Dumping stack trace to 
sh.exe.stackdump
   make: *** 

This seems to be cause by some bug in cygwin/cyg4me with handling paths. The sh.exe program crashes and the build fails. The workaround is to shorten or lengthen the path of your phoneME Feature source tree root. Try moving the source tree to some other directory, delete the build output directory, and try re-running the build. This bug can be very frustrating and it might take several tries to avoid it.

Visual C++ 2005 Redistributable Package

Introduction

This wiki topic is a place to collect up-to-date information on how to build phoneME Feature. It assumes that you have already reviewed the following phoneME documentation and pages:

• Description of phoneME Feature

• phoneME Feature FAQ

In particular, a lot of essential information is contained here:

• Getting Started Guide for phoneME Feature

This wiki topic here is meant as additional information to complement the Getting Started Guide and to add late-breaking information, tips, and workarounds when building phoneME Feature.

Tested phoneME Feature Versions

Currently, these instructions here have been verified using the MR2 b04 build available here:

• Dowbload link for phoneme_feature-mr2-dev-src-b04-21_dec_2006.zip

as well as the MR2 b13 build available via the subversion repository (latest available version as of 28 Mar 2007)

Building on Windows

Building phoneME Feature

-- JonathanKnudsen^? - 04 Jan 2007

Here are my notes on using Microsoft Visual Studio 2005 on Windows XP to build phoneME Feature MR2.

The compiler in Visual Studio 2005 has significant differences from the one the engineering team is currently using. In particular, standard library functions like strcpy() are now deprecated in favor of versions that accept array lengths and check for array overruns.

In addition, executables are now generated in a new way so that an executable has an associated manifest that describes its DLL dependencies (I think). This causes a little trouble with romgen.exe, as you'll see.

-- TerrenceBarr^? - 16 Feb 2007

Update on compiler and linker options:

• A number of compiler options are now deprecated or have changed, such as: /GB and /DEBUGTYPE
• Also, it seems the linker now includes standard libraries so when CLDC or MIDP provide alternate definitions of symbols the linker fails with conflicting symbols. Standard libraries now must be explicitly excluded with the /nodefaultlib linker option.

-- TerrenceBarr^? - 16 Feb 2007

Update on tools:

• For my build I was using Windows 2000 Professional with SP4. The OS seems to be no problem.
• Do not use cygwin. You'll just run into a lot of problems, even if it seems to work initially. Don't waste your time. Use cyg4me at ftp://ftp.sunfreeware.com/pub/freeware/contributions/cygwin
• Use either Visual C++ Express and install the missing ml.exe MASM from here http://www.microsoft.com/downloads/details.aspx?familyid=7A1C9DA0-0510-44A2-B042-7EF370530C64&displaylang=en or use Visual Studio 2005 Professional or above.
• NOTE: Visual Studio Standard does not include the ml.exe MASM program and I have not found any way to add it (the MASM for Visual C++ refuses installation onto Visual Studio Standard and manually copying ml.exe doesn't work)

Update on paths:

• Be very careful with paths within cyg4me and shells your run within cyg4me. There seems to be various flaky behavior around paths, e.g. "_path_" vs. "c:/cygwin/_path_" vs. "\cygwin\_path_" vs. "/cygdrive/c/_path_" should all be the same but depending on the stage of the build and the tools used they seem to be evaluated differently by different tools!. A source of endless fiddling and irritation. Make sure you enter all paths as described other wise you will end up with mysterious build failures.
• Also, don't use shell environment variables except for a variable for the top of your source tree. Pass all variables to make on the command line directly.
• Your executable path in cyg4me bash should look like this: j2sdk1.4.2_13/bin, followed by cyg4me/bin, followed by the stuff defined by Visual C++ vsvargs32.bat.
• Make sure j2sdk1.4.2_13/bin is in your excutable path and check the correct version by running "java -version" from the comand line. Also, pass in JDK_DIR seperately on the make command line. Dropping either will result in failures.

A Working Setup

• cygwin.bat

@echo off
C:
call "/Program Files/Microsoft Visual Studio 8/Common7/Tools/vsvars32.bat"
set PATH=c:\cyg4me\bin;%PATH%
bash --login -i

• .bash_profile

export JDK_DIR=/cygdrive/c/j2sdk1.4.2_13
PATH=$JDK_DIR/bin:$PATH:.

• Resulting cygwin bash shell $PATH

/cygdrive/c/j2sdk1.4.2_13/bin:
/cygdrive/c/cyg4me/bin:
/cygdrive/c/Program Files/Microsoft Visual Studio 8/Common7/IDE:
/cygdrive/c/Program Files/Microsoft Visual Studio 8/VC/BIN:
/cygdrive/c/Program Files/Microsoft Visual Studio 8/Common7/Tools:
/cygdrive/c/Program Files/Microsoft Visual Studio 8/Common7/Tools/bin:
/cygdrive/c/Program Files/Microsoft Visual Studio 8/VC/PlatformSDK/bin:
/cygdrive/c/Program Files/Microsoft Visual Studio 8/SDK/v2.0/bin:
/cygdrive/c/WINNT/Microsoft.NET/Framework/v2.0.50727:
/cygdrive/c/Program Files/Microsoft Visual Studio 8/VC/VCPackages:
/cygdrive/c/cyg4me/bin:/cygdrive/c/WINNT/system32:/cygdrive/c/WINNT:
/cygdrive/c/WINNT/System32/Wbem:.

• build-cldc.sh

export TOP=c:/cygwin/home/work/phoneME_feature_MR2
export OUTPUT=$TOP/output
export LOG=$TOP/log.txt
cd $TOP/cldc/build/win32_i386
make \
JDK_DIR=c:/j2sdk1.4.2_13 \
ENABLE_PCSL=true \
JVMWorkSpace=$TOP/cldc \
JVMBuildSpace=$OUTPUT/cldc \
USE_VS2005=true \
PCSL_OUTPUT_DIR=$OUTPUT/pcsl

Building PCSL

Edit pcsl/makefiles/share/vc.gmk.

In lines 46-50, change the compiler flags definition. Add the flags _CRT_SECURE_NO_DEPRECATE and _CRT_NONSTDC_NO_DEPRECATE and change the treat-warnings-as-errors level from /W3 to /W2. This is what mine looks like when I'm done:

ifeq ($(USE_DEBUG), true)
CFLAGS= /WX /c /W2 -Zi -Od -MDd /D_CRT_SECURE_NO_DEPRECATE /D_CRT_NONSTDC_NO_DEPRECATE
else
CFLAGS= /WX /c /W2 /D_CRT_SECURE_NO_DEPRECATE /D_CRT_NONSTDC_NO_DEPRECATE
endif

The PCSL build should run fine now.

Building CLDC

For CLDC, set the environment variable USE_VS2005 to true before starting the build. It takes care of a lot of compiler warnings.

After the CLDC build successfully completes, make sure to copy romgen.exe.manifest from $JVMBuildSpace/cldc/win32_i386/romgen/app to $JVMBuildSpace/win32_i386/cldc/dist/bin. Otherwise romgen.exe will fail during the MIDP build with a message about a missing DLL.

-- TerrenceBarr^? - 16 Feb 2007

Update to the above: I have not found it necessary to copy romgen.exe.manifest. YMMV

Update: The CLDC build failed when I attempted the SJWC JavaCall build. I get the same link error as for MIDP below. I fixed it by adding a line to cldc/build/javacall_i386_vc/javacall_i386_vc.cfg:

LINK_FLAGS+=-nodefaultlib:libcmt.lib

-- TerrenceBarr^? - 16 Feb 2007

Note: Towards the end of the CLDC build there are still a lot of warning messages around compiler and linker options, such as /GB, /DEBUGTYPE, and multiple defined symbols regarding LIBCMT

Building MIDP

The MIDP link will not work unless you add a flag. Do this by adding the following line to midp/build/win32/Platform.gmk:

LD_FLAGS+=-nodefaultlib:libcmt.lib

After this, the MIDP (SJWC) build should proceed successfully. You will get lots of warnings about method deprecation and an unsupported compiler option /GB, but it should stagger through to the end without errors.

-- Main.terrencebarr - 28 Mar 2007