I am close to porting NME and HXCPP to Palm webOS. Could anyone help me with a couple last things?

[singmajesty]

Hi everyone,

I am working on compiling NME so that I can build HXCPP projects for Palm  
webOS.

I have been able to successfully compile and execute an HXCPP-based haXe  
project on the device, but unfortunately it failed because it was missing  
nme.ndll. Now I have been in the process of compiling NME so that my  
application can run. I am successfully compiling a Palm webOS compatible  
nme.ndll file, with the exception of a couple compiler/linking issues.

When I include SurfaceIO.cpp, it throws some compiler errors. It throws  
"invalid conversion" errors on lines 54-58, and throws multiple "too many  
arguments to function" errors when referencing methods defined in  
jpeglib.h. I am using the latest SVN revision of the nekonme, hxcpp and  
sdl-static libraries, but this makes me wonder if I need a different  
version of libjpeg? However, I also noticed that the iPhone port uses a  
separate file for SurfaceIO, written in Objective-C. Writing C/C++  
applications for Palm is very, very similar to iPhone, except, of course,  
that it doesn't support Objective-C, so the other possibility I wonder is  
if the standard SurfaceIO.cpp is incompatible, so would I then need a C++  
version of the iPhone SurfaceIO.mm file for it to work?

When I leave this file out, everything compiles fine, but it throws a link  
error because it cannot find the SurfaceIO methods. Other than SurfaceIO,  
the other files I would need to provide a complete implementation are  
probably the other two iPhone files, which are also written in  
Objective-C. One is for Sound, and one is for the frame. I can't use the  
frame from the Android port, since I am not hooking the application into  
Java, and I can't use the frame from the Windows version, since I'm using  
OpenGL ES. I'm guessing I probably will need a frame like the iPhone one,  
but in C++. Lastly, the references I see in the iPhone sound file look  
similar to what I've seen for Palm, but again, in C++. Sound is not as  
large of an issue for me right now, so the frame and SurfaceIO files seem  
to be the only links missing in the chain for publishing for Palm.

I found a small bug in one of the files, added string.h to one of the  
other files, and updated BuildCommon.xml (for HXCPP), Build.xml (for NME)  
and OpenGLContext.cpp in order to support the "Palm" export target. I'd  
love to be able to share this with the project when I get this all working.

If it is true that I will need a couple files which aren't present in the  
project right now, I'm willing to try and write them myself, since I know  
the creators of the project may not be as interested or motivated in a  
Palm port as I am. If that's the case, it would help to just have a couple  
pointers so I understand how the stage and SurfaceIO files connect to the  
framework, so I know what I need to write.

Help is appreciated! Thanks!



--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

--
haXe - an open source web programming language
http://haxe.org

[singmajesty]

Quick update:

I just tried to use SDL for the stage and sound ... still upset about  
SurfaceIO. I created a stub .cpp file so it wouldn't complain about that  
anymore, and I get the following (and I think final) link error:



c:/program files (x86)/codesourcery/sourcery g++  
lite/bin/../arm-none-linux-gnue
abi/libc/usr/lib/crt1.o: In function `_start':
init.c:(.text+0x30): undefined reference to `main'
collect2: ld returned 1 exit status
Called from <null> line 1
Called from BuildTool.hx line 883
Called from BuildTool.hx line 451
Called from BuildTool.hx line 474
Called from BuildTool.hx line 547
Called from BuildTool.hx line 628
Called from BuildTool.hx line 256
Uncaught exception - Error : 1 - build cancelled



Is this normal?


Thanks again if anyone can help me! (Please? :)



On Sun, 11 Jul 2010 18:18:58 -0700, Joshua Granick  
<[hidden email]> wrote:

> Hi everyone,
>
> I am working on compiling NME so that I can build HXCPP projects for  
> Palm webOS.
>
> I have been able to successfully compile and execute an HXCPP-based haXe  
> project on the device, but unfortunately it failed because it was  
> missing nme.ndll. Now I have been in the process of compiling NME so  
> that my application can run. I am successfully compiling a Palm webOS  
> compatible nme.ndll file, with the exception of a couple  
> compiler/linking issues.
>
> When I include SurfaceIO.cpp, it throws some compiler errors. It throws  
> "invalid conversion" errors on lines 54-58, and throws multiple "too  
> many arguments to function" errors when referencing methods defined in  
> jpeglib.h. I am using the latest SVN revision of the nekonme, hxcpp and  
> sdl-static libraries, but this makes me wonder if I need a different  
> version of libjpeg? However, I also noticed that the iPhone port uses a  
> separate file for SurfaceIO, written in Objective-C. Writing C/C++  
> applications for Palm is very, very similar to iPhone, except, of  
> course, that it doesn't support Objective-C, so the other possibility I  
> wonder is if the standard SurfaceIO.cpp is incompatible, so would I then  
> need a C++ version of the iPhone SurfaceIO.mm file for it to work?
>
> When I leave this file out, everything compiles fine, but it throws a  
> link error because it cannot find the SurfaceIO methods. Other than  
> SurfaceIO, the other files I would need to provide a complete  
> implementation are probably the other two iPhone files, which are also  
> written in Objective-C. One is for Sound, and one is for the frame. I  
> can't use the frame from the Android port, since I am not hooking the  
> application into Java, and I can't use the frame from the Windows  
> version, since I'm using OpenGL ES. I'm guessing I probably will need a  
> frame like the iPhone one, but in C++. Lastly, the references I see in  
> the iPhone sound file look similar to what I've seen for Palm, but  
> again, in C++. Sound is not as large of an issue for me right now, so  
> the frame and SurfaceIO files seem to be the only links missing in the  
> chain for publishing for Palm.
>
> I found a small bug in one of the files, added string.h to one of the  
> other files, and updated BuildCommon.xml (for HXCPP), Build.xml (for  
> NME) and OpenGLContext.cpp in order to support the "Palm" export target.  
> I'd love to be able to share this with the project when I get this all  
> working.
>
> If it is true that I will need a couple files which aren't present in  
> the project right now, I'm willing to try and write them myself, since I  
> know the creators of the project may not be as interested or motivated  
> in a Palm port as I am. If that's the case, it would help to just have a  
> couple pointers so I understand how the stage and SurfaceIO files  
> connect to the framework, so I know what I need to write.
>
> Help is appreciated! Thanks!
>
>
>

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

--
haXe - an open source web programming language
http://haxe.org

[singmajesty]

Hi again,

I think I've got it. I'm compiling fine without errors. The only problem,  
I think, is that the compiler must be doing both NME and my application as  
an executable. I need to figure out how to compile a shared library or  
dynamic shared library using GCC. Once I do that, (with fingers crossed),  
I'll be ready to run applications on the phone.

Fortunately hxcpp already works for so many platforms already, there's a  
wealth of code available to pick and choose what to use for a new  
platform. I've set it up to use SDL for graphics to start, so I can see it  
working, then I can invest some time into tying up a couple loose ends so  
that I can have GL for graphics instead




On Sun, 11 Jul 2010 18:34:37 -0700, Joshua Granick  
<[hidden email]> wrote:

> Quick update:
>
> I just tried to use SDL for the stage and sound ... still upset about  
> SurfaceIO. I created a stub .cpp file so it wouldn't complain about that  
> anymore, and I get the following (and I think final) link error:
>
>
>
> c:/program files (x86)/codesourcery/sourcery g++  
> lite/bin/../arm-none-linux-gnue
> abi/libc/usr/lib/crt1.o: In function `_start':
> init.c:(.text+0x30): undefined reference to `main'
> collect2: ld returned 1 exit status
> Called from <null> line 1
> Called from BuildTool.hx line 883
> Called from BuildTool.hx line 451
> Called from BuildTool.hx line 474
> Called from BuildTool.hx line 547
> Called from BuildTool.hx line 628
> Called from BuildTool.hx line 256
> Uncaught exception - Error : 1 - build cancelled
>
>
>
> Is this normal?
>
>
> Thanks again if anyone can help me! (Please? :)
>
>
>
> On Sun, 11 Jul 2010 18:18:58 -0700, Joshua Granick  
> <[hidden email]> wrote:
>
>> Hi everyone,
>>
>> I am working on compiling NME so that I can build HXCPP projects for  
>> Palm webOS.
>>
>> I have been able to successfully compile and execute an HXCPP-based  
>> haXe project on the device, but unfortunately it failed because it was  
>> missing nme.ndll. Now I have been in the process of compiling NME so  
>> that my application can run. I am successfully compiling a Palm webOS  
>> compatible nme.ndll file, with the exception of a couple  
>> compiler/linking issues.
>>
>> When I include SurfaceIO.cpp, it throws some compiler errors. It throws  
>> "invalid conversion" errors on lines 54-58, and throws multiple "too  
>> many arguments to function" errors when referencing methods defined in  
>> jpeglib.h. I am using the latest SVN revision of the nekonme, hxcpp and  
>> sdl-static libraries, but this makes me wonder if I need a different  
>> version of libjpeg? However, I also noticed that the iPhone port uses a  
>> separate file for SurfaceIO, written in Objective-C. Writing C/C++  
>> applications for Palm is very, very similar to iPhone, except, of  
>> course, that it doesn't support Objective-C, so the other possibility I  
>> wonder is if the standard SurfaceIO.cpp is incompatible, so would I  
>> then need a C++ version of the iPhone SurfaceIO.mm file for it to work?
>>
>> When I leave this file out, everything compiles fine, but it throws a  
>> link error because it cannot find the SurfaceIO methods. Other than  
>> SurfaceIO, the other files I would need to provide a complete  
>> implementation are probably the other two iPhone files, which are also  
>> written in Objective-C. One is for Sound, and one is for the frame. I  
>> can't use the frame from the Android port, since I am not hooking the  
>> application into Java, and I can't use the frame from the Windows  
>> version, since I'm using OpenGL ES. I'm guessing I probably will need a  
>> frame like the iPhone one, but in C++. Lastly, the references I see in  
>> the iPhone sound file look similar to what I've seen for Palm, but  
>> again, in C++. Sound is not as large of an issue for me right now, so  
>> the frame and SurfaceIO files seem to be the only links missing in the  
>> chain for publishing for Palm.
>>
>> I found a small bug in one of the files, added string.h to one of the  
>> other files, and updated BuildCommon.xml (for HXCPP), Build.xml (for  
>> NME) and OpenGLContext.cpp in order to support the "Palm" export  
>> target. I'd love to be able to share this with the project when I get  
>> this all working.
>>
>> If it is true that I will need a couple files which aren't present in  
>> the project right now, I'm willing to try and write them myself, since  
>> I know the creators of the project may not be as interested or  
>> motivated in a Palm port as I am. If that's the case, it would help to  
>> just have a couple pointers so I understand how the stage and SurfaceIO  
>> files connect to the framework, so I know what I need to write.
>>
>> Help is appreciated! Thanks!
>>
>>
>>
>
>

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

--
haXe - an open source web programming language
http://haxe.org

[Gamehaxe]

Hi,
It sounds like you are on the right track.

You should first try to use common/SurfaceIO.cpp.  The iphone one is
there really only there to save space (and to add additional image  
formats) -
you can actually use the common one instead.  This condition is handled
in the Build.xml file.
You will need to link again jpeg/png/z as well - there are versions on
these in the sdl-static project - but you might need to compile for
your system.

Each target provides a "Stage", which is responsible for setting up the
window and OpenGL context, passing events onto the the rest of the code
and running the main-loop.  Audio is also done differently for each target.

If you are using SDL, you may just be able to use the SDL stage, and
not have to do anything else.  SDL is doing something similar to
encapsulating the stage, so there is a bit of overlap there.
You would probably write your own "Stage" by starting with some
example code for your device - something that creates a window and
sets up opengl.  The stage code will follow this - you basically
construct events like "Event event(etMouseMove,x,y)" and call  
"ProcessEvent".

Your "main" function should come from HX_BEGIN_MAIN in  
$HXCPP/include/hx/Macros.h,
which should be included from  the generated src/__main__.cpp.
If you are getting the unresolved from compiling nme, then it
looks like you are using the wrong link flags.

In the nme2 Build.xml, it has the lines:

<set name="ndll-tool" value="dll" unless="iphone"/>
<set name="ndll-tool" value="static" if="iphone"/>

and then:

<target id="NDLL" output="nme${name_extra}" tool="linker"  
toolid="${ndll-tool}">

sets the "tool"="linker" and "toolid"="dll" for non-iphone builds.

This then refers the  section in $HXCPP/build/BuildCommon.xml (eg, for  
linux) with the matching id:

<linker id="dll" exe="g++" if="linux">
   <flag value="-shared"/>
   <flag value="-fpic"/>
   <flag value="-fPIC"/>
   <flag value="-m32" unless="HXCPP_M64"/>
   <flag value="-W,l--unresolved-symbols=report-all"/>
   <flag value="-debug" if="debug"/>
   <ext value=".dso"/>
   <outflag value="-o "/>
</linker>

Notice the "-shared" flag - this is what makes it create a .dso instead of  
a .exe.

If you paste the link lines, I will have another look.

