Skip to main content

Volunteer needed to port phoneME Advanced to Garnet OS / Palm OS 5.x

198 replies [Last post]

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
> I am likely getting ahead of myself again, but I posted elsewhere (see http://www.1src.com/forums/showthread.php?t=145828 ) about possible UI related available libraries for Palm development and someone mentioned a port of SDL for the Palm (see https://sourceforge.net/project/showfiles.php?group_id=212180 ). Would SDL (see http://libsdl.org/ ) provide the necessary UI aspects needed for the GUI parts? Would a defs_personal_sdl.mk be worth developing?
>

Hi Eric,

Thanks! That reference will help in the future. Now that you,
Biswajit, and Jay are building on a host system, we'll need to work on
cross-compiling a binary to try on the target PalmOS device. (I think
just getting a System.out.println("Hello World!"); app to work with the
cross-compiler tool will be a big enough challenge before we even
consider UI issues, though ;-) ).

Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

ebresie
Offline
Joined: 2003-08-06

Not sure if this is usable either, but found the following which may also prove useful...

http://www.wxwidgets.org/about/news/palmos.htm

Eric

Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
> Haven't gotten too far, but I have started trying to work on cloning the port directories.
>
> I am working multipled environements (Cygwin based and also trying to get Visual Studios installed), but my thinking is:
>
> At the moment, I am working the Cygwin route, since the prc-tools that are common with Palm development, seems more useful in the Cygwin route.
>
> I created the following directories:
>
> cdc/build/palmos
> cdc/build/palmos-arm
> cdc/src/palmos
> cdc/src/palmos-arm
>
> I have cloned the linux and linux-arm-generic to the palmos and palmos-arm for both build and src directories.
>
> I noticed there are some defs_personal_x11.mk and defs_personal_motif.mk which I assume are for X11 and MOTIF environments, which I suspect are not available for Palm presently, so I dropped these. I did notice the defs_personal_gtk.mk and defs_personal_qt.mk which seemed more likely candidates for use with Palm, but once again, I'm not sure if they have been ported to Palm either. I may need to have another items for whatever Palm UI framework we will end up using.
>

Yes, don't look at any parts of the build that used _basis or
_personal. Those are the GUI parts that just won't build without a huge
amount of work on Palm OS. The best approach is to stick with a
headless CDC/Foundation Profile build (J2ME_CLASSLIB=foundation).

> When attempting:
>
> make CVM_TARGET_TOOLS_PREFIX=/usr/bin/arm-palmos-
>
> I get:
>
> ... generating PackageManager.java
> java.io.FileNotFoundException: e:\usr\local\src\phoneME\cdc\src\share\tools\xml\
> empty.xml (The system cannot find the path specified)
>
>

That's our dreaded Windows mount "feature" in our builds. Try this and
see if it works:

mount e:/usr /usr
make ...

> Not sure if maybe this is a missing cygwin environment tool but there's were I am at the moment.
>
> A question through, why does the "palmos-arm-" build get created? Where does the last "-" come from? Any ideas?
>
...
> I have since created an I palmos-arm-generic directory as well.
>

Yes, that looks like it should match your makefiles now that you renamed
your clone directory to *-*-*.

Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

ebresie
Offline
Joined: 2003-08-06

