Home » Developing U++ » U++ Developers corner » Current porting state?
| Current porting state? [message #4930] |
Fri, 25 August 2006 17:24  |
Werner
Messages: 234
Registered: May 2006
Location: Cologne / Germany
|
Experienced Member |
|
|
Mirek's message #4924 "PocketPC conquered...."
I am happy to announce that the hard part of PocketPC support is finished - I was able
to run most of "examples" on my PDA (interestingly, without any changes to the examples code,
just compile&run).
Now of course, a lot of issues remains to be resolved, starting with right click emulation etc....
but the core work is already done.
Mirek
P.S.: Somebody to donate OSX capable PowerPC Mac?
gives cause to update my web site. So:
What is the current state of the Linux, UNIX, MacOS, ... portings?
Werner
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Current porting state? [message #5251 is a reply to message #5242] |
Mon, 11 September 2006 14:05  |
lundman
Messages: 175
Registered: March 2006
Location: Tokyo
|
Experienced Member |
|
|
| luzr wrote on Mon, 11 September 2006 17:41 |
Well, I might have missed something, but if they are in the C++ code, could you list them please?
|
Nah, usual porting things when it's Linux coders  .. lets see if I remember.
loff_t=off_t
lseek64=lseek
ftruncate64=ftruncate
strerror_r=strerror
Hmm actually, i think the latter needed some code changes due to the argument count differences.
Considered autoconf? I know it doesn't fit in the picture when you have the IDE running, but to build the ide maybe?
Oh, as a corollary, I need a way to run ./configure in my Project from the ide.. possible?
| Quote: |
BE support should be easy (right now there is just single place which needs fixing). Do you have any hardware to test with?
|
Lots and lots. If you want to fiddle with the last place, we can start on some debugging.
Lund
|
|
|
|
| Re: Current porting state? [message #5253 is a reply to message #5251] |
Mon, 11 September 2006 14:16 |
 |
mirek
Messages: 14290
Registered: November 2005
|
Ultimate Member |
|
|
| Quote: |
Considered autoconf? I know it doesn't fit in the picture when you have the IDE running, but to build the ide maybe?
|
No problem, but do not expect me to do that. I still hope for posix maintainer to do that for us...
| Quote: |
Oh, as a corollary, I need a way to run ./configure in my Project from the ide.. possible?
|
The only possible way would be using custom build steps AFAIK.
| Quote: |
Lots and lots. If you want to fiddle with the last place, we can start on some debugging.
|
Actually, the last place I am aware of deals with swapping order in serialization, it would be problem only if you would want to share serialization between BE/LE machines (which is hardly the case now).
Means, if you can, what about to simply try the current version?
Mirek
|
|
|
|
| Re: Current porting state? [message #5262 is a reply to message #5253] |
Tue, 12 September 2006 03:13 |
lundman
Messages: 175
Registered: March 2006
Location: Tokyo
|
Experienced Member |
|
|
| luzr wrote on Mon, 11 September 2006 21:16 |
No problem, but do not expect me to do that. I still hope for posix maintainer to do that for us...
|
Well, let me know. I just forced myself to learn autoconf, and converted 4 of my projects to use it. It was surprisingly easy, but it helped to find an excellent PDF walk-through.
| Quote: |
The only possible way would be using custom build steps AFAIK.
|
I'll explore that, as long as it could be a possible step.
| Quote: |
Actually, the last place I am aware of deals with swapping order in serialization, it would be problem only if you would want to share serialization between BE/LE machines (which is hardly the case now).
Means, if you can, what about to simply try the current version?
Mirek
|
Ok, I have started that.
|
|
|
|
|
|
|
|
| Re: Current porting state? [message #5272 is a reply to message #5266] |
Tue, 12 September 2006 11:03 |
lundman
Messages: 175
Registered: March 2006
Location: Tokyo
|
Experienced Member |
|
|
Right, I created a new flagNETBSD ok, changed everywhere so it compiles without issue. The IDE does seem to have some trouble:
http://netbsd.interq.or.jp/~lundman/upp-609dev1.jpg
But testing all Examples that build, they all work fine.
Did the same for OSX, which compiles, but it does not start. Initially it is:
0xffff86f8 in ___bzero () at
/System/Library/Frameworks/System.framework/PrivateHeaders/p pc/cpu_capabilities.h:187
101::memset(&obj, 0, sizeof(obj));
Which does not really make sense. A bit of googling seems to suggest there is a namespace issue "history", with libedit (readline).
However, I commented that line out, in the interest to see how much further I could get:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x3a262ff8
0x0026e500 in UnpackRLE (t=0x3a262ff8, s=0x421995 "ËËËÃÔ×\205o^rQ:\204a4\030\003vT=\215udÙåç\001òòò", len=<incomplete type>) at /Users/lundman/uppsrc/uppsrc/Draw/ImageBlit.cpp:51
51 *t++ = h;
Also seems odd, perhaps still related to the first issue, so I need to track that down first.
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Current porting state? [message #5298 is a reply to message #5283] |
Wed, 13 September 2006 03:27 |
lundman
Messages: 175
Registered: March 2006
Location: Tokyo
|
Experienced Member |
|
|
I do not know if I am doing it the correct way, but I exported the Makefile for HelloWorld and set to.
The flagUSEMALLOC, when enabled, created some undefined references MemoryDumpLeaks() in Core.h, which was easy to fix, but I took out USEMALLOC anyway.
Compiling HelloWorld failed due to:
StaticCriticalSection::Initialize
So I wrapped the prototype in #ifdef _MULTITHREADED in mt.h
Then we were linked. Still cores in identical memset(), commented out.
Cores in UnpackRLE, so I made it just return s;
Cores in memcpy:82 Util.h
Cores in memset:273 Image.cpp
At this point I get the Window comes up, with working menu bar.
Picking About will core again, this time in:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x36340834
0x000e14fc in BltAAMapRGBA4 (dest=0x6888c00, s=0x36340834, map=0x6377080) at /Users/lundman/uppsrc/uppsrc/Draw/ImageScale.cpp:278
278 dest[0] = (s[0].b + s[step].b + s[2 * step].b + s[3 * step].b) << 6;
(gdb) p s
$1 = (const RGBA *) 0x36340834
(gdb) p *s
Cannot access memory at address 0x36340834
Why is it that your RGBA's, which seem to be defined as "RGBA *" or, pointers to an RGBA, end up with the RGBA value "0x36340834" (which looks like a clean RGBA value to me) instead of a pointer to said value.
Almost like:
RGBA *rgba;
*rgba = value;
.. is interpreted as "*(rgba)=value;" instead of the correct
"(*rgba)=value;".
|
|
|
|
| Re: Current porting state? [message #5299 is a reply to message #5298] |
Wed, 13 September 2006 08:10 |
|
mirek
Messages: 14290
Registered: November 2005
|
Ultimate Member |
|
|
| Quote: |
I do not know if I am doing it the correct way, but I exported the Makefile for HelloWorld and set to.
|
HelloWorld is still too big. First thing that you should make working when porting is logging (LOG and DUMP).
| Quote: |
The flagUSEMALLOC, when enabled, created some undefined references MemoryDumpLeaks() in Core.h, which was easy to fix, but I took out USEMALLOC anyway.
|
Rather stay with malloc. If there is something highly platform sensitive, it is heap allocator implementation.
| Quote: |
Compiling HelloWorld failed due to:
StaticCriticalSection::Initialize
|
Error?
| Quote: |
(gdb) p s
$1 = (const RGBA *) 0x36340834
(gdb) p *s
Cannot access memory at address 0x36340834
Why is it that your RGBA's, which seem to be defined as "RGBA *" or, pointers to an RGBA, end up with the RGBA value "0x36340834" (which looks like a clean RGBA value to me) instead of a pointer to said value.
Almost like:
RGBA *rgba;
*rgba = value;
.. is interpreted as "*(rgba)=value;" instead of the correct
"(*rgba)=value;".
|
Actually, I believe that debugger and compiler are correct. Just somehow s contains invalid address.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Current porting state? [message #5308 is a reply to message #5306] |
Wed, 13 September 2006 11:45 |
|
mirek
Messages: 14290
Registered: November 2005
|
Ultimate Member |
|
|
Image::Image(const Init& init)
{
ASSERT(init.info[0] >= 1);
Size sz;
sz.cx = PeekIL(init.info + 1);
sz.cy = PeekIL(init.info + 5);
ImageBuffer b(sz);
int i = 0;
while(i < init.scan_count) {
UnpackRLE(b[i], (const byte *)init.scans[i], sz.cx);
i++;
}
while(i < sz.cy)
memset(b[i++], 0, sizeof(RGBA) * sz.cx);
b.SetHotSpot(Point(PeekIL(init.info + 9), PeekIL(init.info + 13)));
Set(b);
}
Maybe PeekIL is the cause as it is affected by endianess.
It is defined in Core/util.h, util.cpp.
Maybe it is worth checking what is the status of
CPU_X86
CPU_LE
CPU_UNALIGNED
macros....
[Updated on: Wed, 13 September 2006 11:46] Report message to a moderator |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Goto Forum:
Current Time: Tue Apr 28 16:31:34 GMT+2 2026
Total time taken to generate the page: 0.01304 seconds
|
U++ framework
Search
Help
Members
Register
Login
Home
...)