I am more that happy to integrate your compiler options it the hxcpp build  
code,
and into NME.

For a new hxcpp compiler, I generally start with a "-D compiler" flag to  
the
haxe compile line.  All these automatically get passed to the build script.
When compiling NME, you need to add these manually (Note no space:  
-Dcompiler).
Then, in BuildTool.hx, you can follow the android pattern to set up a  
"BINDIR"
and any other defines you want to use in BuildCommon.xml.
Then in BuildCommon.xml, you can do

<linker id="dll" exe="g++" if="palmos"> ...

You may also want to add a "-DPALMOS" to you compiler flags, so you can use
this in the NME c++ code.


Hope this helps,

Hugh

>
> Hi again,
>
> I think I've got it. I'm compiling fine without errors. The only  
> problem, I think, is that the compiler must be doing both NME and my  
> application as an executable. I need to figure out how to compile a  
> shared library or dynamic shared library using GCC. Once I do that,  
> (with fingers crossed), I'll be ready to run applications on the phone.
>
> Fortunately hxcpp already works for so many platforms already, there's a  
> wealth of code available to pick and choose what to use for a new  
> platform. I've set it up to use SDL for graphics to start, so I can see  
> it working, then I can invest some time into tying up a couple loose  
> ends so that I can have GL for graphics instead
>
>
>
>
> On Sun, 11 Jul 2010 18:34:37 -0700, Joshua Granick  
> <[hidden email]> wrote:
>
>> Quick update:
>>
>> I just tried to use SDL for the stage and sound ... still upset about  
>> SurfaceIO. I created a stub .cpp file so it wouldn't complain about  
>> that anymore, and I get the following (and I think final) link error:
>>
>>
>>
>> c:/program files (x86)/codesourcery/sourcery g++  
>> lite/bin/../arm-none-linux-gnue
>> abi/libc/usr/lib/crt1.o: In function `_start':
>> init.c:(.text+0x30): undefined reference to `main'
>> collect2: ld returned 1 exit status
>> Called from <null> line 1
>> Called from BuildTool.hx line 883
>> Called from BuildTool.hx line 451
>> Called from BuildTool.hx line 474
>> Called from BuildTool.hx line 547
>> Called from BuildTool.hx line 628
>> Called from BuildTool.hx line 256
>> Uncaught exception - Error : 1 - build cancelled
>>
>>
>>
>> Is this normal?
>>
>>
>> Thanks again if anyone can help me! (Please? :)
>>
>>
>>
>> On Sun, 11 Jul 2010 18:18:58 -0700, Joshua Granick  
>> <[hidden email]> wrote:
>>
>>> Hi everyone,
>>>
>>> I am working on compiling NME so that I can build HXCPP projects for  
>>> Palm webOS.
>>>
>>> I have been able to successfully compile and execute an HXCPP-based  
>>> haXe project on the device, but unfortunately it failed because it was  
>>> missing nme.ndll. Now I have been in the process of compiling NME so  
>>> that my application can run. I am successfully compiling a Palm webOS  
>>> compatible nme.ndll file, with the exception of a couple  
>>> compiler/linking issues.
>>>
>>> When I include SurfaceIO.cpp, it throws some compiler errors. It  
>>> throws "invalid conversion" errors on lines 54-58, and throws multiple  
>>> "too many arguments to function" errors when referencing methods  
>>> defined in jpeglib.h. I am using the latest SVN revision of the  
>>> nekonme, hxcpp and sdl-static libraries, but this makes me wonder if I  
>>> need a different version of libjpeg? However, I also noticed that the  
>>> iPhone port uses a separate file for SurfaceIO, written in  
>>> Objective-C. Writing C/C++ applications for Palm is very, very similar  
>>> to iPhone, except, of course, that it doesn't support Objective-C, so  
>>> the other possibility I wonder is if the standard SurfaceIO.cpp is  
>>> incompatible, so would I then need a C++ version of the iPhone  
>>> SurfaceIO.mm file for it to work?
>>>
>>> When I leave this file out, everything compiles fine, but it throws a  
>>> link error because it cannot find the SurfaceIO methods. Other than  
>>> SurfaceIO, the other files I would need to provide a complete  
>>> implementation are probably the other two iPhone files, which are also  
>>> written in Objective-C. One is for Sound, and one is for the frame. I  
>>> can't use the frame from the Android port, since I am not hooking the  
>>> application into Java, and I can't use the frame from the Windows  
>>> version, since I'm using OpenGL ES. I'm guessing I probably will need  
>>> a frame like the iPhone one, but in C++. Lastly, the references I see  
>>> in the iPhone sound file look similar to what I've seen for Palm, but  
>>> again, in C++. Sound is not as large of an issue for me right now, so  
>>> the frame and SurfaceIO files seem to be the only links missing in the  
>>> chain for publishing for Palm.
>>>
>>> I found a small bug in one of the files, added string.h to one of the  
>>> other files, and updated BuildCommon.xml (for HXCPP), Build.xml (for  
>>> NME) and OpenGLContext.cpp in order to support the "Palm" export  
>>> target. I'd love to be able to share this with the project when I get  
>>> this all working.
>>>
>>> If it is true that I will need a couple files which aren't present in  
>>> the project right now, I'm willing to try and write them myself, since  
>>> I know the creators of the project may not be as interested or  
>>> motivated in a Palm port as I am. If that's the case, it would help to  
>>> just have a couple pointers so I understand how the stage and  
>>> SurfaceIO files connect to the framework, so I know what I need to  
>>> write.
>>>
>>> Help is appreciated! Thanks!
>>>
>>>
>>>
>>
>>
>

--
haXe - an open source web programming language
http://haxe.org

[singmajesty]

Hi,

As you suggested, I am using a modified version of BuildCommon.xml to  
configure compiling and linking.

http://pastie.org/1041447


As for Build.xml, I am testing it now under SDL instead of GL, since SDL  
already has the stage and sound. I figure that I can look at writing a  
simple GL stage once I can at least get a "Hello World" application  
running under SDL. I'm using a duplicate of the AndroidFont.cpp file, with  
Android log messages removed, and I am using a simple stub version of  
SurfaceIO which does nothing, but does provide completion so the library  
will compile.

http://pastie.org/1041462


Under these settings, it does compile without errors. There also are a  
couple places where I added #include <string.h> to fix errors, one place  
where I had to replace #if NEKO_LINUX with #ifndef NEKO_LINUX, and a few  
places (such as OpenGLContext.cpp and Lib.cpp) where I used the PALM  
directive to specify the correct extension and options.

http://pastie.org/1041472


Under the BuildCommon.xml settings, my simple project (which runs in Flash  
and in Windows C++) compiles fine as well. There are no errors, but there  
are a few library warnings, which I'm told are to be expected. It just  
warns about system libraries which are present on the phone.

http://pastie.org/1041482


I then copied my executable and library onto the phone, and set  
LD_LIBRARY_PATH to the same directory, so it could find the library ...  
and it does. When I run strace Main-debug, I can see that it finds the  
file. If I compile NME without -nostdlibs, it will provide an error saying  
that it could not load module std@get_env__1. If I do not include the  
flag, it says that it cannot load module nme@filter_image__2.

http://pastie.org/1041490



I'm not sure if there are other things I can do to debug how this is all  
fitting together? This is all a learning experience for me, so please feel  
free to let me know if there are other things I can do to help provide  
useful debugging information.


By the way, I believe that this is the file which was having an error. In  
other cases I needed to add a header include, or occasionally needed a "me  
too!" type of compiler directive, where it applied separate code for  
IPHONE and ANDROID, and so I needed to add PALM in there too. However,  
this one said it had no argument after #if. When I try and compile it as  
#ifdef, it says that _dyld_image_count and _dyld_get_image_name are not  
defined. As it seemed like the closest neighbor in this case was ANDROID,  
which did not reference #include <mach-o/dyld.h>, I figured that #ifndef  
was the right choice (which compiles). Here's a paste of what that file  
looks like

http://pastie.org/1041509



Thank you!



Joshua




On Mon, 12 Jul 2010 09:50:51 -0700, Hugh Sanderson <[hidden email]>  
wrote:

> Hi,
> It sounds like you are on the right track.
>
> You should first try to use common/SurfaceIO.cpp.  The iphone one is
> there really only there to save space (and to add additional image  
> formats) -
> you can actually use the common one instead.  This condition is handled
> in the Build.xml file.
> You will need to link again jpeg/png/z as well - there are versions on
> these in the sdl-static project - but you might need to compile for
> your system.
>
> Each target provides a "Stage", which is responsible for setting up the
> window and OpenGL context, passing events onto the the rest of the code
> and running the main-loop.  Audio is also done differently for each  
> target.
>
> If you are using SDL, you may just be able to use the SDL stage, and
> not have to do anything else.  SDL is doing something similar to
> encapsulating the stage, so there is a bit of overlap there.
> You would probably write your own "Stage" by starting with some
> example code for your device - something that creates a window and
> sets up opengl.  The stage code will follow this - you basically
> construct events like "Event event(etMouseMove,x,y)" and call  
> "ProcessEvent".
>
> Your "main" function should come from HX_BEGIN_MAIN in  
> $HXCPP/include/hx/Macros.h,
> which should be included from  the generated src/__main__.cpp.
> If you are getting the unresolved from compiling nme, then it
> looks like you are using the wrong link flags.
>
> In the nme2 Build.xml, it has the lines:
>
> <set name="ndll-tool" value="dll" unless="iphone"/>
> <set name="ndll-tool" value="static" if="iphone"/>
>
> and then:
>
> <target id="NDLL" output="nme${name_extra}" tool="linker"  
> toolid="${ndll-tool}">
>
> sets the "tool"="linker" and "toolid"="dll" for non-iphone builds.
>
> This then refers the  section in $HXCPP/build/BuildCommon.xml (eg, for  
> linux) with the matching id:
>
> <linker id="dll" exe="g++" if="linux">
>    <flag value="-shared"/>
>    <flag value="-fpic"/>
>    <flag value="-fPIC"/>
>    <flag value="-m32" unless="HXCPP_M64"/>
>    <flag value="-W,l--unresolved-symbols=report-all"/>
>    <flag value="-debug" if="debug"/>
>    <ext value=".dso"/>
>    <outflag value="-o "/>
> </linker>
>
> Notice the "-shared" flag - this is what makes it create a .dso instead  
> of a .exe.
>
> If you paste the link lines, I will have another look.
>
> I am more that happy to integrate your compiler options it the hxcpp  
> build code,
> and into NME.
>
> For a new hxcpp compiler, I generally start with a "-D compiler" flag to  
> the
> haxe compile line.  All these automatically get passed to the build  
> script.
> When compiling NME, you need to add these manually (Note no space:  
> -Dcompiler).
> Then, in BuildTool.hx, you can follow the android pattern to set up a  
> "BINDIR"
> and any other defines you want to use in BuildCommon.xml.
> Then in BuildCommon.xml, you can do
>
> <linker id="dll" exe="g++" if="palmos"> ...
>
> You may also want to add a "-DPALMOS" to you compiler flags, so you can  
> use
> this in the NME c++ code.
>
>
> Hope this helps,
>
> Hugh
>
>>
>> Hi again,
>>
>> I think I've got it. I'm compiling fine without errors. The only  
>> problem, I think, is that the compiler must be doing both NME and my  
>> application as an executable. I need to figure out how to compile a  
>> shared library or dynamic shared library using GCC. Once I do that,  
>> (with fingers crossed), I'll be ready to run applications on the phone.
>>
>> Fortunately hxcpp already works for so many platforms already, there's  
>> a wealth of code available to pick and choose what to use for a new  
>> platform. I've set it up to use SDL for graphics to start, so I can see  
>> it working, then I can invest some time into tying up a couple loose  
>> ends so that I can have GL for graphics instead
>>
>>
>>
>>
>> On Sun, 11 Jul 2010 18:34:37 -0700, Joshua Granick  
>> <[hidden email]> wrote:
>>
>>> Quick update:
>>>
>>> I just tried to use SDL for the stage and sound ... still upset about  
>>> SurfaceIO. I created a stub .cpp file so it wouldn't complain about  
>>> that anymore, and I get the following (and I think final) link error:
>>>
>>>
>>>
>>> c:/program files (x86)/codesourcery/sourcery g++  
>>> lite/bin/../arm-none-linux-gnue
>>> abi/libc/usr/lib/crt1.o: In function `_start':
>>> init.c:(.text+0x30): undefined reference to `main'
>>> collect2: ld returned 1 exit status
>>> Called from <null> line 1
>>> Called from BuildTool.hx line 883
>>> Called from BuildTool.hx line 451
>>> Called from BuildTool.hx line 474
>>> Called from BuildTool.hx line 547
>>> Called from BuildTool.hx line 628
>>> Called from BuildTool.hx line 256
>>> Uncaught exception - Error : 1 - build cancelled
>>>
>>>
>>>
>>> Is this normal?
>>>
>>>
>>> Thanks again if anyone can help me! (Please? :)
>>>
>>>
>>>
>>> On Sun, 11 Jul 2010 18:18:58 -0700, Joshua Granick  
>>> <[hidden email]> wrote:
>>>
>>>> Hi everyone,
>>>>
>>>> I am working on compiling NME so that I can build HXCPP projects for  
>>>> Palm webOS.
>>>>
>>>> I have been able to successfully compile and execute an HXCPP-based  
>>>> haXe project on the device, but unfortunately it failed because it  
>>>> was missing nme.ndll. Now I have been in the process of compiling NME  
>>>> so that my application can run. I am successfully compiling a Palm  
>>>> webOS compatible nme.ndll file, with the exception of a couple  
>>>> compiler/linking issues.
>>>>
>>>> When I include SurfaceIO.cpp, it throws some compiler errors. It  
>>>> throws "invalid conversion" errors on lines 54-58, and throws  
>>>> multiple "too many arguments to function" errors when referencing  
>>>> methods defined in jpeglib.h. I am using the latest SVN revision of  
>>>> the nekonme, hxcpp and sdl-static libraries, but this makes me wonder  
>>>> if I need a different version of libjpeg? However, I also noticed  
>>>> that the iPhone port uses a separate file for SurfaceIO, written in  
>>>> Objective-C. Writing C/C++ applications for Palm is very, very  
>>>> similar to iPhone, except, of course, that it doesn't support  
>>>> Objective-C, so the other possibility I wonder is if the standard  
>>>> SurfaceIO.cpp is incompatible, so would I then need a C++ version of  
>>>> the iPhone SurfaceIO.mm file for it to work?
>>>>
>>>> When I leave this file out, everything compiles fine, but it throws a  
>>>> link error because it cannot find the SurfaceIO methods. Other than  
>>>> SurfaceIO, the other files I would need to provide a complete  
>>>> implementation are probably the other two iPhone files, which are  
>>>> also written in Objective-C. One is for Sound, and one is for the  
>>>> frame. I can't use the frame from the Android port, since I am not  
>>>> hooking the application into Java, and I can't use the frame from the  
>>>> Windows version, since I'm using OpenGL ES. I'm guessing I probably  
>>>> will need a frame like the iPhone one, but in C++. Lastly, the  
>>>> references I see in the iPhone sound file look similar to what I've  
>>>> seen for Palm, but again, in C++. Sound is not as large of an issue  
>>>> for me right now, so the frame and SurfaceIO files seem to be the  
>>>> only links missing in the chain for publishing for Palm.
>>>>
>>>> I found a small bug in one of the files, added string.h to one of the  
>>>> other files, and updated BuildCommon.xml (for HXCPP), Build.xml (for  
>>>> NME) and OpenGLContext.cpp in order to support the "Palm" export  
>>>> target. I'd love to be able to share this with the project when I get  
>>>> this all working.
>>>>
>>>> If it is true that I will need a couple files which aren't present in  
>>>> the project right now, I'm willing to try and write them myself,  
>>>> since I know the creators of the project may not be as interested or  
>>>> motivated in a Palm port as I am. If that's the case, it would help  
>>>> to just have a couple pointers so I understand how the stage and  
>>>> SurfaceIO files connect to the framework, so I know what I need to  
>>>> write.
>>>>
>>>> Help is appreciated! Thanks!
>>>>
>>>>
>>>>
>>>
>>>
>>
>

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