Yup...I stumbled across a thread elsewhere ( http://forums.java.net/jive/message.jspa?messageID=282367 ) that mentioned the problem. I tried it out and this resolved the problem of the empty.xml file. I was able to get further.

Eric

ebresie
Offline
Joined: 2003-08-06

I forgot to mention, with my linux-arm-generic based build, I ended up getting an error relating to threading. I'm thinking the linux code might be making some thread calls of some type, but I'm not sure how much of that is usable and how much will have to be totally re-written for the palm. Don't have my code at the moment, so will provide details when I am able to provide it.

Eric

Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
> I forgot to mention, with my linux-arm-generic based build, I ended up getting an error relating to threading. I'm thinking the linux code might be making some thread calls of some type, but I'm not sure how much of that is usable and how much will have to be totally re-written for the palm. Don't have my code at the moment, so will provide details when I am able to provide it.
>

Hi Eric,

Did you find what was going on with the threading error? Did you have a
specific error message that you saw in the output?

Thanks,
Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

bsarkar
Offline
Joined: 2006-09-18

Hi Bill!

Thanks a lot. I had to make some changes in the *defs* file but, finally, I got a build.

Biswajit

bsarkar
Offline
Joined: 2006-09-18

> Set your cygwin shell env variables:
> export JAVA_HOME=/cygdrive/c/j2sdk1.4.2_17
> export JAVA_PATH=$JAVA_HOME
> export JDK_HOME=$JAVA_HOME
>

I have a question here. Instead of exporting everytime, isn't it possible to put all these env variables in, say, defs.mk file?

Thanks.

cjplummer
Offline
Joined: 2006-10-16

You only need to set JDK_HOME. I'm not sure why setting JAVA_HOME and JAVA_PATH was recommended since they are not needed.

JDK_HOME cannot be set in a makefile since it may vary for different users. You can export it, set it in a script you use to execute the GNUmakefile, or set it on the make command line. You can even just put the java tools on the path and the makefiles will pick them up automatically if JDK_HOME is not set. If you have something newer than Jave SE 1.4.x on the path and are using it in your build, usually that is OK, but is not recommended.

Chris

bsarkar
Offline
Joined: 2006-09-18

> JDK_HOME cannot be set in a makefile since it may
> vary for different users.

In the defs.mk file, the path to Visual Studio (VS_DIR) is defined although this too will be user dependent. In my case, for example, this is D:/Microsoft Visual Studio and I had to edit this entry before I could get a build. Anyway, since JDK_HOME is known for my system, why can't I put it here?

Thanks

Biswajit

cjplummer
Offline
Joined: 2006-10-16

> > JDK_HOME cannot be set in a makefile since it may
> > vary for different users.
>
> In the defs.mk file, the path to Visual Studio
> (VS_DIR) is defined although this too will be user
> dependent. In my case, for example, this is
> D:/Microsoft Visual Studio and I had to edit this
> entry before I could get a build. Anyway, since
> JDK_HOME is known for my system, why can't I put it
> here?
>
> Thanks
>
> Biswajit

VS_DIR has a default which is the same as where the default location where Visual Studio will install itself. Therefore it works for most users. For JDK_HOME, there are many versions of JavaSE 1.4, and we don't require the latest, so it is unlikely that any default we set for it will work for more than a small percent of the users.

As for putting JDK_HOME in defs.mk, you can do that since it will work for your setup. I'm just saying that this isn't the type of change that can be committed back to the OSS source.

Chris

bsarkar
Offline
Joined: 2006-09-18

> VS_DIR has a default which is the same as where the
> default location where Visual Studio will install
> itself. Therefore it works for most users. For
> JDK_HOME, there are many versions of JavaSE 1.4, and
> we don't require the latest, so it is unlikely that
> any default we set for it will work for more than a
> small percent of the users.
>
> As for putting JDK_HOME in defs.mk, you can do that
> since it will work for your setup. I'm just saying
> that this isn't the type of change that can be
> committed back to the OSS source.
>
> Chris

Okay I understand the rationale now.

Thanks very much for answering my questions with so much patience.

Biswajit

Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
> Okay I understand the rationale now.
>
> Thanks very much for answering my questions with so much patience.
>

Hi Biswajit,

Please also try this which I asked Max to also do:

Try Eric's new bundle and instructions:

Download his bundle from here:
https://j2me-cdc.dev.java.net/servlets/ProjectDocumentList?folderID=9440...
(Click on: pMEA-palmos-0.1.tar.gz
)

See his reference here:
http://forums.java.net/jive/message.jspa?messageID=283031#283031

Please let us know how that works for you.

Hinkmond
[att1.html]

Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
> I'm willing to use my Palm Treo 755p for testing.
>
> I was able to build cvm for linux-x86-generic and run the test class but when trying to build midp with the included script I get stuck with a missing ftheader.h.
>

Hi Jay,

Glad to see another volunteer on board for the Palm OS port!

Using Fedora 9 will be fine. But, you are jumping the gun a bit, since
there is no support of a MIDP/PBP on Qt 3.x yet (only Qt/Embedded 2.x)
and that would require a bit of work to get working right, so going down
that route for a Linux/x86/Qt3 build would be quite a chore and not
helpful to the Palm OS effort right now.

Instead, please try just a regular headless CDC or Foundation Profile
build on your Fedora 9 system.

See:
http://wiki.java.net/bin/view/Mobileandembedded/PhoneMEAdvancedBSGHost#A...

For example:

Can you do this on your Fedora 9 system with the phoneme_advanced_mr2
source bundle?

cd cdc/build/linux-x86-generic
make J2ME_CLASSLIB=foundation

If you get a good build, does the following run for you?

bin/cvm -version
bin/cvm -cp testclasses.zip Test

If you can get the above to work, we can go on to the next step. If
not, let us know what problems you are seeing and we can help.

Thanks,
Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

ebresie
Offline
Joined: 2003-08-06

> So unless you have a linux-x86 cross compiler running under cygwin

Would it make sense to create another port which is a cygwin based build of some type?

Eric

cjplummer
Offline
Joined: 2006-10-16

> > So unless you have a linux-x86 cross compiler
> running under cygwin
>
> Would it make sense to create another port which is a
> cygwin based build of some type?
>
> Eric

I don't think this is useful unless you just want the porting experience.

Chris

ebresie
Offline
Joined: 2003-08-06

> So unless you have a linux-x86 cross compiler running under cygwin that you can point to with CVM_TARGET_TOOLS_PREFIX, you should not be in the linux-x86-generic build directory.

I did build against the linux-x86-generic directory using cygwin as the environment. This is where I suspect I got some differences.

What is the preferred way to set the CVM_TARGET_TOOLS_PREFIX and related variables?

As an environment variable?
As an argument to make?
As a value contained in a related .mk/makefile/configuration file of some type?

What other variables might need to be set? While reviewing some of the output during the build, I noticed references to TARGET_CC, TARGET_CCC, TARGET_AS, TARGET_LD, TARGET_AR, and TARGET_RANLIB. I assume many of these may already get set to a default value, based on other variables, are they set based on running a specific application, or configured as part of make activities. Are any of these correct assumptions?

Thanks ahead of time.

Eric

cjplummer
Offline
Joined: 2006-10-16

> > So unless you have a linux-x86 cross compiler
> running under cygwin that you can point to with
> CVM_TARGET_TOOLS_PREFIX, you should not be in the
> linux-x86-generic build directory.
>
> I did build against the linux-x86-generic directory
> using cygwin as the environment. This is where I
> suspect I got some differences.
>
> What is the preferred way to set the
> CVM_TARGET_TOOLS_PREFIX and related variables?
>
> As an environment variable?
> As an argument to make?
> As a value contained in a related
> .mk/makefile/configuration file of some type?
Any of the above. If the tools are usually in a well known location for a given port (they usually are not) then the GNUmakefile is a good place for a default. However, proceeding with trying to build the linux-x86 port under cygwin is pretty pointless. Just build it on a linux-x86 machine with native tools. A cygwin-x86 port is also pretty pointless. Just use the exising win32-x86 port.
>
> What other variables might need to be set? While
> reviewing some of the output during the build, I
> noticed references to TARGET_CC, TARGET_CCC,
> TARGET_AS, TARGET_LD, TARGET_AR, and TARGET_RANLIB.
> I assume many of these may already get set to a
> default value, based on other variables, are they
> set based on running a specific application, or
> configured as part of make activities. Are any of
> these correct assumptions?

They are set based on the value of CVM_TARGET_TOOLS_PREFIX. Sometimes CVM_TARGET_TOOLS_PREFIX doesn't work so well and you need to set the paths to each tool, but for any gcc build, setting CVM_TARGET_TOOLS_PREFIX should work.

Also note that when the target and host are the same, CVM_TARGET_TOOLS_PREFIX is usually left unset, and gcc is picked up off of $PATH.

Chris

Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
...
>> I did build against the linux-x86-generic directory
>> using cygwin as the environment. This is where I
>> suspect I got some differences.
>>
>> What is the preferred way to set the
>> CVM_TARGET_TOOLS_PREFIX and related variables?
>>
>> As an environment variable?
>> As an argument to make?
>> As a value contained in a related
>> .mk/makefile/configuration file of some type?
> Any of the above. If the tools are usually in a well known location
> for a given port (they usually are not) then the GNUmakefile is a
> good place for a default. However, proceeding with trying to build
> the linux-x86 port under cygwin is pretty pointless. Just build it on
> a linux-x86 machine with native tools. A cygwin-x86 port is also
> pretty pointless. Just use the exising win32-x86 port.

Eric mentioned he doesn't have MS Visual Studio 2005. So, I'm not sure
he can build the win32-x86 build flavor.

Is that correct, Eric? Did you try the win32-x86 build and see you have
missing tools on your Windows PC?

I'm also not sure if you knew there is a free version of MS VS2005:

http://www.download.com/Visual-Studio-2005-SP1/3000-10251_4-10618634.html

So, whichever way you choose, I think it's worth it if you first build a
host system binary to see how our Makefiles work, how you generate a cvm
binary and support files from those, and how it runs by executing the
testclasses.zip Test class. Using the free version of MS VS2005 (above)
and the win32-x86 build flavor (as Chris suggested) might be the
quickest way at this point, knowing just a little about your set up.

It is worth it to do a host build before trying to build a target device
binary (like for ARM) since you won't be able to run and check if you
built the ARM/68k binary incorrectly, especially on a new target device
like a PalmOS device that we are not even sure yet if you have a
Terminal shell or not. Building the host binary becomes your touchstone
that you can compare the target development to.

So, before going too far the route of investigating what it takes to
build a ARM or 68k binary, let us know if you are comfortable in
building and running the x86 cvm binary first, especially since you have
not worked with phoneME or CDC before.

Thanks,
Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
> Well...as I don't have Visual Studios installed at the moment, I tried the linux-x86-generic with cygwin and get the following...
>
> Does this imply it would require developing a x86-pc-cygwin version of some type for this to work (without VS)?
>
>
...
> ---------------------------------
> Target tools not properly specified. The gcc -dumpmachine
> output does not agree with CVM_TARGET. The OS and CPU portions
> must match for compatibility. If this is a cross compile, you
> probably forgot to set CVM_TARGET_TOOLS_PREFIX. If you want to
> to turn off this check, set CVM_COMPILER_INCOMPATIBLE=false
> on the make command line or in the GNUmakefile
> CVM_TARGET: linux-x86-generic
> compiler target: x86-pc-cygwin
>
>

Hi Eric,

It looks like you created a new build/x86-pc-cygwin subdirectory with a
GNUmakefile in it to try to create a new port to your Cygwin/x86 platform.

Our Makefiles are doing a sanity test to see if the subdir name you
created matches the "gcc -dumpmachine" output.

So, for Cygwin/x86, the subdir name should match the "gcc -dumpmachine"
output:

$ gcc -dumpmachin
i686-pc-cygwin
^^^^^^^^^^^^^^

Therefore, your "x86-pc-cygwin" directory name does not match with what
the Makefile expects.

You can try 2 options:

1. Rename your build/x86-pc-cgywin subdir to build/i686-pc-cygwin

OR

2. Build using the flag, CVM_COMPILER_INCOMPATIBLE=false, to turn off
the sanity checking.
Ex.
make ... CVM_COMPILER_INCOMPATIBLE=false

Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

cjplummer
Offline
Joined: 2006-10-16

It's more the opposite. He's in the linux-x86-generic build directory, but is compiling using cygwin default host tools as the target tools, which are for x86-pc-cygwin. Your target tools need to match your target build directory. So unless you have a linux-x86 cross compiler running under cygwin that you can point to with CVM_TARGET_TOOLS_PREFIX, you should not be in the linux-x86-generic build directory.

Porting starts by cloning an existing port to create the proper src and build directories. A start would be to clone one of the build directories to create a build/palmos--. Plug in whatever the cpu is for and whatever the specific device name is for (use generic if all devices are treated equally).

Creating the device build directory is just a small slice of the needed work, you'll need to clone something into src/palmos, build/palmos, src/palmos- and build/palmos-. Of course then you need to modify them to build and work for palmos.

Chris

Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
> It's more the opposite. He's in the linux-x86-generic build directory, but is compiling using cygwin default host tools as the target tools, which are for x86-pc-cygwin. Your target tools need to match your target build directory. So unless you have a linux-x86 cross compiler running under cygwin that you can point to with CVM_TARGET_TOOLS_PREFIX, you should not be in the linux-x86-generic build directory.
>

OK. I see now. I'm the one who at first suggested to Eric (and the
other PalmOS volunteers) to try to build for the host system (in his
case Cygwin/x86) to get them all introduced to building and running a
pMEA host binary as the first step.

