Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Developing U++ » Mac OS » MacOS X woes
Re: MacOS X woes [message #7281 is a reply to message #7280] Wed, 20 December 2006 04:44 Go to previous messageGo to next message
lundman is currently offline  lundman
Messages: 175
Registered: March 2006
Location: Tokyo
Experienced Member

Fails due to

53		int version = 5;
(gdb) s
54		s.Magic(0x12346);
(gdb) s
Upp::Stream::Magic (this=0xbffe6c20, magic=74566) at Stream.cpp:719
719		dword a = magic;
(gdb) s
720		*this % a;
[snip]
Upp::Stream::SerializeRaw (this=0xbffe6c20, data=0xbffe6a68, count=1) at Stream.cpp:459
459		EndianSwap(data, count);
[snip]
(gdb) n
Upp::Stream::operator% (this=0xbffe6c20, d=@0xbffe6a68) at Stream.cpp:592
592		return *this;

Upp::Stream::Magic (this=0xbffe6c20, magic=74566) at Stream.cpp:721
721		if(magic != a) LoadError();
(gdb) p magic
$16 = 74566
(gdb) p a
$17 = 1176699136

Re: MacOS X woes [message #7282 is a reply to message #7281] Wed, 20 December 2006 05:01 Go to previous messageGo to next message
lundman is currently offline  lundman
Messages: 175
Registered: March 2006
Location: Tokyo
Experienced Member
D'oh, you should have said I need to delete my .ide/ config files since they are all big-endian Smile

However, we do get this situation:

rm .ide/ide.cfg
gdb ide
(gdb) run
(Once loaded, click Cancel instead of Selection a main Package)
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x1876d580
0x00275584 in Upp::RichEdit::SetupRuler (this=0xbfff707c) at Editor.cpp:272
272		                zoom, q.grid, q.numbers, q.numbermul, q.marks);

(gdb) p unit
$1 = 16777216



And indeed, now that it has written "ide.cfg" it won't load it unless I delete it first, with the exact same core. So for some reason "unit" ends up big-endian in memory (as well as on disk?) even when Initialised from scratch.


[Updated on: Wed, 20 December 2006 05:02]

Report message to a moderator

Re: MacOS X woes [message #7283 is a reply to message #7282] Wed, 20 December 2006 08:55 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
I do not see obvious problem.

I think breakpoint at RichEdit/Editor.cpp 452 and see what is going on....

Mirek
Re: MacOS X woes [message #7284 is a reply to message #7227] Wed, 20 December 2006 08:57 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
lundman wrote on Mon, 18 December 2006 19:15


Ah whoopsie.. I assumed you had previously done CPU_PPC to be powerpc, since the PocketPC cpu arch is ARM, SH3 or MIPS.

I will guess what is needed here and submit a patch.



I use something along the lines of:


#ifdef flagOSX11




OK, now at the beginning of Core.h.

Mirek

[Updated on: Wed, 20 December 2006 08:58]

Report message to a moderator

Re: MacOS X woes [message #7285 is a reply to message #7283] Wed, 20 December 2006 09:14 Go to previous messageGo to next message
lundman is currently offline  lundman
Messages: 175
Registered: March 2006
Location: Tokyo
Experienced Member

Right
Breakpoint 1, Upp::RichEdit::SerializeSettings (this=0xbfff707c, s=@0xbffe6c20) at /Users/lundman/src/upp/uppsrc/RichEdit/Editor.cpp:453
453		int version = 1;
(gdb) s
454		s / version;
(gdb) s
Upp::Stream::operator/ (this=0xbffe6c20, i=@0xbffe69b8) at Stream.h:223
223		Stream&   operator/(int& i)            { dword w = i + 1; Pack(w); i = w - 1; return *this; }
(gdb) s
Upp::Stream::Pack (this=0xbffe6c20, w=@0xbffe6958) at /Users/lundman/src/upp/uppsrc/Core/Stream.cpp:471
471		if(IsError()) return;
(gdb) n
491	}
(gdb) n
0x0041d410 in Upp::Stream::operator/ (this=0xbffe6c20, i=@0xbffe69b8) at Stream.h:223
223		Stream&   operator/(int& i)            { dword w = i + 1; Pack(w); i = w - 1; return *this; }
(gdb) n
Upp::RichEdit::SerializeSettings (this=0xbfff707c, s=@0xbffe6c20) at /Users/lundman/src/upp/uppsrc/RichEdit/Editor.cpp:455
455		s % unit;
(gdb) p version
$4 = 1
(gdb) p unit
$5 = 1
(gdb) s
Upp::Stream::operator% (this=0xbffe6c20, d=@0xbfffb67c) at /Users/lundman/src/upp/uppsrc/Core/Stream.cpp:585
585		SerializeRaw((dword *)&d, 1);
(gdb) s
Upp::Stream::SerializeRaw (this=0xbffe6c20, data=0xbfffb67c, count=1) at /Users/lundman/src/upp/uppsrc/Core/Stream.cpp:457
457		SerializeRaw((byte *)data, 4 * count);
(gdb) s
Upp::Stream::SerializeRaw (this=0xbffe6c20, data=0xbfffb67c "", size=4) at /Users/lundman/src/upp/uppsrc/Core/Stream.cpp:442
442		if(IsError()) return;
(gdb) n
447	}
(gdb) n
Upp::Stream::SerializeRaw (this=0xbffe6c20, data=0xbfffb67c, count=1) at /Users/lundman/src/upp/uppsrc/Core/Stream.cpp:459
459		EndianSwap(data, count);
(gdb) p data
$6 = (dword *) 0xbfffb67c
(gdb) p *data
$7 = 1
(gdb) n
461	}
(gdb) p *data
$8 = 16777216
(gdb) n
Upp::Stream::operator% (this=0xbffe6c20, d=@0xbfffb67c) at /Users/lundman/src/upp/uppsrc/Core/Stream.cpp:586
586		return *this;
(gdb) 
587	}
(gdb) 
Upp::RichEdit::SerializeSettings (this=0xbfff707c, s=@0xbffe6c20) at /Users/lundman/src/upp/uppsrc/RichEdit/Editor.cpp:456
456		s % showcodes;
(gdb) p unit
$9 = 16777216


