U++ forum: Welcome to the forum

Search on this site

Search in forums

Home » Developing U++ » Mac OS » MacOS X woes

Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend

Re: MacOS X woes [message #7281 is a reply to message #7280]

Wed, 20 December 2006 04:44

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

Report message to a moderator

Re: MacOS X woes [message #7282 is a reply to message #7281]

Wed, 20 December 2006 05:01

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

mirek
Messages: 14271
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

Report message to a moderator

Re: MacOS X woes [message #7284 is a reply to message #7227]

Wed, 20 December 2006 08:57

mirek
Messages: 14271
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

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?

Report message to a moderator

Re: MacOS X woes [message #7286 is a reply to message #7285]

Wed, 20 December 2006 09:29

mirek
Messages: 14271
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

Report message to a moderator

Re: MacOS X woes [message #7287 is a reply to message #7286]

Wed, 20 December 2006 09:50

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?

Report message to a moderator

Re: MacOS X woes [message #7288 is a reply to message #7287]

Wed, 20 December 2006 09:59

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?

Report message to a moderator

Re: MacOS X woes [message #7289 is a reply to message #7288]

Wed, 20 December 2006 10:50

mirek
Messages: 14271
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

Report message to a moderator

Re: MacOS X woes [message #7291 is a reply to message #7289]

Wed, 20 December 2006 13:23

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)

Report message to a moderator

Re: MacOS X woes [message #7292 is a reply to message #7291]

Wed, 20 December 2006 16:06

mirek
Messages: 14271
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

Report message to a moderator

Re: MacOS X woes [message #7299 is a reply to message #7292]

Thu, 21 December 2006 02:21

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.

Attachment: osx_changes.zip
(Size: 16.63KB, Downloaded 569 times)

Report message to a moderator

Re: MacOS X woes [message #7301 is a reply to message #7299]

Thu, 21 December 2006 04:29

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.

Report message to a moderator

Re: MacOS X woes [message #7308 is a reply to message #7301]

Thu, 21 December 2006 14:05

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

Report message to a moderator

Re: MacOS X woes [message #7316 is a reply to message #7308]

Thu, 21 December 2006 21:25

mirek
Messages: 14271
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

Report message to a moderator

Re: MacOS X woes [message #7325 is a reply to message #7316]

Fri, 22 December 2006 12:34

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.

Report message to a moderator

Re: MacOS X woes [message #7335 is a reply to message #7325]

Fri, 22 December 2006 19:09

mirek
Messages: 14271
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

Report message to a moderator

Re: MacOS X woes [message #7340 is a reply to message #7335]

Sat, 23 December 2006 04:43

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.

Report message to a moderator

Re: MacOS X woes [message #7342 is a reply to message #7340]

Sat, 23 December 2006 09:03

mirek
Messages: 14271
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

Report message to a moderator

Re: MacOS X woes [message #7351 is a reply to message #7342]

Sat, 23 December 2006 10:58

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

Report message to a moderator

Pages (3): [ « ‹ 1 2 3 › »]

Next Topic:

701-dev1 / 2007.1beta on Mac OSX

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

]

Current Time: Tue Nov 04 16:05:28 CET 2025

Total time taken to generate the page: 0.07220 seconds