In the next steps, after getting them introduced to how to build and run
pMEA for the host, I was going to start the discussion about building
and running for the target device. But, you do a good job giving a
brief overview (below) already.

Getting to build and run on the host system is not a critical step, but
it's good for Eric and others to do as practice. Eric, let us know if
you want to spend time getting your host build/run practice right, or if
you feel comfortable with that.

> Porting starts by cloning an existing port to create the proper src and build directories. A start would be to clone one of the build directories to create a build/palmos--. Plug in whatever the cpu is for and whatever the specific device name is for (use generic if all devices are treated equally).
>
> Creating the device build directory is just a small slice of the needed work, you'll need to clone something into src/palmos, build/palmos, src/palmos- and build/palmos-. Of course then you need to modify them to build and work for palmos.
>

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

ebresie
Offline
Joined: 2003-08-06

> Porting starts by cloning an existing port to create the proper src and build directories. A start would be to clone one of the build directories to create a build/palmos--. Plug in whatever the cpu is for and whatever the specific device name is for (use generic if all devices are treated equally).

Palms are based originally on 68k chips with later arm chips. The chip on my Treo 680 is an Intel PXA270.

I would suspect we need a palmos-arm and possible a palmos-m68k (for older Palms), but I'm not sure if the older Palms will have the necessary resources to support full implementation, so at a minimum, I think palmos-arm is a good starting point.