--
haXe - an open source web programming language
http://haxe.org

[singmajesty]

Okay, so I think I'm up and running with nme2 for my project. No wonder it  
wouldn't work! nme.so is compiled using the version2 source, but my  
project was compiled using the original source code.

I was confused before because of neash, but it looks like nme2 doesn't  
require neash? I removed neash from the list of libraries used in my  
project, and changed flash:neash to flash:nme, and removed the cpp  
conditional flags in the document class for the project.

Here are the .hx files (very simple) I am using in my project now

http://pastie.org/1041594
http://pastie.org/1041595


I can compile it without errors now, but when I run it, it throws a new  
error. Now it says it cannot load nme@nme_create_display_object. This  
makes a lot of sense, since DisplayObject is the base class for Sprite,  
and the first module that your DisplayObject class attempts to load  
appears to be nme_create_display_object

http://code.google.com/p/nekonme/source/browse/trunk/version2/nme/display/DisplayObject.hx?spec=svn446&r=446


I'm guessing this means that I'm all up and running on nme2, but it still  
isn't completely synced with the nme.so file I compiled, somehow? If I  
changed its extension to nme.dso would it make any difference?





On Mon, 12 Jul 2010 13:44:45 -0700, Joshua Granick  
<[hidden email]> wrote:

> Hi,
>
> As you suggested, I am using a modified version of BuildCommon.xml to  
> configure compiling and linking.
>
> http://pastie.org/1041447
>
>
> As for Build.xml, I am testing it now under SDL instead of GL, since SDL  
> already has the stage and sound. I figure that I can look at writing a  
> simple GL stage once I can at least get a "Hello World" application  
> running under SDL. I'm using a duplicate of the AndroidFont.cpp file,  
> with Android log messages removed, and I am using a simple stub version  
> of SurfaceIO which does nothing, but does provide completion so the  
> library will compile.
>
> http://pastie.org/1041462
>
>
> Under these settings, it does compile without errors. There also are a  
> couple places where I added #include <string.h> to fix errors, one place  
> where I had to replace #if NEKO_LINUX with #ifndef NEKO_LINUX, and a few  
> places (such as OpenGLContext.cpp and Lib.cpp) where I used the PALM  
> directive to specify the correct extension and options.
>
> http://pastie.org/1041472
>
>
> Under the BuildCommon.xml settings, my simple project (which runs in  
> Flash and in Windows C++) compiles fine as well. There are no errors,  
> but there are a few library warnings, which I'm told are to be expected.  
> It just warns about system libraries which are present on the phone.
>
> http://pastie.org/1041482
>
>
> I then copied my executable and library onto the phone, and set  
> LD_LIBRARY_PATH to the same directory, so it could find the library ...  
> and it does. When I run strace Main-debug, I can see that it finds the  
> file. If I compile NME without -nostdlibs, it will provide an error  
> saying that it could not load module std@get_env__1. If I do not include  
> the flag, it says that it cannot load module nme@filter_image__2.
>
> http://pastie.org/1041490
>
>
>
> I'm not sure if there are other things I can do to debug how this is all  
> fitting together? This is all a learning experience for me, so please  
> feel free to let me know if there are other things I can do to help  
> provide useful debugging information.
>
>
> By the way, I believe that this is the file which was having an error.  
> In other cases I needed to add a header include, or occasionally needed  
> a "me too!" type of compiler directive, where it applied separate code  
> for IPHONE and ANDROID, and so I needed to add PALM in there too.  
> However, this one said it had no argument after #if. When I try and  
> compile it as #ifdef, it says that _dyld_image_count and  
> _dyld_get_image_name are not defined. As it seemed like the closest  
> neighbor in this case was ANDROID, which did not reference #include  
> <mach-o/dyld.h>, I figured that #ifndef was the right choice (which  
> compiles). Here's a paste of what that file looks like
>
> http://pastie.org/1041509
>
>
>
> Thank you!
>
>
>
> Joshua
>
>
>
>
> On Mon, 12 Jul 2010 09:50:51 -0700, Hugh Sanderson  
> <[hidden email]> wrote:
>
>> Hi,
>> It sounds like you are on the right track.
>>
>> You should first try to use common/SurfaceIO.cpp.  The iphone one is
>> there really only there to save space (and to add additional image  
>> formats) -
>> you can actually use the common one instead.  This condition is handled
>> in the Build.xml file.
>> You will need to link again jpeg/png/z as well - there are versions on
>> these in the sdl-static project - but you might need to compile for
>> your system.
>>
>> Each target provides a "Stage", which is responsible for setting up the
>> window and OpenGL context, passing events onto the the rest of the code
>> and running the main-loop.  Audio is also done differently for each  
>> target.
>>
>> If you are using SDL, you may just be able to use the SDL stage, and
>> not have to do anything else.  SDL is doing something similar to
>> encapsulating the stage, so there is a bit of overlap there.
>> You would probably write your own "Stage" by starting with some
>> example code for your device - something that creates a window and
>> sets up opengl.  The stage code will follow this - you basically
>> construct events like "Event event(etMouseMove,x,y)" and call  
>> "ProcessEvent".
>>
>> Your "main" function should come from HX_BEGIN_MAIN in  
>> $HXCPP/include/hx/Macros.h,
>> which should be included from  the generated src/__main__.cpp.
>> If you are getting the unresolved from compiling nme, then it
>> looks like you are using the wrong link flags.
>>
>> In the nme2 Build.xml, it has the lines:
>>
>> <set name="ndll-tool" value="dll" unless="iphone"/>
>> <set name="ndll-tool" value="static" if="iphone"/>
>>
>> and then:
>>
>> <target id="NDLL" output="nme${name_extra}" tool="linker"  
>> toolid="${ndll-tool}">
>>
>> sets the "tool"="linker" and "toolid"="dll" for non-iphone builds.
>>
>> This then refers the  section in $HXCPP/build/BuildCommon.xml (eg, for  
>> linux) with the matching id:
>>
>> <linker id="dll" exe="g++" if="linux">
>>    <flag value="-shared"/>
>>    <flag value="-fpic"/>
>>    <flag value="-fPIC"/>
>>    <flag value="-m32" unless="HXCPP_M64"/>
>>    <flag value="-W,l--unresolved-symbols=report-all"/>
>>    <flag value="-debug" if="debug"/>
>>    <ext value=".dso"/>
>>    <outflag value="-o "/>
>> </linker>
>>
>> Notice the "-shared" flag - this is what makes it create a .dso instead  
>> of a .exe.
>>
>> If you paste the link lines, I will have another look.
>>
>> I am more that happy to integrate your compiler options it the hxcpp  
>> build code,
>> and into NME.
>>
>> For a new hxcpp compiler, I generally start with a "-D compiler" flag  
>> to the
>> haxe compile line.  All these automatically get passed to the build  
>> script.
>> When compiling NME, you need to add these manually (Note no space:  
>> -Dcompiler).
>> Then, in BuildTool.hx, you can follow the android pattern to set up a  
>> "BINDIR"
>> and any other defines you want to use in BuildCommon.xml.
>> Then in BuildCommon.xml, you can do
>>
>> <linker id="dll" exe="g++" if="palmos"> ...
>>
>> You may also want to add a "-DPALMOS" to you compiler flags, so you can  
>> use
>> this in the NME c++ code.
>>
>>
>> Hope this helps,
>>
>> Hugh
>>
>>>
>>> Hi again,
>>>
>>> I think I've got it. I'm compiling fine without errors. The only  
>>> problem, I think, is that the compiler must be doing both NME and my  
>>> application as an executable. I need to figure out how to compile a  
>>> shared library or dynamic shared library using GCC. Once I do that,  
>>> (with fingers crossed), I'll be ready to run applications on the phone.
>>>
>>> Fortunately hxcpp already works for so many platforms already, there's  
>>> a wealth of code available to pick and choose what to use for a new  
>>> platform. I've set it up to use SDL for graphics to start, so I can  
>>> see it working, then I can invest some time into tying up a couple  
>>> loose ends so that I can have GL for graphics instead
>>>
>>>
>>>
>>>
>>> On Sun, 11 Jul 2010 18:34:37 -0700, Joshua Granick  
>>> <[hidden email]> wrote:
>>>
>>>> Quick update:
>>>>
>>>> I just tried to use SDL for the stage and sound ... still upset about  
>>>> SurfaceIO. I created a stub .cpp file so it wouldn't complain about  
>>>> that anymore, and I get the following (and I think final) link error:
>>>>
>>>>
>>>>
>>>> c:/program files (x86)/codesourcery/sourcery g++  
>>>> lite/bin/../arm-none-linux-gnue
>>>> abi/libc/usr/lib/crt1.o: In function `_start':
>>>> init.c:(.text+0x30): undefined reference to `main'
>>>> collect2: ld returned 1 exit status
>>>> Called from <null> line 1
>>>> Called from BuildTool.hx line 883
>>>> Called from BuildTool.hx line 451
>>>> Called from BuildTool.hx line 474
>>>> Called from BuildTool.hx line 547
>>>> Called from BuildTool.hx line 628
>>>> Called from BuildTool.hx line 256
>>>> Uncaught exception - Error : 1 - build cancelled
>>>>
>>>>
>>>>
>>>> Is this normal?
>>>>
>>>>
>>>> Thanks again if anyone can help me! (Please? :)
>>>>
>>>>
>>>>
>>>> On Sun, 11 Jul 2010 18:18:58 -0700, Joshua Granick  
>>>> <[hidden email]> wrote:
>>>>
>>>>> Hi everyone,
>>>>>
>>>>> I am working on compiling NME so that I can build HXCPP projects for  
>>>>> Palm webOS.
>>>>>
>>>>> I have been able to successfully compile and execute an HXCPP-based  
>>>>> haXe project on the device, but unfortunately it failed because it  
>>>>> was missing nme.ndll. Now I have been in the process of compiling  
>>>>> NME so that my application can run. I am successfully compiling a  
>>>>> Palm webOS compatible nme.ndll file, with the exception of a couple  
>>>>> compiler/linking issues.
>>>>>
>>>>> When I include SurfaceIO.cpp, it throws some compiler errors. It  
>>>>> throws "invalid conversion" errors on lines 54-58, and throws  
>>>>> multiple "too many arguments to function" errors when referencing  
>>>>> methods defined in jpeglib.h. I am using the latest SVN revision of  
>>>>> the nekonme, hxcpp and sdl-static libraries, but this makes me  
>>>>> wonder if I need a different version of libjpeg? However, I also  
>>>>> noticed that the iPhone port uses a separate file for SurfaceIO,  
>>>>> written in Objective-C. Writing C/C++ applications for Palm is very,  
>>>>> very similar to iPhone, except, of course, that it doesn't support  
>>>>> Objective-C, so the other possibility I wonder is if the standard  
>>>>> SurfaceIO.cpp is incompatible, so would I then need a C++ version of  
>>>>> the iPhone SurfaceIO.mm file for it to work?
>>>>>
>>>>> When I leave this file out, everything compiles fine, but it throws  
>>>>> a link error because it cannot find the SurfaceIO methods. Other  
>>>>> than SurfaceIO, the other files I would need to provide a complete  
>>>>> implementation are probably the other two iPhone files, which are  
>>>>> also written in Objective-C. One is for Sound, and one is for the  
>>>>> frame. I can't use the frame from the Android port, since I am not  
>>>>> hooking the application into Java, and I can't use the frame from  
>>>>> the Windows version, since I'm using OpenGL ES. I'm guessing I  
>>>>> probably will need a frame like the iPhone one, but in C++. Lastly,  
>>>>> the references I see in the iPhone sound file look similar to what  
>>>>> I've seen for Palm, but again, in C++. Sound is not as large of an  
>>>>> issue for me right now, so the frame and SurfaceIO files seem to be  
>>>>> the only links missing in the chain for publishing for Palm.
>>>>>
>>>>> I found a small bug in one of the files, added string.h to one of  
>>>>> the other files, and updated BuildCommon.xml (for HXCPP), Build.xml  
>>>>> (for NME) and OpenGLContext.cpp in order to support the "Palm"  
>>>>> export target. I'd love to be able to share this with the project  
>>>>> when I get this all working.
>>>>>
>>>>> If it is true that I will need a couple files which aren't present  
>>>>> in the project right now, I'm willing to try and write them myself,  
>>>>> since I know the creators of the project may not be as interested or  
>>>>> motivated in a Palm port as I am. If that's the case, it would help  
>>>>> to just have a couple pointers so I understand how the stage and  
>>>>> SurfaceIO files connect to the framework, so I know what I need to  
>>>>> write.
>>>>>
>>>>> Help is appreciated! Thanks!
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
>

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