Seems it is given a default value, then gets EndianSwapped, when maybe it should only be endianswapped when read?

Re: MacOS X woes [message #7286 is a reply to message #7285] Wed, 20 December 2006 09:29 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
lundman wrote on Wed, 20 December 2006 03:14


Right
Breakpoint 1, Upp::RichEdit::SerializeSettings (this=0xbfff707c, s=@0xbffe6c20) at /Users/lundman/src/upp/uppsrc/RichEdit/Editor.cpp:453
453		int version = 1;
(gdb) s
454		s / version;
(gdb) s
Upp::Stream::operator/ (this=0xbffe6c20, i=@0xbffe69b8) at Stream.h:223
223		Stream&   operator/(int& i)            { dword w = i + 1; Pack(w); i = w - 1; return *this; }
(gdb) s
Upp::Stream::Pack (this=0xbffe6c20, w=@0xbffe6958) at /Users/lundman/src/upp/uppsrc/Core/Stream.cpp:471
471		if(IsError()) return;
(gdb) n
491	}
(gdb) n
0x0041d410 in Upp::Stream::operator/ (this=0xbffe6c20, i=@0xbffe69b8) at Stream.h:223
223		Stream&   operator/(int& i)            { dword w = i + 1; Pack(w); i = w - 1; return *this; }
(gdb) n
Upp::RichEdit::SerializeSettings (this=0xbfff707c, s=@0xbffe6c20) at /Users/lundman/src/upp/uppsrc/RichEdit/Editor.cpp:455
455		s % unit;
(gdb) p version
$4 = 1
(gdb) p unit
$5 = 1
(gdb) s
Upp::Stream::operator% (this=0xbffe6c20, d=@0xbfffb67c) at /Users/lundman/src/upp/uppsrc/Core/Stream.cpp:585
585		SerializeRaw((dword *)&d, 1);
(gdb) s
Upp::Stream::SerializeRaw (this=0xbffe6c20, data=0xbfffb67c, count=1) at /Users/lundman/src/upp/uppsrc/Core/Stream.cpp:457
457		SerializeRaw((byte *)data, 4 * count);
(gdb) s
Upp::Stream::SerializeRaw (this=0xbffe6c20, data=0xbfffb67c "", size=4) at /Users/lundman/src/upp/uppsrc/Core/Stream.cpp:442
442		if(IsError()) return;
(gdb) n
447	}
(gdb) n
Upp::Stream::SerializeRaw (this=0xbffe6c20, data=0xbfffb67c, count=1) at /Users/lundman/src/upp/uppsrc/Core/Stream.cpp:459
459		EndianSwap(data, count);
(gdb) p data
$6 = (dword *) 0xbfffb67c
(gdb) p *data
$7 = 1
(gdb) n
461	}
(gdb) p *data
$8 = 16777216
(gdb) n
Upp::Stream::operator% (this=0xbffe6c20, d=@0xbfffb67c) at /Users/lundman/src/upp/uppsrc/Core/Stream.cpp:586
586		return *this;
(gdb) 
587	}
(gdb) 
Upp::RichEdit::SerializeSettings (this=0xbfff707c, s=@0xbffe6c20) at /Users/lundman/src/upp/uppsrc/RichEdit/Editor.cpp:456
456		s % showcodes;
(gdb) p unit
$9 = 16777216