Which existing port would you recommend? Would it be better to pick something based on an arm chip of some type or based on a more complete implementation such as a linux-arm port of some kind?

Eric

cjplummer
Offline
Joined: 2006-10-16

> > Porting starts by cloning an existing port to
> create the proper src and build directories. A start
> would be to clone one of the build directories to
> create a build/palmos--. Plug in
> whatever the cpu is for and whatever the
> specific device name is for (use generic if
> all devices are treated equally).
>
> Palms are based originally on 68k chips with later
> arm chips. The chip on my Treo 680 is an Intel
> PXA270.
>
> I would suspect we need a palmos-arm and possible a
> palmos-m68k (for older Palms), but I'm not sure if
> the older Palms will have the necessary resources to
> support full implementation, so at a minimum, I think
> palmos-arm is a good starting point.
>
> Which existing port would you recommend? Would it be
> better to pick something based on an arm chip of some
> type or based on a more complete implementation such
> as a linux-arm port of some kind?
>
> Eric

You'll want to start with one of our many OS ports to ARM. I have no idea which OS palm is most like. You can choose from linux, win32, symbian, and vxworks (solaris and darwin aren't much different than linux). There are ports to ARM for linux, win32, and symbian, including the JIT.

For 68k, if you go that route, I'd suggest first getting a palmos-arm port working since we currently have no 68k support for any OS.

Chris

ebresie
Offline
Joined: 2003-08-06

Haven't gotten too far, but I have started trying to work on cloning the port directories.

I am working multipled environements (Cygwin based and also trying to get Visual Studios installed), but my thinking is:

At the moment, I am working the Cygwin route, since the prc-tools that are common with Palm development, seems more useful in the Cygwin route.

I created the following directories:

cdc/build/palmos
cdc/build/palmos-arm
cdc/src/palmos
cdc/src/palmos-arm

I have cloned the linux and linux-arm-generic to the palmos and palmos-arm for both build and src directories.

I noticed there are some defs_personal_x11.mk and defs_personal_motif.mk which I assume are for X11 and MOTIF environments, which I suspect are not available for Palm presently, so I dropped these. I did notice the defs_personal_gtk.mk and defs_personal_qt.mk which seemed more likely candidates for use with Palm, but once again, I'm not sure if they have been ported to Palm either. I may need to have another items for whatever Palm UI framework we will end up using.

When attempting:

make CVM_TARGET_TOOLS_PREFIX=/usr/bin/arm-palmos-

I get:

... generating PackageManager.java
java.io.FileNotFoundException: e:\usr\local\src\phoneME\cdc\src\share\tools\xml\
empty.xml (The system cannot find the path specified)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.(FileInputStream.java:106)
at java.io.FileInputStream.(FileInputStream.java:66)
at sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection
.java:70)
at sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLCon
nection.java:161)
at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrent
Entity(XMLEntityManager.java:653)
at com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determineD
ocVersion(XMLVersionDetector.java:186)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(X
ML11Configuration.java:771)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(X
ML11Configuration.java:737)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.
java:107)
at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.
java:225)
at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(Doc
umentBuilderImpl.java:283)
at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:208)
at com.sun.xml.transform.CodeTransformerImpl.transform(Unknown Source)
at com.sun.xml.transform.CodeTransformer.main(Unknown Source)
make: *** [/usr/local/src/phoneME/cdc/build/palmos-arm-/./generated/classes/com/
sun/cdc/config/PackageManager.java] Error 1