--
haXe - an open source web programming language
http://haxe.org

[Gamehaxe]

Hi,
Firstly, yes, neash is not needed for nme2.

Also, the startup code has changed - see the examples in the nme/version2.
Basically, your main should look like this:

static function main()
{
    #if flash
    new Demo ();
    #else
    nme.Lib.create(function(){new  
Demo();},320,480,60,0xccccff,nme.Lib.HARDWARE | nme.Lib.RESIZABLE);
    #end
}

 From your earlier log, I see the Loader trying to load the nme from  
various locations.
The message is coming from __loadprim in $HXCPP/src/hx/Lib.cpp.
Try putting debug on in here, or refer to your earlier logs - this will
tell you the places it is looking.
The first call it does should be to "nme.so" without a full path.
This should then look in your LD_LIBRARY_PATH and find it.

You can use the "nm" command (you may need the device/cross compiler  
version)
to see the symbols in the .so file - this should also help to see if
your .so file is compiled correctly.

Hugh

>
> Okay, so I think I'm up and running with nme2 for my project. No wonder  
> it wouldn't work! nme.so is compiled using the version2 source, but my  
> project was compiled using the original source code.
>
> I was confused before because of neash, but it looks like nme2 doesn't  
> require neash? I removed neash from the list of libraries used in my  
> project, and changed flash:neash to flash:nme, and removed the cpp  
> conditional flags in the document class for the project.
>
> Here are the .hx files (very simple) I am using in my project now
>
> http://pastie.org/1041594
> http://pastie.org/1041595
>
>
> I can compile it without errors now, but when I run it, it throws a new  
> error. Now it says it cannot load nme@nme_create_display_object. This  
> makes a lot of sense, since DisplayObject is the base class for Sprite,  
> and the first module that your DisplayObject class attempts to load  
> appears to be nme_create_display_object
>
> http://code.google.com/p/nekonme/source/browse/trunk/version2/nme/display/DisplayObject.hx?spec=svn446&r=446
>
>
> I'm guessing this means that I'm all up and running on nme2, but it  
> still isn't completely synced with the nme.so file I compiled, somehow?  
> If I changed its extension to nme.dso would it make any difference?
>
>
>
>
>
> On Mon, 12 Jul 2010 13:44:45 -0700, Joshua Granick  
> <[hidden email]> wrote:
>
>> Hi,
>>
>> As you suggested, I am using a modified version of BuildCommon.xml to  
>> configure compiling and linking.
>>
>> http://pastie.org/1041447
>>
>>
>> As for Build.xml, I am testing it now under SDL instead of GL, since  
>> SDL already has the stage and sound. I figure that I can look at  
>> writing a simple GL stage once I can at least get a "Hello World"  
>> application running under SDL. I'm using a duplicate of the  
>> AndroidFont.cpp file, with Android log messages removed, and I am using  
>> a simple stub version of SurfaceIO which does nothing, but does provide  
>> completion so the library will compile.
>>
>> http://pastie.org/1041462
>>
>>
>> Under these settings, it does compile without errors. There also are a  
>> couple places where I added #include <string.h> to fix errors, one  
>> place where I had to replace #if NEKO_LINUX with #ifndef NEKO_LINUX,  
>> and a few places (such as OpenGLContext.cpp and Lib.cpp) where I used  
>> the PALM directive to specify the correct extension and options.
>>
>> http://pastie.org/1041472
>>
>>
>> Under the BuildCommon.xml settings, my simple project (which runs in  
>> Flash and in Windows C++) compiles fine as well. There are no errors,  
>> but there are a few library warnings, which I'm told are to be  
>> expected. It just warns about system libraries which are present on the  
>> phone.
>>
>> http://pastie.org/1041482
>>
>>
>> I then copied my executable and library onto the phone, and set  
>> LD_LIBRARY_PATH to the same directory, so it could find the library ...  
>> and it does. When I run strace Main-debug, I can see that it finds the  
>> file. If I compile NME without -nostdlibs, it will provide an error  
>> saying that it could not load module std@get_env__1. If I do not  
>> include the flag, it says that it cannot load module  
>> nme@filter_image__2.
>>
>> http://pastie.org/1041490
>>
>>
>>
>> I'm not sure if there are other things I can do to debug how this is  
>> all fitting together? This is all a learning experience for me, so  
>> please feel free to let me know if there are other things I can do to  
>> help provide useful debugging information.
>>
>>
>> By the way, I believe that this is the file which was having an error.  
>> In other cases I needed to add a header include, or occasionally needed  
>> a "me too!" type of compiler directive, where it applied separate code  
>> for IPHONE and ANDROID, and so I needed to add PALM in there too.  
>> However, this one said it had no argument after #if. When I try and  
>> compile it as #ifdef, it says that _dyld_image_count and  
>> _dyld_get_image_name are not defined. As it seemed like the closest  
>> neighbor in this case was ANDROID, which did not reference #include  
>> <mach-o/dyld.h>, I figured that #ifndef was the right choice (which  
>> compiles). Here's a paste of what that file looks like
>>
>> http://pastie.org/1041509
>>
>>
>>
>> Thank you!
>>
>>
>>
>> Joshua
>>
>>
>>
>>
>> On Mon, 12 Jul 2010 09:50:51 -0700, Hugh Sanderson  
>> <[hidden email]> wrote:
>>
>>> Hi,
>>> It sounds like you are on the right track.
>>>
>>> You should first try to use common/SurfaceIO.cpp.  The iphone one is
>>> there really only there to save space (and to add additional image  
>>> formats) -
>>> you can actually use the common one instead.  This condition is handled
>>> in the Build.xml file.
>>> You will need to link again jpeg/png/z as well - there are versions on
>>> these in the sdl-static project - but you might need to compile for
>>> your system.
>>>
>>> Each target provides a "Stage", which is responsible for setting up the
>>> window and OpenGL context, passing events onto the the rest of the code
>>> and running the main-loop.  Audio is also done differently for each  
>>> target.
>>>
>>> If you are using SDL, you may just be able to use the SDL stage, and
>>> not have to do anything else.  SDL is doing something similar to
>>> encapsulating the stage, so there is a bit of overlap there.
>>> You would probably write your own "Stage" by starting with some
>>> example code for your device - something that creates a window and
>>> sets up opengl.  The stage code will follow this - you basically
>>> construct events like "Event event(etMouseMove,x,y)" and call  
>>> "ProcessEvent".
>>>
>>> Your "main" function should come from HX_BEGIN_MAIN in  
>>> $HXCPP/include/hx/Macros.h,
>>> which should be included from  the generated src/__main__.cpp.
>>> If you are getting the unresolved from compiling nme, then it
>>> looks like you are using the wrong link flags.
>>>
>>> In the nme2 Build.xml, it has the lines:
>>>
>>> <set name="ndll-tool" value="dll" unless="iphone"/>
>>> <set name="ndll-tool" value="static" if="iphone"/>
>>>
>>> and then:
>>>
>>> <target id="NDLL" output="nme${name_extra}" tool="linker"  
>>> toolid="${ndll-tool}">
>>>
>>> sets the "tool"="linker" and "toolid"="dll" for non-iphone builds.
>>>
>>> This then refers the  section in $HXCPP/build/BuildCommon.xml (eg, for  
>>> linux) with the matching id:
>>>
>>> <linker id="dll" exe="g++" if="linux">
>>>    <flag value="-shared"/>
>>>    <flag value="-fpic"/>
>>>    <flag value="-fPIC"/>
>>>    <flag value="-m32" unless="HXCPP_M64"/>
>>>    <flag value="-W,l--unresolved-symbols=report-all"/>
>>>    <flag value="-debug" if="debug"/>
>>>    <ext value=".dso"/>
>>>    <outflag value="-o "/>
>>> </linker>
>>>
>>> Notice the "-shared" flag - this is what makes it create a .dso  
>>> instead of a .exe.
>>>
>>> If you paste the link lines, I will have another look.
>>>
>>> I am more that happy to integrate your compiler options it the hxcpp  
>>> build code,
>>> and into NME.
>>>
>>> For a new hxcpp compiler, I generally start with a "-D compiler" flag  
>>> to the
>>> haxe compile line.  All these automatically get passed to the build  
>>> script.
>>> When compiling NME, you need to add these manually (Note no space:  
>>> -Dcompiler).
>>> Then, in BuildTool.hx, you can follow the android pattern to set up a  
>>> "BINDIR"
>>> and any other defines you want to use in BuildCommon.xml.
>>> Then in BuildCommon.xml, you can do
>>>
>>> <linker id="dll" exe="g++" if="palmos"> ...
>>>
>>> You may also want to add a "-DPALMOS" to you compiler flags, so you  
>>> can use
>>> this in the NME c++ code.
>>>
>>>
>>> Hope this helps,
>>>
>>> Hugh
>>>
>>>>
>>>> Hi again,
>>>>
>>>> I think I've got it. I'm compiling fine without errors. The only  
>>>> problem, I think, is that the compiler must be doing both NME and my  
>>>> application as an executable. I need to figure out how to compile a  
>>>> shared library or dynamic shared library using GCC. Once I do that,  
>>>> (with fingers crossed), I'll be ready to run applications on the  
>>>> phone.
>>>>
>>>> Fortunately hxcpp already works for so many platforms already,  
>>>> there's a wealth of code available to pick and choose what to use for  
>>>> a new platform. I've set it up to use SDL for graphics to start, so I  
>>>> can see it working, then I can invest some time into tying up a  
>>>> couple loose ends so that I can have GL for graphics instead
>>>>
>>>>
>>>>
>>>>
>>>> On Sun, 11 Jul 2010 18:34:37 -0700, Joshua Granick  
>>>> <[hidden email]> wrote:
>>>>
>>>>> Quick update:
>>>>>
>>>>> I just tried to use SDL for the stage and sound ... still upset  
>>>>> about SurfaceIO. I created a stub .cpp file so it wouldn't complain  
>>>>> about that anymore, and I get the following (and I think final) link  
>>>>> error:
>>>>>
>>>>>
>>>>>
>>>>> c:/program files (x86)/codesourcery/sourcery g++  
>>>>> lite/bin/../arm-none-linux-gnue
>>>>> abi/libc/usr/lib/crt1.o: In function `_start':
>>>>> init.c:(.text+0x30): undefined reference to `main'
>>>>> collect2: ld returned 1 exit status
>>>>> Called from <null> line 1
>>>>> Called from BuildTool.hx line 883
>>>>> Called from BuildTool.hx line 451
>>>>> Called from BuildTool.hx line 474
>>>>> Called from BuildTool.hx line 547
>>>>> Called from BuildTool.hx line 628
>>>>> Called from BuildTool.hx line 256
>>>>> Uncaught exception - Error : 1 - build cancelled
>>>>>
>>>>>
>>>>>
>>>>> Is this normal?
>>>>>
>>>>>
>>>>> Thanks again if anyone can help me! (Please? :)
>>>>>
>>>>>
>>>>>
>>>>> On Sun, 11 Jul 2010 18:18:58 -0700, Joshua Granick  
>>>>> <[hidden email]> wrote:
>>>>>
>>>>>> Hi everyone,
>>>>>>
>>>>>> I am working on compiling NME so that I can build HXCPP projects  
>>>>>> for Palm webOS.
>>>>>>
>>>>>> I have been able to successfully compile and execute an HXCPP-based  
>>>>>> haXe project on the device, but unfortunately it failed because it  
>>>>>> was missing nme.ndll. Now I have been in the process of compiling  
>>>>>> NME so that my application can run. I am successfully compiling a  
>>>>>> Palm webOS compatible nme.ndll file, with the exception of a couple  
>>>>>> compiler/linking issues.
>>>>>>
>>>>>> When I include SurfaceIO.cpp, it throws some compiler errors. It  
>>>>>> throws "invalid conversion" errors on lines 54-58, and throws  
>>>>>> multiple "too many arguments to function" errors when referencing  
>>>>>> methods defined in jpeglib.h. I am using the latest SVN revision of  
>>>>>> the nekonme, hxcpp and sdl-static libraries, but this makes me  
>>>>>> wonder if I need a different version of libjpeg? However, I also  
>>>>>> noticed that the iPhone port uses a separate file for SurfaceIO,  
>>>>>> written in Objective-C. Writing C/C++ applications for Palm is  
>>>>>> very, very similar to iPhone, except, of course, that it doesn't  
>>>>>> support Objective-C, so the other possibility I wonder is if the  
>>>>>> standard SurfaceIO.cpp is incompatible, so would I then need a C++  
>>>>>> version of the iPhone SurfaceIO.mm file for it to work?
>>>>>>
>>>>>> When I leave this file out, everything compiles fine, but it throws  
>>>>>> a link error because it cannot find the SurfaceIO methods. Other  
>>>>>> than SurfaceIO, the other files I would need to provide a complete  
>>>>>> implementation are probably the other two iPhone files, which are  
>>>>>> also written in Objective-C. One is for Sound, and one is for the  
>>>>>> frame. I can't use the frame from the Android port, since I am not  
>>>>>> hooking the application into Java, and I can't use the frame from  
>>>>>> the Windows version, since I'm using OpenGL ES. I'm guessing I  
>>>>>> probably will need a frame like the iPhone one, but in C++. Lastly,  
>>>>>> the references I see in the iPhone sound file look similar to what  
>>>>>> I've seen for Palm, but again, in C++. Sound is not as large of an  
>>>>>> issue for me right now, so the frame and SurfaceIO files seem to be  
>>>>>> the only links missing in the chain for publishing for Palm.
>>>>>>
>>>>>> I found a small bug in one of the files, added string.h to one of  
>>>>>> the other files, and updated BuildCommon.xml (for HXCPP), Build.xml  
>>>>>> (for NME) and OpenGLContext.cpp in order to support the "Palm"  
>>>>>> export target. I'd love to be able to share this with the project  
>>>>>> when I get this all working.
>>>>>>
>>>>>> If it is true that I will need a couple files which aren't present  
>>>>>> in the project right now, I'm willing to try and write them myself,  
>>>>>> since I know the creators of the project may not be as interested  
>>>>>> or motivated in a Palm port as I am. If that's the case, it would  
>>>>>> help to just have a couple pointers so I understand how the stage  
>>>>>> and SurfaceIO files connect to the framework, so I know what I need  
>>>>>> to write.
>>>>>>
>>>>>> Help is appreciated! Thanks!
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>