Seems it is given a default value, then gets EndianSwapped, when maybe it should only be endianswapped when read?




Oops. I am stupid. There must be TWO swaps, one before SerializeRaw, second after it!

void Stream::SerializeRaw(word *data, dword count) {
#ifdef CPU_BE
	EndianSwap(data, count);
#endif
	SerializeRaw((byte *)data, 2 * count);
#ifdef CPU_BE
	EndianSwap(data, count);
#endif
}

void Stream::SerializeRaw(dword *data, dword count) {
#ifdef CPU_BE
	EndianSwap(data, count);
#endif
	SerializeRaw((byte *)data, 4 * count);
#ifdef CPU_BE
	EndianSwap(data, count);
#endif
}

void Stream::SerializeRaw(uint64 *data, dword count) {
#ifdef CPU_BE
	EndianSwap(data, count);
#endif
	SerializeRaw((byte *)data, 8 * count);
#ifdef CPU_BE
	EndianSwap(data, count);
#endif
}



(later we most likely should speed optimize that)

Mirek
Re: MacOS X woes [message #7287 is a reply to message #7286] Wed, 20 December 2006 09:50 Go to previous messageGo to next message
lundman is currently offline  lundman
Messages: 175
Registered: March 2006
Location: Tokyo
Experienced Member
I pretty guessed that was the case, and it fixed it. It starts up correctly, and looks nice. No change in the icons that are off-colour still.

Can't build anything at the moment, but I think that is due to that the -current version is "in between" versions, maybe.

HelloWorld.cpp:

hello.cpp:3: error: expected class name before `{' token


Hmm odd - but anyway, will sync again next change.

What we were fixing was the Image Editor in ide, and that does work now (reading my little endian .iml file and displays correctly) so that is one bug down.

To focus on why icons in the IDE are odd coloured, where are they coming from? For example the "Help Topics"'s question mark icon?

Any of the Examples do simple .png, .bmp tests?





Re: MacOS X woes [message #7288 is a reply to message #7287] Wed, 20 December 2006 09:59 Go to previous messageGo to next message
lundman is currently offline  lundman
Messages: 175
Registered: March 2006
Location: Tokyo
Experienced Member

Ah no I lie, it was just that my icon had little colour.

If I draw a line on icons

line of red
line of green
line of blue
line of purple

I visually see
line of "nothing"
line of "nothing"
line of blue
line of cyan

Hmm maybe I shoul dhave screenshot that.. So, are RGBA perhaps needed to be Endian swapped too?
Re: MacOS X woes [message #7289 is a reply to message #7288] Wed, 20 December 2006 10:50 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Yes, very likely, RGBA has to be swapped before being sent to X11.

There are two ways how to do that. I think we should try to alter RGBA structure itself first

Core/Color.cpp

#ifdef CPU_LE
struct RGBA : Moveable<RGBA> {
	byte b, g, r, a;
};
#else
struct RGBA : Moveable<RGBA> {
	byte a, r, g, b;
};
#endif


Mirek
Re: MacOS X woes [message #7291 is a reply to message #7289] Wed, 20 December 2006 13:23 Go to previous messageGo to next message
lundman is currently offline  lundman
Messages: 175
Registered: March 2006
Location: Tokyo
Experienced Member
http://netbsd.interq.or.jp/~lundman/osx8.jpg

Very pretty. Running out of things to fix now. Only thing missing is the ability to specify linking options, or somehow be able to do cross-compile for the other arch.

Final code changes:
Core/Core.h
#endif // #ifdef flagFREEBSD

#ifdef flagOSX11
    #define PLATFORM_OSX11
    #define PLATFORM_POSIX
    #ifdef flagGUI
        #define PLATFORM_X11
    #endif

    #ifdef flagTESTLEAKS
        #define TESTLEAKS
    #endif

     // defines set by OsX for us.                                              
    #ifdef __POWERPC__
        #define flagPOWERPC
    #endif

    #ifdef __i386__
        #define flagX86
    #endif

#endif

#elif defined(flagPPC)
    #define CPU_32
    #define CPU_PPC
    #define CPU_BE
    #define CPU_BIG_ENDIAN
    #define CPU_ALIGNED
+#elif defined(flagPOWERPC)
+    #define CPU_32
+    #define CPU_POWERPC
+    #define CPU_BE
+    #define CPU_BIG_ENDIAN
+    #define CPU_ALIGNED
#else



And the same changed in CppBuilder.cpp and GccBuilder.cpp, Host.cpp, bmphdr.h

And the 2 PackageOrganiser changes.

Next semi-stable release I can make a PPC binary, but Intel needs to wait for the Link options (unless I temporarily hardcode it)

Re: MacOS X woes [message #7292 is a reply to message #7291] Wed, 20 December 2006 16:06 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Do you think you could zip and post all changed files? (Just to be sure that I apply changes correctly).

Mirek
Re: MacOS X woes [message #7299 is a reply to message #7292] Thu, 21 December 2006 02:21 Go to previous messageGo to next message
lundman is currently offline  lundman
Messages: 175
Registered: March 2006
Location: Tokyo
Experienced Member
As requested, attached file.

I guess I could also mention two other things, they don't really affect the usage of U++, but sometimes perfection is desirable.

When a Window is minimized (or possibly removed) Console gets:
X Error: BadMatch (invalid parameter attributes), request: X_SetInputFocus, resource id: 6295038 = 600DFE


but it is just noisy, no noticable impact.

And when you exit the Ide:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x000004d0
0x00f20468 in XQueryExtension ()
(gdb) bt
#0  0x00f20468 in XQueryExtension ()
#1  0x00f161c0 in XInitExtension ()
#2  0x018bf34c in XextAddDisplay ()
#3  0x00df11e0 in XRenderFreePicture ()
#4  0x00320568 in Upp::Image::Data::SysRelease (this=0x1bd3488) at /Users/lundman/src/upp/uppsrc/Draw/ImageX11.cpp:63
#5  0x002fdbf4 in Upp::Image::Data::~Data (this=0x1bd3488) at Image.cpp:324
#6  0x005850dc in Upp::Image::Data::Release (this=0x1bd3488) at Image.h:117
#7  0x002fdd04 in Upp::Image::~Image (this=0x200993c) at Image.cpp:278
#8  0x0044928c in Upp::Iml::IImage::~IImage (this=0x2009938) at Image.h:253
#9  0x0045a694 in Upp::DestroyArray<Upp::Iml::IImage> (t=0x2009938, lim=0x2009a10) at Topt.h:175
#10 0x0045a76c in Upp::Vector<Upp::Iml::IImage>::Free (this=0x91ea40) at Vcont.hpp:101
#11 0x0045a80c in Upp::Vector<Upp::Iml::IImage>::~Vector (this=0x91ea40) at Vcont.h:82
#12 0x0045a848 in Upp::AMap<Upp::String, Upp::Iml::IImage, Upp::Vector<Upp::Iml::IImage>, Upp::StdHash<Upp::String> >::~AMap (this=0x91ea04) at Map.h:2
#13 0x0045a8c0 in Upp::VectorMap<Upp::String, Upp::Iml::IImage, Upp::StdHash<Upp::String> >::~VectorMap (this=0x91ea00) at Map.h:130
#14 0x0047571c in Upp::Iml::~Iml (this=0x91e9f4) at Image.h:252
#15 0x002ae584 in __tcf_0 () at iml_source.h:54
#16 0x00003a44 in cxa_atexit_wrapper ()
#17 0x9001455c in __cxa_finalize ()
#18 0x90014444 in exit ()
#19 0x00002c58 in _start ()
#20 0x00002958 in start ()


But all files are saved correctly, so again, no impact, just not "clean". I used File/Exit there, but same happens when you push Close X-icon.

Re: MacOS X woes [message #7301 is a reply to message #7299] Thu, 21 December 2006 04:29 Go to previous messageGo to next message
lundman is currently offline  lundman
Messages: 175
Registered: March 2006
Location: Tokyo
Experienced Member

Bored at work, so I looked at it. Reason it complains, is that Xdisplay is NULL, presumably already been freed.

I changed the code to
void Image::Data::SysRelease()
{
    if(picture) {
        if(Xdisplay) XRenderFreePicture(Xdisplay, picture);
        ResCount -= !paintonly;
        picture = 0;
    }
    if(picture8) {
        if (Xdisplay) XRenderFreePicture(Xdisplay, picture8);


And now I get:

Program exited normally.

So that is something. Might not be the proper fix though.

Re: MacOS X woes [message #7308 is a reply to message #7301] Thu, 21 December 2006 14:05 Go to previous messageGo to next message
lundman is currently offline  lundman
Messages: 175
Registered: March 2006
Location: Tokyo
Experienced Member

I sent a binary of my app to a colleague to check and we found an interesting problem. It does not start up, but spins forever, ktrace tells us it is in:

11119 UFxp     CALL  open(0xe521f4,0,0) 
11119 UFxp     NAMI  "libgtk-x11-2.0.so" 11119 UFxp     RET   open -1 errno 2 No such file or directory 
11119 UFxp     CALL  close(0xffffffff) 
11119 UFxp     RET   close -1 errno 9 Bad file descriptor 
11119 UFxp     CALL  open(0xbfffefa0,0,0)
11119 UFxp     NAMI  "libgtk-x11-2.0.so.36" 
11119 UFxp     RET   open -1 errno 2 No such file or directory


Which is interesting, since it isn't linked against those libraries the usual way. I assume then that you use dynamic library load at run time, and perhaps does not deal with the error as well as one would hope? What should normally happen on failure to open a library?

Lund
Re: MacOS X woes [message #7316 is a reply to message #7308] Thu, 21 December 2006 21:25 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
U++ tries to dlopen gtk libraries to use it for theming widgets.

If that fails, "standard" look is used.

Mirek
Re: MacOS X woes [message #7325 is a reply to message #7316] Fri, 22 December 2006 12:34 Go to previous messageGo to next message
lundman is currently offline  lundman
Messages: 175
Registered: March 2006
Location: Tokyo
Experienced Member

Ok, I will try with the latest build to see if it still happens, that was a 605 build.

I will hold off on 612-dev2 as it doesn't have all the OsX changes, and stay with the -current versions for now.

Re: MacOS X woes [message #7335 is a reply to message #7325] Fri, 22 December 2006 19:09 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Applied all changes EXCEPT bmphdr, which does not make a sense to me... (casting word reference to word reference?!).

But maybe it was just old version.

Mirek
Re: MacOS X woes [message #7340 is a reply to message #7335] Sat, 23 December 2006 04:43 Go to previous messageGo to next message
lundman is currently offline  lundman
Messages: 175
Registered: March 2006
Location: Tokyo
Experienced Member
Thank you! Synced and trying... You forgot the Color.h changes for RGBA.

Compiling we get:


Bmp.cpp
/Users/lundman/src/upp/uppsrc/plugin/bmp/bmphdr.h: In member function 'void Upp::BMP_FILEHEADER::SwapEndian()':
/Users/lundman/src/upp/uppsrc/plugin/bmp/bmphdr.h:18: error: cannot bind packed field '((Upp::BMP_FILEHEADER*)this)->Upp::BMP_FILEHEADER::
        bfType' to 'Upp::word&'
/Users/lundman/src/upp/uppsrc/plugin/bmp/bmphdr.h:19: error: cannot bind packed field '((Upp::BMP_FILEHEADER*)this)->Upp::BMP_FILEHEADER::
        bfSize' to 'Upp::dword&'

[snip]


Which I can "fix" by casting it (lets me compile it at least)

Later on I get:

uppsrc/CtrlCore/Win32Proc.cpp:3:20 error winnls.h: No such file or directory


I assume it is just too high up, actually its included twice, so I just removed the top one.

Install.cpp
/Users/lundman/src/upp/uppsrc/ide/Install.cpp: In member function 'void XInstallDlg::FindInstFolder()':
/Users/lundman/src/upp/uppsrc/ide/Install.cpp:267: error: 'path' was not declared in this scope
/Users/lundman/src/upp/uppsrc/ide/Install.cpp: In constructor 'XInstallDlg::XInstallDlg()':
/Users/lundman/src/upp/uppsrc/ide/Install.cpp:280: error: 'tutorial' was not declared in this scope
/Users/lundman/src/upp/uppsrc/ide/Install.cpp:281: error: 'path' was not declared in this scope
/Users/lundman/src/upp/uppsrc/ide/Install.cpp: In function 'bool Install()':
/Users/lundman/src/upp/uppsrc/ide/Install.cpp:304: error: 'struct XInstallDlg' has no member named 'path'
/Users/lundman/src/upp/uppsrc/ide/Install.cpp:311: error: 'struct XInstallDlg' has no member named 'path'
/Users/lundman/src/upp/uppsrc/ide/Install.cpp:346: error: 'struct XInstallDlg' has no member named 'tutorial'
ide: 1 file(s) built in (0:04.97), 4977 msecs / file, duration = 5748 msecs



Apart from that, builds.

Re: MacOS X woes [message #7342 is a reply to message #7340] Sat, 23 December 2006 09:03 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
lundman wrote on Fri, 22 December 2006 22:43

Thank you! Synced and trying... You forgot the Color.h changes for RGBA.



You forgot to send the file Smile


Quote:


/Users/lundman/src/upp/uppsrc/plugin/bmp/bmphdr.h:18: error: cannot bind packed field '((Upp::BMP_FILEHEADER*)this)->Upp::BMP_FILEHEADER::
bfType' to 'Upp::word&'



Ahh, "packed field" rings the bell - it treats the __atrribute__(packed) using bit fields! Which makes your fix most likely wrong. Tried to fix (by adding SwapEndian functions which operate with value input and value return).

If it compiles, please try to load some .bmp files - there is nice examples/ImageView.

Quote:


Later on I get:

uppsrc/CtrlCore/Win32Proc.cpp:3:20 error winnls.h: No such file or directory


I assume it is just too high up, actually its included twice, so I just removed the top one.



Fixed.

Quote:


Install.cpp
/Users/lundman/src/upp/uppsrc/ide/Install.cpp: In member function 'void XInstallDlg::FindInstFolder()':
/Users/lundman/src/upp/uppsrc/ide/Install.cpp:267: error: 'path' was not declared in this scope




Interesting. path should be defined in ide.lay.

Mirek
Re: MacOS X woes [message #7351 is a reply to message #7342] Sat, 23 December 2006 10:58 Go to previous messageGo to previous message
lundman is currently offline  lundman
Messages: 175
Registered: March 2006
Location: Tokyo
Experienced Member
It was your fix Smile
Color.h:
#ifdef PLATFORM_WIN32
struct RGBA : Moveable<RGBA> {
        byte b, g, r, a;
};
#endif

#ifdef PLATFORM_POSIX
#ifdef CPU_BE
struct RGBA : Moveable<RGBA> {
        byte a, r, g, b;
};
#else
struct RGBA : Moveable<RGBA> {
        byte b, g, r, a;
};
#endif
#endif

#ifndef PLATFORM_WIN32



"path" is defined in .lay, I checked, but it just doesn't want to compile Smile



bmphdr (looks like no change):
/Users/lundman/src/upp/uppsrc/plugin/bmp/bmphdr.h: In member function 'void Upp::BMP_FILEHEADER::SwapEndian()':
/Users/lundman/src/upp/uppsrc/plugin/bmp/bmphdr.h:18: error: no matching function for call to 'Upp::BMP_FILEHEADER::SwapEndian(Upp::word&)
        '
/Users/lundman/src/upp/uppsrc/plugin/bmp/bmphdr.h:15: note: candidates are: void Upp::BMP_FILEHEADER::SwapEndian()
/Users/lundman/src/upp/uppsrc/plugin/bmp/bmphdr.h:19: error: no matching function for call to 'Upp::BMP_FILEHEADER::SwapEndian(Upp::dword&
        )'

etc






Next Topic: 701-dev1 / 2007.1beta on Mac OSX
Goto Forum:
  


Current Time: Fri Mar 29 11:19:39 CET 2024

Total time taken to generate the page: 0.01278 seconds