Not sure if maybe this is a missing cygwin environment tool but there's were I am at the moment.

A question through, why does the "palmos-arm-" build get created? Where does the last "-" come from? Any ideas?

Eric

ebresie
Offline
Joined: 2003-08-06

> A question through, why does the "palmos-arm-" build get created? Where does the last "-" come from? Any ideas?

Opps...I think I may have figured part of my problem...

I incorrectly copied from a linux-arm-generic directory into my palmos-arm directory which may have caused some of the problems. I have since created an I palmos-arm-generic directory as well.

I did continue to get the same problem error.

Eric

mattleo
Offline
Joined: 2008-06-23

I've got access to two PalmOS 5 devices, although they're rather old (A Tungsten T and a Zire 71), as well as a rather large selection of PocketPC devices if having one for comparison would be useful.

I don't have any native development experience on Palm, although I've developed waba applications. I do have C experience, although it's been a long time.

I can build either on Linux with the gnu toolchain, or on Windows with Visual Studio. I also have access to a Mac if there is any value in using that. I'm most used to working with Eclipse. I'm willing to spend a modest amount of money on tools, if that would be useful. Whatever is the most productive platform to cooperate with, I'll use that.

I can also buy another Palm device, if need be.

Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
> I've got access to two PalmOS 5 devices, although they're rather old (A Tungsten T and a Zire 71), as well as a rather large selection of PocketPC devices if having one for comparison would be useful.
> ...
>
> I can build either on Linux with the gnu toolchain, or on Windows with Visual Studio. I also have access to a Mac if there is any value in using that.

Hi Matt,

Thanks for volunteering! Since, many of the other Palm OS port
developers are also using Windows with Visual Studio, can you try the
following:

Download:
http://wiki.java.net/bin/view/Mobileandembedded/PhoneMEAdvancedBSGGetting

Set up:
Download and Install J2SDK 1.4.2

Set your cygwin shell env variables:
export JAVA_HOME=/cygdrive/c/j2sdk1.4.2_17
export JAVA_PATH=$JAVA_HOME
export JDK_HOME=$JAVA_HOME

Try building:
cd cdc/build/win32-x86-vc8
make J2ME_CLASSLIB=foundation

Try running:
bin/cvm -version
bin/cvm -cp testclasses.zip Test

Let us know if you get that far.

Thanks,
Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

mattleo
Offline
Joined: 2008-06-23

Hmmm. So you'd like me to try this on Windows with cygwin, as opposed to VS? In that case, why not Linux?

I do most of my development these days on virtual machines (it makes switching machines sooo much easier). So I'm going to try the build on some kind of virtual machine or another. I was thinking it might be useful to try the build on a Linux virtual appliance. One thing I've found is that it's a bit of a PITA to get a new team member set up with everything he needs. If I can do the checkout and build on a Linux VM, the nice thing about that would be that the entire VM would be re-distributable without license restrictions. Anybody interested in getting their feet wet could just download the appliance, start it up, do a checkout and build.

The downside is the lack of Palm's official hotsync software, but I've found Ubuntu's Palm hardware support to be quite good. I haven't tried it in a vm appliance yet, but it should be possible to hook the USB Device up to the virtual Ubuntu and install software.

Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
> Hmmm. So you'd like me to try this on Windows with cygwin, as opposed to VS? In that case, why not Linux?
>
> I do most of my development these days on virtual machines (it makes switching machines sooo much easier). So I'm going to try the build on some kind of virtual machine or another. I was thinking it might be useful to try the build on a Linux virtual appliance. One thing I've found is that it's a bit of a PITA to get a new team member set up with everything he needs. If I can do the checkout and build on a Linux VM, the nice thing about that would be that the entire VM would be re-distributable without license restrictions. Anybody interested in getting their feet wet could just download the appliance, start it up, do a checkout and build.
>
> The downside is the lack of Palm's official hotsync software, but I've found Ubuntu's Palm hardware support to be quite good. I haven't tried it in a vm appliance yet, but it should be possible to hook the USB Device up to the virtual Ubuntu and install software.
>

Hi Matt,

That sounds fine if you want to try to use a virtual Ubuntu or even
Windows w/MS VS2005. There are bigger problems right now that there is
no Console or Terminal to bring up a shell to type command lines on a
PalmOS device itself and it seems there is no true POSIX threads in PalmOS.

If that's true, it is a showstopper for the PalmOS port of pMEA if you
guys cannot figure a workaround, since that means a simple
HelloWorld.java test won't be able to confirm that the headless base
port of the VM is working OK.

Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

mattleo
Offline
Joined: 2008-06-23

Well, OK. Mostly I want to take the path of least resistance, but if all things are equal it might be nice to develop in Linux because it makes moving the development environment around easier. However, if that is likely to be a limiting factor in contributing, then I'll use what "everyone else" is using. I also have a Palm Developer Network membership so I can download the Access Developer Network tools, which are Windows based.