--
haXe - an open source web programming language
http://haxe.org

[singmajesty]

Hey Hugh,

Thanks!

Yes, I'm using that code in main() now, and I'm successfully compiling  
using nme2.


1.) First pass

I had recently changed the library to use a -soname, then added a -lnme  
flag for the application. This correctly caused the system to require  
libnme.so in order to run. I updated the code in Lib.cpp for it to look  
for "libnme.so" instead of "nme.so", but it threw a segmentation fault,  
after hanging for a while.


2.) Second pass

I removed the -soname and -lnme flags, and renamed the library to nme.so.  
Here's the log messages I received:


root@palm-webos-device:/media/internal# Main-debug
Searching for nme...
  try nme-debug.so...
  try nme-debug.ndll...
  try nme.so...
Searching for std...
  try std-debug.so...
  try std-debug.ndll...
  try std.so...
  try std.ndll...
Error : Could not load module std@float_of_bytes__2


3.) Third pass

I put -nostdlib into the flags for the library, and compiled everything  
again. Here's what it printed out:


root@palm-webos-device:/media/internal# Main-debug
Searching for nme...
  try nme-debug.so...
  try nme-debug.ndll...
  try nme.so...
  try nme.ndll...
Error : Could not load module nme@nme_create_display_object__0


I tried putting in a few more trace messages, and it looks like dlopen is  
returning false. Strangely, it returns true (I am guessing) if I don't use  
the -nostdlib flag. Maybe it would still fail even if I had std.so? Is  
this a basic file I/O type operation, or is it more advanced than that?


Thank you!


On Tue, 13 Jul 2010 07:39:07 -0700, Hugh Sanderson <[hidden email]>  
wrote:

> Hi,
> Firstly, yes, neash is not needed for nme2.
>
> Also, the startup code has changed - see the examples in the  
> nme/version2.
> Basically, your main should look like this:
>
> static function main()
> {
>     #if flash
>     new Demo ();
>     #else
>     nme.Lib.create(function(){new  
> Demo();},320,480,60,0xccccff,nme.Lib.HARDWARE | nme.Lib.RESIZABLE);
>     #end
> }
>
>  From your earlier log, I see the Loader trying to load the nme from  
> various locations.
> The message is coming from __loadprim in $HXCPP/src/hx/Lib.cpp.
> Try putting debug on in here, or refer to your earlier logs - this will
> tell you the places it is looking.
> The first call it does should be to "nme.so" without a full path.
> This should then look in your LD_LIBRARY_PATH and find it.
>
> You can use the "nm" command (you may need the device/cross compiler  
> version)
> to see the symbols in the .so file - this should also help to see if
> your .so file is compiled correctly.
>
> Hugh
>
>
>
>>
>> Okay, so I think I'm up and running with nme2 for my project. No wonder  
>> it wouldn't work! nme.so is compiled using the version2 source, but my  
>> project was compiled using the original source code.
>>
>> I was confused before because of neash, but it looks like nme2 doesn't  
>> require neash? I removed neash from the list of libraries used in my  
>> project, and changed flash:neash to flash:nme, and removed the cpp  
>> conditional flags in the document class for the project.
>>
>> Here are the .hx files (very simple) I am using in my project now
>>
>> http://pastie.org/1041594
>> http://pastie.org/1041595
>>
>>
>> I can compile it without errors now, but when I run it, it throws a new  
>> error. Now it says it cannot load nme@nme_create_display_object. This  
>> makes a lot of sense, since DisplayObject is the base class for Sprite,  
>> and the first module that your DisplayObject class attempts to load  
>> appears to be nme_create_display_object
>>
>> http://code.google.com/p/nekonme/source/browse/trunk/version2/nme/display/DisplayObject.hx?spec=svn446&r=446
>>
>>
>> I'm guessing this means that I'm all up and running on nme2, but it  
>> still isn't completely synced with the nme.so file I compiled, somehow?  
>> If I changed its extension to nme.dso would it make any difference?
>>
>>
>>
>>
>>
>> On Mon, 12 Jul 2010 13:44:45 -0700, Joshua Granick  
>> <[hidden email]> wrote:
>>
>>> Hi,
>>>
>>> As you suggested, I am using a modified version of BuildCommon.xml to  
>>> configure compiling and linking.
>>>
>>> http://pastie.org/1041447
>>>
>>>
>>> As for Build.xml, I am testing it now under SDL instead of GL, since  
>>> SDL already has the stage and sound. I figure that I can look at  
>>> writing a simple GL stage once I can at least get a "Hello World"  
>>> application running under SDL. I'm using a duplicate of the  
>>> AndroidFont.cpp file, with Android log messages removed, and I am  
>>> using a simple stub version of SurfaceIO which does nothing, but does  
>>> provide completion so the library will compile.
>>>
>>> http://pastie.org/1041462
>>>
>>>
>>> Under these settings, it does compile without errors. There also are a  
>>> couple places where I added #include <string.h> to fix errors, one  
>>> place where I had to replace #if NEKO_LINUX with #ifndef NEKO_LINUX,  
>>> and a few places (such as OpenGLContext.cpp and Lib.cpp) where I used  
>>> the PALM directive to specify the correct extension and options.
>>>
>>> http://pastie.org/1041472
>>>
>>>
>>> Under the BuildCommon.xml settings, my simple project (which runs in  
>>> Flash and in Windows C++) compiles fine as well. There are no errors,  
>>> but there are a few library warnings, which I'm told are to be  
>>> expected. It just warns about system libraries which are present on  
>>> the phone.
>>>
>>> http://pastie.org/1041482
>>>
>>>
>>> I then copied my executable and library onto the phone, and set  
>>> LD_LIBRARY_PATH to the same directory, so it could find the library  
>>> ... and it does. When I run strace Main-debug, I can see that it finds  
>>> the file. If I compile NME without -nostdlibs, it will provide an  
>>> error saying that it could not load module std@get_env__1. If I do not  
>>> include the flag, it says that it cannot load module  
>>> nme@filter_image__2.
>>>
>>> http://pastie.org/1041490
>>>
>>>
>>>
>>> I'm not sure if there are other things I can do to debug how this is  
>>> all fitting together? This is all a learning experience for me, so  
>>> please feel free to let me know if there are other things I can do to  
>>> help provide useful debugging information.
>>>
>>>
>>> By the way, I believe that this is the file which was having an error.  
>>> In other cases I needed to add a header include, or occasionally  
>>> needed a "me too!" type of compiler directive, where it applied  
>>> separate code for IPHONE and ANDROID, and so I needed to add PALM in  
>>> there too. However, this one said it had no argument after #if. When I  
>>> try and compile it as #ifdef, it says that _dyld_image_count and  
>>> _dyld_get_image_name are not defined. As it seemed like the closest  
>>> neighbor in this case was ANDROID, which did not reference #include  
>>> <mach-o/dyld.h>, I figured that #ifndef was the right choice (which  
>>> compiles). Here's a paste of what that file looks like
>>>
>>> http://pastie.org/1041509
>>>
>>>
>>>
>>> Thank you!
>>>
>>>
>>>
>>> Joshua
>>>
>>>
>>>
>>>
>>> On Mon, 12 Jul 2010 09:50:51 -0700, Hugh Sanderson  
>>> <[hidden email]> wrote:
>>>
>>>> Hi,
>>>> It sounds like you are on the right track.
>>>>
>>>> You should first try to use common/SurfaceIO.cpp.  The iphone one is
>>>> there really only there to save space (and to add additional image  
>>>> formats) -
>>>> you can actually use the common one instead.  This condition is  
>>>> handled
>>>> in the Build.xml file.
>>>> You will need to link again jpeg/png/z as well - there are versions on
>>>> these in the sdl-static project - but you might need to compile for
>>>> your system.
>>>>
>>>> Each target provides a "Stage", which is responsible for setting up  
>>>> the
>>>> window and OpenGL context, passing events onto the the rest of the  
>>>> code
>>>> and running the main-loop.  Audio is also done differently for each  
>>>> target.
>>>>
>>>> If you are using SDL, you may just be able to use the SDL stage, and
>>>> not have to do anything else.  SDL is doing something similar to
>>>> encapsulating the stage, so there is a bit of overlap there.
>>>> You would probably write your own "Stage" by starting with some
>>>> example code for your device - something that creates a window and
>>>> sets up opengl.  The stage code will follow this - you basically
>>>> construct events like "Event event(etMouseMove,x,y)" and call  
>>>> "ProcessEvent".
>>>>
>>>> Your "main" function should come from HX_BEGIN_MAIN in  
>>>> $HXCPP/include/hx/Macros.h,
>>>> which should be included from  the generated src/__main__.cpp.
>>>> If you are getting the unresolved from compiling nme, then it
>>>> looks like you are using the wrong link flags.
>>>>
>>>> In the nme2 Build.xml, it has the lines:
>>>>
>>>> <set name="ndll-tool" value="dll" unless="iphone"/>
>>>> <set name="ndll-tool" value="static" if="iphone"/>
>>>>
>>>> and then:
>>>>
>>>> <target id="NDLL" output="nme${name_extra}" tool="linker"  
>>>> toolid="${ndll-tool}">
>>>>
>>>> sets the "tool"="linker" and "toolid"="dll" for non-iphone builds.
>>>>
>>>> This then refers the  section in $HXCPP/build/BuildCommon.xml (eg,  
>>>> for linux) with the matching id:
>>>>
>>>> <linker id="dll" exe="g++" if="linux">
>>>>    <flag value="-shared"/>
>>>>    <flag value="-fpic"/>
>>>>    <flag value="-fPIC"/>
>>>>    <flag value="-m32" unless="HXCPP_M64"/>
>>>>    <flag value="-W,l--unresolved-symbols=report-all"/>
>>>>    <flag value="-debug" if="debug"/>
>>>>    <ext value=".dso"/>
>>>>    <outflag value="-o "/>
>>>> </linker>
>>>>
>>>> Notice the "-shared" flag - this is what makes it create a .dso  
>>>> instead of a .exe.
>>>>
>>>> If you paste the link lines, I will have another look.
>>>>
>>>> I am more that happy to integrate your compiler options it the hxcpp  
>>>> build code,
>>>> and into NME.
>>>>
>>>> For a new hxcpp compiler, I generally start with a "-D compiler" flag  
>>>> to the
>>>> haxe compile line.  All these automatically get passed to the build  
>>>> script.
>>>> When compiling NME, you need to add these manually (Note no space:  
>>>> -Dcompiler).
>>>> Then, in BuildTool.hx, you can follow the android pattern to set up a  
>>>> "BINDIR"
>>>> and any other defines you want to use in BuildCommon.xml.
>>>> Then in BuildCommon.xml, you can do
>>>>
>>>> <linker id="dll" exe="g++" if="palmos"> ...
>>>>
>>>> You may also want to add a "-DPALMOS" to you compiler flags, so you  
>>>> can use
>>>> this in the NME c++ code.
>>>>
>>>>
>>>> Hope this helps,
>>>>
>>>> Hugh
>>>>
>>>>>
>>>>> Hi again,
>>>>>
>>>>> I think I've got it. I'm compiling fine without errors. The only  
>>>>> problem, I think, is that the compiler must be doing both NME and my  
>>>>> application as an executable. I need to figure out how to compile a  
>>>>> shared library or dynamic shared library using GCC. Once I do that,  
>>>>> (with fingers crossed), I'll be ready to run applications on the  
>>>>> phone.
>>>>>
>>>>> Fortunately hxcpp already works for so many platforms already,  
>>>>> there's a wealth of code available to pick and choose what to use  
>>>>> for a new platform. I've set it up to use SDL for graphics to start,  
>>>>> so I can see it working, then I can invest some time into tying up a  
>>>>> couple loose ends so that I can have GL for graphics instead
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Sun, 11 Jul 2010 18:34:37 -0700, Joshua Granick  
>>>>> <[hidden email]> wrote:
>>>>>
>>>>>> Quick update:
>>>>>>
>>>>>> I just tried to use SDL for the stage and sound ... still upset  
>>>>>> about SurfaceIO. I created a stub .cpp file so it wouldn't complain  
>>>>>> about that anymore, and I get the following (and I think final)  
>>>>>> link error:
>>>>>>
>>>>>>
>>>>>>
>>>>>> c:/program files (x86)/codesourcery/sourcery g++  
>>>>>> lite/bin/../arm-none-linux-gnue
>>>>>> abi/libc/usr/lib/crt1.o: In function `_start':
>>>>>> init.c:(.text+0x30): undefined reference to `main'
>>>>>> collect2: ld returned 1 exit status
>>>>>> Called from <null> line 1
>>>>>> Called from BuildTool.hx line 883
>>>>>> Called from BuildTool.hx line 451
>>>>>> Called from BuildTool.hx line 474
>>>>>> Called from BuildTool.hx line 547
>>>>>> Called from BuildTool.hx line 628
>>>>>> Called from BuildTool.hx line 256
>>>>>> Uncaught exception - Error : 1 - build cancelled
>>>>>>
>>>>>>
>>>>>>
>>>>>> Is this normal?
>>>>>>
>>>>>>
>>>>>> Thanks again if anyone can help me! (Please? :)
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sun, 11 Jul 2010 18:18:58 -0700, Joshua Granick  
>>>>>> <[hidden email]> wrote:
>>>>>>
>>>>>>> Hi everyone,
>>>>>>>
>>>>>>> I am working on compiling NME so that I can build HXCPP projects  
>>>>>>> for Palm webOS.
>>>>>>>
>>>>>>> I have been able to successfully compile and execute an  
>>>>>>> HXCPP-based haXe project on the device, but unfortunately it  
>>>>>>> failed because it was missing nme.ndll. Now I have been in the  
>>>>>>> process of compiling NME so that my application can run. I am  
>>>>>>> successfully compiling a Palm webOS compatible nme.ndll file, with  
>>>>>>> the exception of a couple compiler/linking issues.
>>>>>>>
>>>>>>> When I include SurfaceIO.cpp, it throws some compiler errors. It  
>>>>>>> throws "invalid conversion" errors on lines 54-58, and throws  
>>>>>>> multiple "too many arguments to function" errors when referencing  
>>>>>>> methods defined in jpeglib.h. I am using the latest SVN revision  
>>>>>>> of the nekonme, hxcpp and sdl-static libraries, but this makes me  
>>>>>>> wonder if I need a different version of libjpeg? However, I also  
>>>>>>> noticed that the iPhone port uses a separate file for SurfaceIO,  
>>>>>>> written in Objective-C. Writing C/C++ applications for Palm is  
>>>>>>> very, very similar to iPhone, except, of course, that it doesn't  
>>>>>>> support Objective-C, so the other possibility I wonder is if the  
>>>>>>> standard SurfaceIO.cpp is incompatible, so would I then need a C++  
>>>>>>> version of the iPhone SurfaceIO.mm file for it to work?
>>>>>>>
>>>>>>> When I leave this file out, everything compiles fine, but it  
>>>>>>> throws a link error because it cannot find the SurfaceIO methods.  
>>>>>>> Other than SurfaceIO, the other files I would need to provide a  
>>>>>>> complete implementation are probably the other two iPhone files,  
>>>>>>> which are also written in Objective-C. One is for Sound, and one  
>>>>>>> is for the frame. I can't use the frame from the Android port,  
>>>>>>> since I am not hooking the application into Java, and I can't use  
>>>>>>> the frame from the Windows version, since I'm using OpenGL ES. I'm  
>>>>>>> guessing I probably will need a frame like the iPhone one, but in  
>>>>>>> C++. Lastly, the references I see in the iPhone sound file look  
>>>>>>> similar to what I've seen for Palm, but again, in C++. Sound is  
>>>>>>> not as large of an issue for me right now, so the frame and  
>>>>>>> SurfaceIO files seem to be the only links missing in the chain for  
>>>>>>> publishing for Palm.
>>>>>>>
>>>>>>> I found a small bug in one of the files, added string.h to one of  
>>>>>>> the other files, and updated BuildCommon.xml (for HXCPP),  
>>>>>>> Build.xml (for NME) and OpenGLContext.cpp in order to support the  
>>>>>>> "Palm" export target. I'd love to be able to share this with the  
>>>>>>> project when I get this all working.
>>>>>>>
>>>>>>> If it is true that I will need a couple files which aren't present  
>>>>>>> in the project right now, I'm willing to try and write them  
>>>>>>> myself, since I know the creators of the project may not be as  
>>>>>>> interested or motivated in a Palm port as I am. If that's the  
>>>>>>> case, it would help to just have a couple pointers so I understand  
>>>>>>> how the stage and SurfaceIO files connect to the framework, so I  
>>>>>>> know what I need to write.
>>>>>>>
>>>>>>> Help is appreciated! Thanks!
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

--
haXe - an open source web programming language
http://haxe.org

[m5no1]

Can you speak in detail a little? I want know how you build HXCPP projects for Palm ?
I want port it to symbian.  

[singmajesty]

Does Symbian support C++ applications with SDL 1.2, OpenGL ES 1.1 and  
dynamic shared libraries? iPhone, Android and Palm are all different in  
terms of suiting the code for the target, so it sort of depends on what  
type of environment Symbian offers




On Fri, 23 Jul 2010 03:55:48 -0700, m5no1 <[hidden email]> wrote:

>
> Can you speak in detail a little? I want know how you build HXCPP  
> projects
> for Palm ?
> I want port it to symbian.

--
haXe - an open source web programming language
http://haxe.org

[m5no1]

Symbian support C++ applications with SDL  and dynamic shared libraries.and gcc has a version for arm symbian .so i think it's enough.  i'm new to the  HAXE.i really want know how to use BuildTool.hx to build dll for symbian,so i want know how to build HXCPP projects as a dynamic shared libraries for palm,it may help me do same things on symbian

thanks!

[singmajesty]

You can take a look at the project's repository, here:

http://code.google.com/p/hxcpp-webos/

Much of the leg-work has already been done to support Palm devices. If  
Symbian is very similar, then you might even be able to use this project  
without changing a thing. The compiler for Palm is a G++ compiler for ARM  
GNU/Linux devices. The specific toolchain I'm using is the Sourcery G++  
Lite ARM GNU/Linux toolchain. You might start there, compiling with the  
-webos directive.

If you make any head way and have any improvements for the the framework,  
I'd be welcome to see your changes. I intend to maintain this  
"alternative" repository until builds are stable, at which point we may  
try to merge relevant changes with the official nekonme, sdl-static and  
hxcpp projects.




On Fri, 23 Jul 2010 09:26:05 -0700, m5no1 <[hidden email]> wrote:

>
> Symbian support C++ applications with SDL  and dynamic shared  
> libraries.and
> gcc has a version for arm symbian .so i think it's enough.  i'm new to  
> the
> HAXE.i really want know how to use BuildTool.hx to build dll for  
> symbian,so
> i want know how to build HXCPP projects as a dynamic shared libraries for
> palm,it may help me do same things on symbian
>
> thanks!

--
haXe - an open source web programming language
http://haxe.org

[Gamehaxe]

Hi,
The first thing to go is get an example opengl/sdl program compiling
for your system using the standard dev kit/tools you get with the system.

Then is is a matter of "copying" the gcc and link flags used into their
own section in the BuildCommon.xml file.

Flags get passed from haxe to hxcpp, so pick a define (say "symbian") and
then when you do:
haxe ...... -D symbian .....
ultimately the build tool will get called with:
haxelib run hxcpp ...... -Dsymbian .....

You can then use this to set the "os" in BuildTool.hx, and then refer to  
this
in BuildCommon.xml.

You will need to create a "compiler" for your system and a "linker".
The linker may need to be "dll" if symbian accepts .so files, or "exe"
if you generate exes.

The best way to do this is to copy one of the existing sections.
If your tools are gcc based, there is probably not much to do.

I generally prefer to have 1 environment variable pointing to
the root of the dev kit, and base compiler paths relative to this.
This makes it easy to switch between compilers without having to
put any special one of them first in the exe path. eg: SYMBIAN_SDK
You may need to add include & library paths relative to this
variable too.

There is not much doco here, but if you can make a start and come back
with some specific error dumps, then I should be able to help.

Hugh

>
> Symbian support C++ applications with SDL  and dynamic shared  
> libraries.and
> gcc has a version for arm symbian .so i think it's enough.  i'm new to  
> the
> HAXE.i really want know how to use BuildTool.hx to build dll for  
> symbian,so
> i want know how to build HXCPP projects as a dynamic shared libraries for
> palm,it may help me do same things on symbian
>
> thanks!

--
haXe - an open source web programming language
http://haxe.org

[m5no1]

hi~

thanks for your reply

I have add symbian section to buildcommon.xml
http://pastie.org/1063885

and it got error...

C:\Documents and Settings\m5\My Documents\haxe\cppstest\cpp2\src>haxe c.hxml -D
symbian
haxelib run hxcpp Build.xml haxe -Dcpp -Dhaxe_205 -Dnme -Dsymbian -Dtrue
arm-none-symbianelf-g++ -c -O2 -DSYMBIAN -fvisibility=hidden -IC:/S60/devices/S6
0_5th_Edition_SDK_v1.0/epoc32/include/gcce/ -IC:/S60/devices/S60_5th_Edition_SDK
_v1.0/epoc32/include/libc -IC:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/inclu
de -IC:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/variant -IC:/S60/dev
ices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport -IC:\Program Files\
Motion-Twin\haxe\lib\hxcpp\2,05,1/include -march=armv5t -mthumb -mapcs -nostdinc
 -D__MARM__ -D__MARM_ARMV5__ -D__MARM_THUMB__ -D__MARM_INTERWORK__ -D__EABI__ -D