WRT to the console issue, I'm not sure I understand why this should be a problem. The waba people simply create a file for console output. In the long term it'd be nice to have a console for interactive testing, but for HelloWorld an OutputStream's and OutputStream. Of course, maybe I'm just being ignorant. I'll know more once I've got to the point of being able to build.

bsarkar
Offline
Joined: 2006-09-18

Hi Hinkmond!

I've been working on getting used to Cygwin and *make*. When I run the *make* command, I get the following message:

ERROR: JDK_DIR must be set
make: *** [JDK_DIR] Error 255

Where do I set this? My JAVA_HOME is C:\jdk1.6.0. Should I create a new System Variable?

Biswajit

Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
> Hi Hinkmond!
>
> I've been working on getting used to Cygwin and *make*. When I run the *make* command, I get the following message:
>
> ERROR: JDK_DIR must be set
> make: *** [JDK_DIR] Error 255
>
> Where do I set this? My JAVA_HOME is C:\jdk1.6.0. Should I create a new System Variable?
>

Hi Biswajit,

For the above error, try downloading and installing JDK 1.4.2 (what you
need to build phoneME Advanced), then set your environment variables
like this:

Set up:
Download and Install J2SDK 1.4.2

Set your cygwin shell env variables:
export JAVA_HOME=/cygdrive/c/j2sdk1.4.2_17
export JAVA_PATH=$JAVA_HOME
export JDK_HOME=$JAVA_HOME

Try building:
cd cdc/build/win32-x86-vc8
make J2ME_CLASSLIB=foundation

Try running:
bin/cvm -version
bin/cvm -cp testclasses.zip Test

Hinkmond

[att1.html]

bsarkar
Offline
Joined: 2006-09-18

> phonemeadvanced@mobileandembedded.org wrote:
> > Hi Hinkmond!
> >
> > I've been working on getting used to Cygwin and
> *make*. When I run the *make* command, I get the
> following message:
> >
> > ERROR: JDK_DIR must be set
> > make: *** [JDK_DIR] Error 255
> >
> > Where do I set this? My JAVA_HOME is C:\jdk1.6.0.
> Should I create a new System Variable?
> >
>
> Hi Biswajit,
>
> For the above error, try downloading and installing
> JDK 1.4.2 (what you
> need to build phoneME Advanced), then set your
> environment variables
> like this:
>
> Set up:
> Download and Install J2SDK 1.4.2
> > -CDS_Developer-Site/en_US/-/USD/ViewProductDetail-Star
> t?ProductRef=j2sdk-1.4.2_17-oth-JPR@CDS-CDS_Developer>
>
> Set your cygwin shell env variables:
> export JAVA_HOME=/cygdrive/c/j2sdk1.4.2_17
> export JAVA_PATH=$JAVA_HOME
> export JDK_HOME=$JAVA_HOME
>
> Try building:
> cd cdc/build/win32-x86-vc8
> make J2ME_CLASSLIB=foundation
>
> Try running:
> bin/cvm -version
> bin/cvm -cp testclasses.zip Test
>
>
> Hinkmond
>
> [att1.html]

Hi Hinkmond!

I've done the following:

a) I have JDK 1.4.2_05 already in my system so I have set JAVA_HOME to point to that directory.

b) I have set the env variables as per your instructions above.

c) I cd'd to .../cdc/build/win32-x86-vc8

d) and then *make J2ME_CLASSLIB=foundation*

There is a profusion of messages the final one being:

[b]..../cdc/build/win32\javavm/include/ansi/stddef.h(31) : fatal error C1083: Cannot open include file: 'stddef.h' : No such file or directory
make: *** [../../build/win32-x86-vc8/./obj/gen_semispace.0] Error 2[/b]

Also it seems to be looking for MS Visual Studio 8:

[b]TARGET_RANLIB = which: no ranlib in (cygdrive/c/Program Files/Microsoft Visual Studio 8/VC/bin:.......[/b]

I don't have VS8 just VS6 which is in my D: drive.

What do I do now?

In the meanwhile, I've started looking at KNI documentation. We'll need that isn't it? I'll probably need to know the Palm OS APIs as well. If so then where can I find that documentation?

I know I'm probably jumping the gun a bit but I thought it's better to start preparing myself as early as I can.

Thanks

Biswajit

billp
Offline
Joined: 2006-09-19

If you only have VC6 then try doing the build in the win32-x86-vc6 directory.

bill

Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
> If you only have VC6 then try doing the build in the win32-x86-vc6 directory.
>

I agree with Bill. You should try:

cd build/win32-x86-vc6
make J2ME_CLASSLIB=foundation

If you cannot build a cvm binary for your host system and are not able
to run our functional sanity tests using that binary, you won't get very
far with trying to port to Palm OS, since we still need to guide you
through how to use the cross-compiler toolchain for Palm OS, and get you
familiarized with our Makefiles and build system.

There's several more steps to get through before even considering what
to do in the native interface layer. So, hopefully we can get past that
quickly.

Thanks,

Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

bsarkar
Offline
Joined: 2006-09-18

> phonemeadvanced@mobileandembedded.org wrote:
> > If you only have VC6 then try doing the build in
> the win32-x86-vc6 directory.
> >
>
> I agree with Bill. You should try:
>
> cd build/win32-x86-vc6
> make J2ME_CLASSLIB=foundation
>
>
> If you cannot build a cvm binary for your host system
> and are not able
> to run our functional sanity tests using that binary,
> you won't get very
> far with trying to port to Palm OS, since we still
> need to guide you
> through how to use the cross-compiler toolchain for
> Palm OS, and get you
> familiarized with our Makefiles and build system.
>
> There's several more steps to get through before even
> considering what
> to do in the native interface layer. So, hopefully
> we can get past that
> quickly.
>
>
> Thanks,
>
> Hinkmond
>
> ------------------------------------------------------
> ---------------
> To unsubscribe, e-mail:
> advanced-unsubscribe@phoneme.dev.java.net
> For additional commands, e-mail:
> advanced-help@phoneme.dev.java.net

Hi Hinkmond!

Okay I got a build. I ran the tests and got the following message:

[b]Test completed with 411 tests passed and 0 failures[/b]

Biswajit

Hinkmond Wong

> Okay I got a build. I ran the tests and got the following message:
>
> [b]Test completed with 411 tests passed and 0 failures[/b]
>

Hi Biswajit,

Glad to hear you have the CVM build working on your host system now!
I'm going to keep track of all the PalmOS developers and their statuses
and post our next steps.

See:

http://wiki.java.net/bin/view/Mobileandembedded/PhoneMEAdvancedPlatforms...

Biswajit, Eric, and Jay, please look at the new table I have in the
above TWiki URL and let me know if it reflects your latest status.
Please go ahead and edit the table yourselves if you'd like also.

Our next step will be to use the PalmOS gcc to integrate in with the cvm
build to do a target device build instead of a host system build.

Can anyone tell me the name of the PalmOS or Garnet OS C compiler and
what type of experience you might have had with it? And, what is the
output of the following command using the PalmOS/GarnetOS gcc
cross-compiler:

*-gcc -dumpmachine

Thanks,

Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

ebresie
Offline
Joined: 2003-08-06

The gcc compiler for Palm is: /usr/bin/arm-palmos-gcc.

"/usr/bin/arm-palmos-gcc. -dumpmachine" gives: arm-palmos

Eric

jslee06
Offline
Joined: 2008-06-21

I'm willing to use my Palm Treo 755p for testing.

I was able to build cvm for linux-x86-generic and run the test class but when trying to build midp with the included script I get stuck with a missing ftheader.h.

Here is my modified script:

#!/bin/bash

export TOP_DIR=/usr/local/src/phoneme_advanced_mr2

make \
CVM_HOST_TOOLS_PREFIX=/usr/bin/ \
CVM_TARGET_TOOLS_PREFIX=/usr/bin/ \
CVM_JAVA_TOOLS_PREFIX=/usr/java/j2sdk1.4.2_17/bin/ \
JDK_HOME=/usr/java/j2sdk1.4.2_17/ \
CVM_BUILD_SUBDIR=true \
CVM_BUILD_SUBDIR_NAME=build_b76 \
J2ME_CLASSLIB=basis \
AWT_IMPLEMENTATION=qt \
QT_TARGET_DIR=/usr/local/qt-embedded-free-3.3.8b \
QT_VERSION=3.3.8b \
QTEMBEDDED=true \
QTOPIA=false \
USE_QVFB=true \
USE_QT_FB=false \
PCSL_DIR=$TOP_DIR/pcsl \
TOOLS_DIR=$TOP_DIR/tools \
USE_MIDP=true \
MIDP_DIR=$TOP_DIR/midp

This is the error I get:

c++ /usr/local/src/phoneme_advanced_mr2/cdc/src/share/basis/native/awt/qt/QtFontMetrics.cpp
In file included from ../../../../../qt-embedded-free-3.3.8b/include/qfontfactoryttf_qws.h:49,
from ../../../../../qt-embedded-free-3.3.8b/include/qt.h:340,
from ../../src/share/basis/native/awt/qt/awt.h:32,
from ../../src/share/basis/native/awt/qt/QtFontMetrics.cpp:28:
/usr/include/ft2build.h:56:38: error: freetype/config/ftheader.h: No such file or directory

My output from freetype-config --cflags is -I/usr/include/freetype2. Does this still have something to do with the path or should I downgrade my qt embedded version (again)?

Thanks,

Jay Lee
jslee06

jslee06
Offline
Joined: 2008-06-21

I forgot to mention I am using Fedora 9 but I can switch to Ubuntu if people don't like me logging in as root all the time.

rockie12
Offline
Joined: 2008-07-25

Hi all
I would like to assist with this project. What do I need to do? Where do I start?

Thanks
Dean-O

Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
> Hi all
> I would like to assist with this project. What do I need to do? Where do I start?
>

Hi Dean-O

Here's the current thread about porting phoneME Advanced to the Palm OS:

http://forums.java.net/jive/thread.jspa?messageID=294963#295183

There are still a lot of hurdles with this project because Palm OS is so
limited (no full std C lib, no good multithreading lib support, etc.)

If you can read over the link to the full mail thread (above) and
comment on the hurdles we have already discussed in that thread, you
might be able to help by recommending what to try next.

Thanks,
Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

mgreco32
Offline
Joined: 2005-01-03

All,

I'd like to volunteer. Shoot me an email at mgreco@chartermi.net with instructions on getting started so I don't clutter this thead too much. I have 12+ years of dev experience in C, C++ and Java. Never used Palm SDK (if that's needed). I have a Palm Treo 700p to test on with IBM WEME installed from Palm (before it was unavailable).

Thanks
Mike (mgreco32)

Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
> All,
>
> I'd like to volunteer. Shoot me an email at mgreco@chartermi.net with instructions on getting started so I don't clutter this thead too much. I have 12+ years of dev experience in C, C++ and Java. Never used Palm SDK (if that's needed). I have a Palm Treo 700p to test on with IBM WEME installed from Palm (before it was unavailable).
>
> Thanks
> Mike (mgreco32)
>

Hi Mike,

As you can see by the current thread about porting phoneME Advanced to
the Palm OS:

http://forums.java.net/jive/thread.jspa?messageID=294963#295183

there are still a lot of hurdles with the Palm OS being so limited (no
full std C lib, no good multithreading lib support, etc.)

So, this project is kind of stuck currently. It might be that the
easier solution would be to use Davy Preuveneers' current phoneME
Advanced Windows Mobile binaries
(http://www.cs.kuleuven.be/~davy/phoneme/downloads.htm) on the future new
models of Palm devices with WinMobile.

Ex.

Palm Treo Pro:
http://www.infoworld.com/article/08/08/20/Palm-Treo-Pro-steps-into-smart...

Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

ebresie
Offline
Joined: 2003-08-06

> phonemeadvanced@mobileandembedded.org wrote:
> > All,
> >
> > I'd like to volunteer. Shoot me an email at
> mgreco@chartermi.net with instructions on getting
> started so I don't clutter this thead too much. I
> have 12+ years of dev experience in C, C++ and Java.
> Never used Palm SDK (if that's needed). I have a
> Palm Treo 700p to test on with IBM WEME installed
> from Palm (before it was unavailable).
>
> > Thanks
> > Mike (mgreco32)
> >
>
> Hi Mike,
>
> As you can see by the current thread about porting
> phoneME Advanced to
> the Palm OS:
>
> http://forums.java.net/jive/thread.jspa?messageID=2949
> 63#295183
>
> there are still a lot of hurdles with the Palm OS
> being so limited (no
> full std C lib, no good multithreading lib support,
> etc.)
>
> So, this project is kind of stuck currently. It
> might be that the
> easier solution would be to use Davy Preuveneers'
> current phoneME
> Advanced Windows Mobile binaries
> (http://www.cs.kuleuven.be/~davy/phoneme/downloads.htm
> ) on the future new
> models of Palm devices with WinMobile.
>
> Ex.
>
> Palm Treo Pro:
> http://www.infoworld.com/article/08/08/20/Palm-Treo-Pr
> o-steps-into-smartphone-ring_1.html
>
>
> Hinkmond

Regretfully, the new device is Windows Mobile based. Palm supports two OS on their devices. Palm OS and Windows Mobile. However, the two are not compatible. The 700p he mentions is a Palm OS based, so won't be able to do so without buying a new device.

Eric

rockie12
Offline
Joined: 2008-07-25

Hi all.
How goes this project? Have you tried superwaba from Brazil? It is a Java like language that works cross platform palm os and windows mobile devices. Why are you reinventing the wheel here?

ebresie
Offline
Joined: 2003-08-06

The project has been slowing recently due to some Palm (lack of) threading issues being investigated.

We are simply trying to implement for Palm / Garnet a full implementation of phoneME Advanced version in the open source realm including CDC based implementation which does not appear to exist as part of superwaba yet.

I have heard of superwaba and have heard good things about it...

Eric

nileshpereira
Offline
Joined: 2003-08-22

Anyone managed to actually build and run arm native code on the palm yet? I finally got the source of Tom's prc-tools so hopefully I will be able to build a working arm-palmos toolchain soon.

ebresie
Offline
Joined: 2003-08-06

As of this moment, nope...

Not sure if it will help any, but did find the following ARM programming FAQ that may be of help:

http://www.flippinbits.com/twiki/index.php?page=arm-development

And relating to threading:

http://www.flippinbits.com/twiki/index.php?page=how-to-do-threads

I have been looking into porting pth...I tried using a ARM version but was unable to get very far as it seemed to require access to crt0 libraries which did not seem to be immediately available for the include arm-palmos included version. I used the following:

# ARM Palm OS based
#CC=arm-palmos-gcc CPPFLAGS=-I/usr/arm-palmos/include LIBS=-L/usr/arm-palmos/lib ./configure --prefix=/src/threads/pth/pth-2.0.7/build --enable-pthread --enable-test --enable-debug --with-mctx-mth=sjlj --with-mctx-dsp=sjlje --with-mctx-stk=none

So then I reverted back to the m68k version using the following:

## M68K Palm OS based
CC=m68k-palmos-gcc CPPFLAGS=-I/usr/m68k-palmos/include LIBS=-L=/usr/m68k-palmos/lib ./configure --prefix=/src/threads/pth/pth-2.0.7/build --enable-pthread --enable-test --enable-debug --with-mctx-mth=sjlj --with-mctx-dsp=sjlje --with-mctx-stk=none

This got me a little further...

I then encountered the following:

configure:2033: checking for C compiler default output file name
configure:2036: m68k-palmos-gcc -I/usr/m68k-palmos/include conftest.c -L=/usr/
m68k-palmos/lib >&5
/usr/m68k-palmos/lib/crt0.o(.text+0x64): In function `start':
crt0.c:69: undefined reference to `PilotMain'
collect2: ld returned 1 exit status
configure:2039: $? = 1
configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:2078: error: C compiler cannot create executables

Eric