__EXE__ -D_DEBUG -D_UNICODE -D__SUPPORT_CPP_EXCEPTIONS__ -D__GCCE__ -D__SYMBIAN3
2__ -D__EPOC32__ -D__S60_50__ -D__S60_3X__ -D__SERIES60_3X__ -D__PRODUCT_INCLUDE
__=\'C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/variant/symbian_os.h
rh\' -Iinclude -frtti ./src/nme/display/JointStyle.cpp -oobj/symbian//src/nme/di
splay/JointStyle.o
<command-line>:0: warning: missing terminating ' character
In file included from C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/lib
c/string.h:25,
                 from C:\Program Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include
/hxcpp.h:6,
                 from ./src/nme/display/JointStyle.cpp:1:
C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/libc/stddef.h:20: error:
redeclaration of C++ built-in type 'wchar_t'
In file included from C:\Program Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include
/hxcpp.h:103,
                 from ./src/nme/display/JointStyle.cpp:1:
C:\Program Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include/hx/Object.h: In const
ructor 'hx::ObjectPtr<O>::ObjectPtr(const hx::ObjectPtr<SOURCE_>&)':
C:\Program Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include/hx/Object.h:149: erro
r: must #include <typeinfo> before using typeid
C:\Program Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include/hx/Object.h: In const
ructor 'hx::ObjectPtr<O>::ObjectPtr(const SOURCE_*)':
C:\Program Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include/hx/Object.h:163: erro
r: must #include <typeinfo> before using typeid
In file included from C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/std
apis/stlport/stl/_construct.h:42,
                 from C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/std
apis/stlport/stl/_pair.h:34,
                 from C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/std
apis/stlport/stl/_algobase.h:51,
                 from C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/std
apis/stlport/stl/_algo.h:34,
                 from C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/std
apis/stlport/algorithm:44,
                 from C:\Program Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include
/Array.h:181,
                 from C:\Program Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include
/hxcpp.h:112,
                 from ./src/nme/display/JointStyle.cpp:1:
C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_new.
h: At global scope:
C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_new.
h:150: error: expected unqualified-id before '&' token
C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_new.
h:150: error: expected ')' before '&' token
C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_new.
h:150: error: expected initializer before '&' token
C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_new.
h:152: error: expected unqualified-id before '&' token
C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_new.
h:152: error: expected ')' before '&' token
C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_new.
h:152: error: expected initializer before '&' token
C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_new.
h:154: error: expected unqualified-id before '&' token
C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_new.
h:154: error: expected ')' before '&' token
C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_new.
h:154: error: expected initializer before '&' token
C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_new.
h:156: error: expected unqualified-id before '&' token
C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_new.
h:156: error: expected ')' before '&' token
C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_new.
h:156: error: expected initializer before '&' token
In file included from C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/std
apis/stlport/stl/_algo.h:38,
                 from C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/std
apis/stlport/algorithm:44,
                 from C:\Program Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include
/Array.h:181,
                 from C:\Program Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include
/hxcpp.h:112,
                 from ./src/nme/display/JointStyle.cpp:1:
C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_temp
buf.h: In function 'void std::return_temporary_buffer(_Tp*)':
C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_temp
buf.h:73: error: there are no arguments to 'free' that depend on a template para
meter, so a declaration of 'free' must be available
C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_temp
buf.h:73: note: (if you use '-fpermissive', G++ will accept your code, but allow
ing the use of an undeclared name is deprecated)
C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_temp
buf.h: In member function 'void std::_Temporary_buffer<_ForwardIterator, _Tp>::_
M_allocate_buffer()':
C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_temp
buf.h:87: error: 'INT_MAX' was not declared in this scope
C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_temp
buf.h:91: error: there are no arguments to 'malloc' that depend on a template pa
rameter, so a declaration of 'malloc' must be available
In file included from C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/std
apis/stlport/stl/_tempbuf.h:158,
                 from C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/std
apis/stlport/stl/_algo.h:38,
                 from C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/std
apis/stlport/algorithm:44,
                 from C:\Program Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include
/Array.h:181,
                 from C:\Program Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include
/hxcpp.h:112,
                 from ./src/nme/display/JointStyle.cpp:1:
C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_temp
buf.c: In function 'std::pair<_Tp*, long int> std::__get_temporary_buffer(ptrdif
f_t, _Tp*)':
C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_temp
buf.c:39: error: 'INT_MAX' was not declared in this scope
C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_temp
buf.c:43: error: there are no arguments to 'malloc' that depend on a template pa
rameter, so a declaration of 'malloc' must be available
In file included from C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/std
apis/stlport/stl/_algo.h:732,
                 from C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/std
apis/stlport/algorithm:44,
                 from C:\Program Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include
/Array.h:181,
                 from C:\Program Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include
/hxcpp.h:112,
                 from ./src/nme/display/JointStyle.cpp:1:
C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_algo
.c: In function '_Distance std::__random_number(_Distance)':
C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_algo
.c:436: error: there are no arguments to 'rand' that depend on a template parame
ter, so a declaration of 'rand' must be available
In file included from C:\Program Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include
/hxcpp.h:112,
                 from ./src/nme/display/JointStyle.cpp:1:
C:\Program Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include/Array.h: In member fu
nction 'Array<ELEM_>& Array<ELEM_>::operator=(const Dynamic&)':
C:\Program Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include/Array.h:467: warning:
 hex escape sequence out of range
In file included from C:\Program Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include
/hxcpp.h:113,
                 from ./src/nme/display/JointStyle.cpp:1:
C:\Program Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include/Class.h: In function
'bool hx::TCanCast(hx::Object*)':
C:\Program Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include/Class.h:113: error: m
ust #include <typeinfo> before using typeid
In file included from C:\Program Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include
/hxcpp.h:117,
                 from ./src/nme/display/JointStyle.cpp:1:
C:\Program Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include/hx/Operators.h: In fu
nction 'String operator+(const hx::ObjectPtr<T>&, const String&)':
C:\Program Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include/hx/Operators.h:30: wa
rning: hex escape sequence out of range
In file included from ./src/nme/display/JointStyle.cpp:4:
include/nme/display/JointStyle.h: In member function 'virtual String nme::displa
y::JointStyle_obj::GetEnumName() const':
include/nme/display/JointStyle.h:21: warning: hex escape sequence out of range
include/nme/display/JointStyle.h: In member function 'virtual String nme::displa
y::JointStyle_obj::__ToString() const':
include/nme/display/JointStyle.h:22: warning: hex escape sequence out of range
./src/nme/display/JointStyle.cpp: In function 'Dynamic nme::display::CreateJoint
Style_obj(String, hx::DynamicArray)':
./src/nme/display/JointStyle.cpp:15: warning: hex escape sequence out of range
./src/nme/display/JointStyle.cpp:15: warning: hex escape sequence out of range
./src/nme/display/JointStyle.cpp: In static member function 'static int nme::dis
play::JointStyle_obj::__FindIndex(String)':
./src/nme/display/JointStyle.cpp:19: warning: hex escape sequence out of range
./src/nme/display/JointStyle.cpp:20: warning: hex escape sequence out of range
./src/nme/display/JointStyle.cpp:21: warning: hex escape sequence out of range
./src/nme/display/JointStyle.cpp: In static member function 'static int nme::dis
play::JointStyle_obj::__FindArgCount(String)':
./src/nme/display/JointStyle.cpp:27: warning: hex escape sequence out of range
./src/nme/display/JointStyle.cpp:28: warning: hex escape sequence out of range
./src/nme/display/JointStyle.cpp:29: warning: hex escape sequence out of range
./src/nme/display/JointStyle.cpp: In member function 'virtual Dynamic nme::displ
ay::JointStyle_obj::__Field(const String&)':
./src/nme/display/JointStyle.cpp:35: warning: hex escape sequence out of range
./src/nme/display/JointStyle.cpp:36: warning: hex escape sequence out of range
./src/nme/display/JointStyle.cpp:37: warning: hex escape sequence out of range
./src/nme/display/JointStyle.cpp: At global scope:
./src/nme/display/JointStyle.cpp:42: warning: hex escape sequence out of range
./src/nme/display/JointStyle.cpp:43: warning: hex escape sequence out of range
./src/nme/display/JointStyle.cpp:44: warning: hex escape sequence out of range
./src/nme/display/JointStyle.cpp: In static member function 'static void nme::di
splay::JointStyle_obj::__register()':
./src/nme/display/JointStyle.cpp:61: warning: hex escape sequence out of range
./src/nme/display/JointStyle.cpp: In static member function 'static void nme::di
splay::JointStyle_obj::__boot()':
./src/nme/display/JointStyle.cpp:68: warning: hex escape sequence out of range
./src/nme/display/JointStyle.cpp:69: warning: hex escape sequence out of range
./src/nme/display/JointStyle.cpp:70: warning: hex escape sequence out of range
Called from <null> line 1
Called from BuildTool.hx line 840
Called from BuildTool.hx line 433
Called from BuildTool.hx line 456
Called from BuildTool.hx line 529
Called from BuildTool.hx line 561
Called from BuildTool.hx line 166
Uncaught exception - Error : 1 - build cancelled
Error : Build failedBuildCommon.xml

[singmajesty]

If you're going to use a symbian directive, and not the webos directive,  
then you're going to have to step through the code and work with the  
conditionals. There are many instances in the code where it will use  
directives like:


ifdef ANDROID


or


if defined(ANDROID) || defined(IPHONE) || defined(WEBOS)


or


ifndef ANDROID



Without the proper directives in the code for Symbian, it may be trying to  
compile code which was not meant for mobile. You will also have to  
determine the best compiler flags to use. This whole process took quite  
some time for me to work out, however, you may be able to duplicate most  
of what I've done for webOS. Like I mentioned before, Android runs inside  
a Java wrapper, and iPhone requires static libraries and leverages  
Objective-C in a few places. webOS is pure C++, SDL, OpenGL, so in some  
ways it was trial and error to determine where I should borrow from the  
Android directive, the iPhone directive, or neither. You will probably be  
able to borrow almost entirely from the webOS directive, since they may be  
similar.

In fact, if I were you, the first thing I would try is edit the webOS  
options in BuildCommon.xml, to point to arm-none-symbianelf-g++ instead of  
arm-none-gnueabi-linux-g++, then alter those processor specific flags (-m  
stuff) and see if it compiles. That might work. If it does, you can either  
continue to use webOS for now, or try and step through and duplicate  
things.


On Wed, 28 Jul 2010 07:16:46 -0700, m5no1 <[hidden email]> wrote:

>
> hi~
>
> thanks for your reply
>
> I have add symbian section to buildcommon.xml
> http://pastie.org/1063885 http://pastie.org/1063885
>
> and it got error...
>
> C:\Documents and Settings\m5\My Documents\haxe\cppstest\cpp2\src>haxe  
> c.hxml
> -D
> symbian
> haxelib run hxcpp Build.xml haxe -Dcpp -Dhaxe_205 -Dnme -Dsymbian -Dtrue
> arm-none-symbianelf-g++ -c -O2 -DSYMBIAN -fvisibility=hidden
> -IC:/S60/devices/S6
> 0_5th_Edition_SDK_v1.0/epoc32/include/gcce/
> -IC:/S60/devices/S60_5th_Edition_SDK
> _v1.0/epoc32/include/libc
> -IC:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/inclu
> de -IC:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/variant
> -IC:/S60/dev
> ices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport -IC:\Program
> Files\
> Motion-Twin\haxe\lib\hxcpp\2,05,1/include -march=armv5t -mthumb -mapcs
> -nostdinc
>  -D__MARM__ -D__MARM_ARMV5__ -D__MARM_THUMB__ -D__MARM_INTERWORK__
> -D__EABI__ -D
> __EXE__ -D_DEBUG -D_UNICODE -D__SUPPORT_CPP_EXCEPTIONS__ -D__GCCE__
> -D__SYMBIAN3
> 2__ -D__EPOC32__ -D__S60_50__ -D__S60_3X__ -D__SERIES60_3X__
> -D__PRODUCT_INCLUDE
> __=\'C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/variant/symbian_os.h
> rh\' -Iinclude -frtti ./src/nme/display/JointStyle.cpp
> -oobj/symbian//src/nme/di
> splay/JointStyle.o
> <command-line>:0: warning: missing terminating ' character
> In file included from
> C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/lib
> c/string.h:25,
>                  from C:\Program
> Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include
> /hxcpp.h:6,
>                  from ./src/nme/display/JointStyle.cpp:1:
> C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/libc/stddef.h:20:
> error:
> redeclaration of C++ built-in type 'wchar_t'
> In file included from C:\Program
> Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include
> /hxcpp.h:103,
>                  from ./src/nme/display/JointStyle.cpp:1:
> C:\Program Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include/hx/Object.h:  
> In
> const
> ructor 'hx::ObjectPtr<O>::ObjectPtr(const hx::ObjectPtr<SOURCE_>&)':
> C:\Program  
> Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include/hx/Object.h:149:
> erro
> r: must #include <typeinfo> before using typeid
> C:\Program Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include/hx/Object.h:  
> In
> const
> ructor 'hx::ObjectPtr<O>::ObjectPtr(const SOURCE_*)':
> C:\Program  
> Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include/hx/Object.h:163:
> erro
> r: must #include <typeinfo> before using typeid
> In file included from
> C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/std
> apis/stlport/stl/_construct.h:42,
>                  from
> C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/std
> apis/stlport/stl/_pair.h:34,
>                  from
> C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/std
> apis/stlport/stl/_algobase.h:51,
>                  from
> C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/std
> apis/stlport/stl/_algo.h:34,
>                  from
> C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/std
> apis/stlport/algorithm:44,
>                  from C:\Program
> Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include
> /Array.h:181,
>                  from C:\Program
> Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include
> /hxcpp.h:112,
>                  from ./src/nme/display/JointStyle.cpp:1:
> C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_new.
> h: At global scope:
> C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_new.
> h:150: error: expected unqualified-id before '&' token
> C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_new.
> h:150: error: expected ')' before '&' token
> C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_new.
> h:150: error: expected initializer before '&' token
> C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_new.
> h:152: error: expected unqualified-id before '&' token
> C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_new.
> h:152: error: expected ')' before '&' token
> C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_new.
> h:152: error: expected initializer before '&' token
> C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_new.
> h:154: error: expected unqualified-id before '&' token
> C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_new.
> h:154: error: expected ')' before '&' token
> C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_new.
> h:154: error: expected initializer before '&' token
> C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_new.
> h:156: error: expected unqualified-id before '&' token
> C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_new.
> h:156: error: expected ')' before '&' token
> C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_new.
> h:156: error: expected initializer before '&' token
> In file included from
> C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/std
> apis/stlport/stl/_algo.h:38,
>                  from
> C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/std
> apis/stlport/algorithm:44,
>                  from C:\Program
> Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include
> /Array.h:181,
>                  from C:\Program
> Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include
> /hxcpp.h:112,
>                  from ./src/nme/display/JointStyle.cpp:1:
> C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_temp
> buf.h: In function 'void std::return_temporary_buffer(_Tp*)':
> C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_temp
> buf.h:73: error: there are no arguments to 'free' that depend on a  
> template
> para
> meter, so a declaration of 'free' must be available
> C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_temp
> buf.h:73: note: (if you use '-fpermissive', G++ will accept your code,  
> but
> allow
> ing the use of an undeclared name is deprecated)
> C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_temp
> buf.h: In member function 'void std::_Temporary_buffer<_ForwardIterator,
> _Tp>::_
> M_allocate_buffer()':
> C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_temp
> buf.h:87: error: 'INT_MAX' was not declared in this scope
> C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_temp
> buf.h:91: error: there are no arguments to 'malloc' that depend on a
> template pa
> rameter, so a declaration of 'malloc' must be available
> In file included from
> C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/std
> apis/stlport/stl/_tempbuf.h:158,
>                  from
> C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/std
> apis/stlport/stl/_algo.h:38,
>                  from
> C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/std
> apis/stlport/algorithm:44,
>                  from C:\Program
> Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include
> /Array.h:181,
>                  from C:\Program
> Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include
> /hxcpp.h:112,
>                  from ./src/nme/display/JointStyle.cpp:1:
> C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_temp
> buf.c: In function 'std::pair<_Tp*, long int>
> std::__get_temporary_buffer(ptrdif
> f_t, _Tp*)':
> C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_temp
> buf.c:39: error: 'INT_MAX' was not declared in this scope
> C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_temp
> buf.c:43: error: there are no arguments to 'malloc' that depend on a
> template pa
> rameter, so a declaration of 'malloc' must be available
> In file included from
> C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/std
> apis/stlport/stl/_algo.h:732,
>                  from
> C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/std
> apis/stlport/algorithm:44,
>                  from C:\Program
> Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include
> /Array.h:181,
>                  from C:\Program
> Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include
> /hxcpp.h:112,
>                  from ./src/nme/display/JointStyle.cpp:1:
> C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_algo
> .c: In function '_Distance std::__random_number(_Distance)':
> C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport/stl/_algo
> .c:436: error: there are no arguments to 'rand' that depend on a template
> parame
> ter, so a declaration of 'rand' must be available
> In file included from C:\Program
> Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include
> /hxcpp.h:112,
>                  from ./src/nme/display/JointStyle.cpp:1:
> C:\Program Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include/Array.h: In
> member fu
> nction 'Array<ELEM_>& Array<ELEM_>::operator=(const Dynamic&)':
> C:\Program Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include/Array.h:467:
> warning:
>  hex escape sequence out of range
> In file included from C:\Program
> Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include
> /hxcpp.h:113,
>                  from ./src/nme/display/JointStyle.cpp:1:
> C:\Program Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include/Class.h: In
> function
> 'bool hx::TCanCast(hx::Object*)':
> C:\Program Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include/Class.h:113:
> error: m
> ust #include <typeinfo> before using typeid
> In file included from C:\Program
> Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include
> /hxcpp.h:117,
>                  from ./src/nme/display/JointStyle.cpp:1:
> C:\Program  
> Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include/hx/Operators.h:
> In fu
> nction 'String operator+(const hx::ObjectPtr<T>&, const String&)':
> C:\Program
> Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include/hx/Operators.h:30: wa
> rning: hex escape sequence out of range
> In file included from ./src/nme/display/JointStyle.cpp:4:
> include/nme/display/JointStyle.h: In member function 'virtual String
> nme::displa
> y::JointStyle_obj::GetEnumName() const':
> include/nme/display/JointStyle.h:21: warning: hex escape sequence out of
> range
> include/nme/display/JointStyle.h: In member function 'virtual String
> nme::displa
> y::JointStyle_obj::__ToString() const':
> include/nme/display/JointStyle.h:22: warning: hex escape sequence out of
> range
> ./src/nme/display/JointStyle.cpp: In function 'Dynamic
> nme::display::CreateJoint
> Style_obj(String, hx::DynamicArray)':
> ./src/nme/display/JointStyle.cpp:15: warning: hex escape sequence out of
> range
> ./src/nme/display/JointStyle.cpp:15: warning: hex escape sequence out of
> range
> ./src/nme/display/JointStyle.cpp: In static member function 'static int
> nme::dis
> play::JointStyle_obj::__FindIndex(String)':
> ./src/nme/display/JointStyle.cpp:19: warning: hex escape sequence out of
> range
> ./src/nme/display/JointStyle.cpp:20: warning: hex escape sequence out of
> range
> ./src/nme/display/JointStyle.cpp:21: warning: hex escape sequence out of
> range
> ./src/nme/display/JointStyle.cpp: In static member function 'static int
> nme::dis
> play::JointStyle_obj::__FindArgCount(String)':
> ./src/nme/display/JointStyle.cpp:27: warning: hex escape sequence out of
> range
> ./src/nme/display/JointStyle.cpp:28: warning: hex escape sequence out of
> range
> ./src/nme/display/JointStyle.cpp:29: warning: hex escape sequence out of
> range
> ./src/nme/display/JointStyle.cpp: In member function 'virtual Dynamic
> nme::displ
> ay::JointStyle_obj::__Field(const String&)':
> ./src/nme/display/JointStyle.cpp:35: warning: hex escape sequence out of
> range
> ./src/nme/display/JointStyle.cpp:36: warning: hex escape sequence out of
> range
> ./src/nme/display/JointStyle.cpp:37: warning: hex escape sequence out of
> range
> ./src/nme/display/JointStyle.cpp: At global scope:
> ./src/nme/display/JointStyle.cpp:42: warning: hex escape sequence out of
> range
> ./src/nme/display/JointStyle.cpp:43: warning: hex escape sequence out of
> range
> ./src/nme/display/JointStyle.cpp:44: warning: hex escape sequence out of
> range
> ./src/nme/display/JointStyle.cpp: In static member function 'static void
> nme::di
> splay::JointStyle_obj::__register()':
> ./src/nme/display/JointStyle.cpp:61: warning: hex escape sequence out of
> range
> ./src/nme/display/JointStyle.cpp: In static member function 'static void
> nme::di
> splay::JointStyle_obj::__boot()':
> ./src/nme/display/JointStyle.cpp:68: warning: hex escape sequence out of
> range
> ./src/nme/display/JointStyle.cpp:69: warning: hex escape sequence out of
> range
> ./src/nme/display/JointStyle.cpp:70: warning: hex escape sequence out of
> range
> Called from <null> line 1
> Called from BuildTool.hx line 840
> Called from BuildTool.hx line 433
> Called from BuildTool.hx line 456
> Called from BuildTool.hx line 529
> Called from BuildTool.hx line 561
> Called from BuildTool.hx line 166
> Uncaught exception - Error : 1 - build cancelled
> Error : Build failed
> http://haxe.1354130.n2.nabble.com/file/n5345664/BuildCommon.xml
> BuildCommon.xml

--
Joshua Granick
Owner / Lead Developer
[ eclecticdesignstudio ]
P: [phone]

--
haXe - an open source web programming language
http://haxe.org

[m5no1]

there is a string.h in C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport,and i have add " IC:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport " flag,but it since havn't been included.

[m5no1]

i have fixed the include problem ,but there is a new error here:


C:\Documents and Settings\m5\My Documents\haxe\cppstest\cpp2\src>haxe c.hxml -D
symbian
haxelib run hxcpp Build.xml haxe -Dcpp -Dhaxe_205 -Dnme -Dsymbian -Dtrue
arm-none-symbianelf-g++ -c -O2 -DSYMBIAN -fvisibility=hidden -IC:/S60/devices/S6
0_5th_Edition_SDK_v1.0/epoc32/include/gcce/ -IC:/S60/devices/S60_5th_Edition_SDK
_v1.0/epoc32/include -IC:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/va
riant -IC:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis -IC:/S60/
devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport -IC:\Program Fil
es\Motion-Twin\haxe\lib\hxcpp\2,05,1/include -march=armv5t -mthumb -mapcs -nostd
inc -D__MARM__ -D__MARM_ARMV5__ -D__MARM_THUMB__ -D__MARM_INTERWORK__ -D__EABI__
 -D__EXE__ -D_DEBUG -D_UNICODE -D__SUPPORT_CPP_EXCEPTIONS__ -D__GCCE__ -D__SYMBI
AN32__ -D__EPOC32__ -D__S60_50__ -D__S60_3X__ -D__SERIES60_3X__ -D__PRODUCT_INCL
UDE__=\'C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/variant/symbian_o
s.hrh\' -D__GCC32__ -D_WCHAR_T_DECLARED -Iinclude -frtti ./src/nme/display/Joint
Style.cpp -oobj/symbian//src/nme/display/JointStyle.o
<command-line>:0: warning: missing terminating ' character
In file included from C:\Program Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include
/hxcpp.h:103,
                 from ./src/nme/display/JointStyle.cpp:1:
C:\Program Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include/hx/Object.h: In const
ructor 'hx::ObjectPtr<O>::ObjectPtr(const hx::ObjectPtr<SOURCE_>&)':
C:\Program Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include/hx/Object.h:149: erro
r: must #include <typeinfo> before using typeid



can any one help me ?  thanks!

[m5no1]

i have fixed the include problem ,but there is a new error here:


C:\Documents and Settings\m5\My Documents\haxe\cppstest\cpp2\src>haxe c.hxml -D
symbian
haxelib run hxcpp Build.xml haxe -Dcpp -Dhaxe_205 -Dnme -Dsymbian -Dtrue
arm-none-symbianelf-g++ -c -O2 -DSYMBIAN -fvisibility=hidden -IC:/S60/devices/S6
0_5th_Edition_SDK_v1.0/epoc32/include/gcce/ -IC:/S60/devices/S60_5th_Edition_SDK
_v1.0/epoc32/include -IC:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/va
riant -IC:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis -IC:/S60/
devices/S60_5th_Edition_SDK_v1.0/epoc32/include/stdapis/stlport -IC:\Program Fil
es\Motion-Twin\haxe\lib\hxcpp\2,05,1/include -march=armv5t -mthumb -mapcs -nostd
inc -D__MARM__ -D__MARM_ARMV5__ -D__MARM_THUMB__ -D__MARM_INTERWORK__ -D__EABI__
 -D__EXE__ -D_DEBUG -D_UNICODE -D__SUPPORT_CPP_EXCEPTIONS__ -D__GCCE__ -D__SYMBI
AN32__ -D__EPOC32__ -D__S60_50__ -D__S60_3X__ -D__SERIES60_3X__ -D__PRODUCT_INCL
UDE__=\'C:/S60/devices/S60_5th_Edition_SDK_v1.0/epoc32/include/variant/symbian_o
s.hrh\' -D__GCC32__ -D_WCHAR_T_DECLARED -Iinclude -frtti ./src/nme/display/Joint
Style.cpp -oobj/symbian//src/nme/display/JointStyle.o
<command-line>:0: warning: missing terminating ' character
In file included from C:\Program Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include
/hxcpp.h:103,
                 from ./src/nme/display/JointStyle.cpp:1:
C:\Program Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include/hx/Object.h: In const
ructor 'hx::ObjectPtr<O>::ObjectPtr(const hx::ObjectPtr<SOURCE_>&)':
C:\Program Files\Motion-Twin\haxe\lib\hxcpp\2,05,1/include/hx/Object.h:149: erro
r: must #include <typeinfo> before using typeid



can any one help me ?  thanks!