Re: MacOS X building instructions
Quote:
Originally Posted by
gpetty
The resulting executable is huge: 784 MB.
The executable is huge because it contains debug info. I was hoping that the latest Mac gcc compilers would use DWARF and the debug info would take up less space, but it looks as if one of my assumptions is wrong somewhere. I too have a have binary of about that size - probably over 800 MB actually, which I use for debugging, and strip to fit on a CD.
Quote:
Originally Posted by
gpetty
... it definitely halts when it can't find the one library in /usr/lib, ...
You could look for every configuration file with a path starting /usr/lib and delete those files. The configure system should re-create them with correct paths
Ben
Re: MacOS X building instructions
Quote:
Originally Posted by
gpetty
... I simply clicked on the drawing window, and the program complained about a "very serious error" and said that it would have to close.
This is Bug 935 "APPLICATION CLOSE"
I can post a patch for this tomorrow morning.
Ben.
Re: MacOS X building instructions
Quote:
Originally Posted by
abligh
Harmless
You wrote this in response to my comment about it not finding ImageMagick. But interestingly, that initial failure to find it explains the difference in behavior I got when I started the program from the command line versus opening it via the GUI.
Recall that when I tried to start it from the command line, the program displayed the splash logo and then immediately became unresponsive. It was using the CPU fully and it was failing to quit when asked to do so.
My initial experience opening it via the GUI, on the other hand, was that it opened fine, though it failed to find ImageMagick, and then crashed only when I tried to do something in the drawing window.
I opened it a second time and then closed it without doing anything else in order to create a preferences file, which I then edited to give the path to ImageMagick. I then found that when I opened it again via the GUI, it behaved exactly the same as when I had previously executed it from the command line (for which paths to ImageMagick were defined by my shell).
In other words, it is ImageMagick, most likely convert (since that appeared in the ps listing) that caused Xtreme to hang on start-up. I just thought this behavior might be significant to somebody. Clearly I will have to disable the path to IM again in order to successfully start Xtreme again, unless someone can suggest another fix.
Quote:
It might be better to have this discussion on the dev list (see
http://www.xaraxtreme.org/community/) by the way, there are more Mac folks there. I'm not sure they are a huge amount further forward than you though...
Alex
Since I haven't received the email with registration confirmation for that forum yet (I'm not sure whether a delay is normal or not), I'll just continue posting here for now.
Also, I may have to at least temporarly scale back my efforts to get Xtreme working, because I just discovered, and successfully installed, the package Inkscape, which looks like it might accomplish most of what I was looking for in a drawing package.
Thanks to both Ben and Alex for your efforts on behalf of getting Xtreme running on my Mac ... I'll try to stay tuned for news on this front.
I guess one thing I never found out is whether *anyone* out there has a more or less functioning copy of Xtreme running on an Intel-based Mac?
regards,
Grant
Re: MacOS X building instructions
Quote:
Originally Posted by
gpetty
I [have] just discovered, and successfully installed, the package Inkscape, which looks like it might accomplish most of what I was looking for in a drawing package.
The package Inkscape runs under the X Windows System (the GTK that we heard about earlier), and this does not suit everyone.
Quote:
Originally Posted by
gpetty
I guess one thing I never found out is whether *anyone* out there has a more or less functioning copy of Xtreme running on an Intel-based Mac?
I am fairly sure that I could create a Xara LX deliverable for Mac Intel (UB) in about half a day's work - if I had access to an Intel Mac, but it would likely still be a minefield of various Mac specific problems, so it would be 'more or less' functioning only in the most literal sense of that phrase. I really couldn't advance such a product for doing useful work, but Inkscape is used by thousands of people for diagrams, logos, icons, user interface mock-ups web page mock-ups and all forms of computer art.
I do assure you that that the Linux edition of the Xara LX is held in high regard, and we expect that it only a matter of time and continued effort before the Mac version reaches parity with it; and of course, your comments and the account of your experiences has indeed been a help and stimulus!
Thank you.
Ben.
Re: MacOS X building instructions
Heya all,
I figured I'd keep this going with my experience, in case someone's listening.
I built Xara without any difficulties at all, first try, by following the XCode instructions on the site. Now, I'm running XCode 2.3 on a PowerBook G4 (1.25 gig of ram) with fink 0.80 and OSX 10.4.7. Because of Blender I also have my gcc set to v3.3; this might make a difference.
Anyway, compiled fine with very few issues; the biggest problem was that I ran out of hard disk space. (After building, the total size of all compiled object files and the executable is 1.84 gig. That's insane.) Lemme hit you up with a few screen shots:
http://ministryofdoom.org/cloud/xara...25/splash1.jpg
http://ministryofdoom.org/cloud/xara...n-windows1.jpg
http://ministryofdoom.org/cloud/xara...lock-file1.jpg
First run was much as stated above -- I got windows, and the menus are built, but Xara->About did nothing and any attempt to use a tool caused a crash. On reload of the program I got the lock file message above. I tried deleting the .xara-xtreme folder and restarting, but that didn't seem to have any effect.
I get the imagemagick error on every load, but I only got the font error on first load. Also, I'd like to attach the console output:
Code:
[Debug] 21:09:58: Launching: convert
[Debug] 21:09:58: wxMacExecute Bad bundle: convert
[Debug] 21:09:58: pid=22040
[Debug] 21:09:58: no task_for_pid()
[Debug] 21:09:58: Process ended
[Debug] 21:10:30: Unrecognized accel key 'NUMPAD 1', accel string ignored.
[Debug] 21:10:30: Unrecognized accel key 'NUMPAD 1', accel string ignored.
[Debug] 21:10:30: Unrecognized accel key 'NUMPAD .', accel string ignored.
[Debug] 21:10:30: Unrecognized accel key 'NUMPAD 2', accel string ignored.
[Debug] 21:10:30: Unrecognized accel key 'NUMPAD 2', accel string ignored.
[Debug] 21:10:30: Unrecognized accel key 'NUMPAD *', accel string ignored.
[Debug] 21:10:55: ../src/mac/carbon/bitmap.cpp(229): assert "m_rawAccessCount == 0" failed.
[Debug] 21:22:56: Launching: convert
[Debug] 21:22:56: wxMacExecute Bad bundle: convert
[Debug] 21:22:56: pid=22047
[Debug] 21:22:56: Successfully added notification to the runloop
[Debug] 21:22:56: Process ended
[Debug] 21:23:47: Launching: convert
[Debug] 21:23:47: wxMacExecute Bad bundle: convert
[Debug] 21:23:47: pid=22057
[Debug] 21:23:47: Successfully added notification to the runloop
[Debug] 21:24:36: Process ended
Aug 25 21:24:36 starbuck crashdump[22058]: XaraLX crashed
Aug 25 21:24:38 starbuck crashdump[22058]: crash report written to: /Users/*****/Library/Logs/CrashReporter/XaraLX.crash.log
Some of that's repeated from multiple launches. The thing eating up all processor cycles seems to be the crash reporter; let it run long enough and Xara crashes properly, with the log written out. For the curious the log from the above is available at http://ministryofdoom.org/cloud/xara....crash.log.zip -- wasn't sure if people wanted me attaching it here.
Things about the build that I noticed right off the bat:
- Two windows -- wxWindows is attempting to set up an MDI interface which is basically not possible / not preferred on the Mac. Once it stops crashing and starts displaying icons that's the first thing that needs to be fixed.
- The icons -- is that part of the endian troubles that were mentioned? I thought I'd read that the icons are 32-bit .png files, in which case endian troubles don't make any sense. (I've compiled the same code using libpng on both PC and Mac and run across no problems.) Unless the icons are put into those .xar files? I haven't really given it more than a five-minute look.
- The splash screen says Linux Edition. Mac version should say Mac Edition, in my opinion. (I won't go into how the color scheme makes me think of the good old CGA days, either. ^_^; )
Anyway, I'd like to play with it more. Where's a good place to start for Mac folks? Are there any code primers?
~ Charles
Re: MacOS X building instructions
Quote:
Originally Posted by
kattkieru
Heya all,
I figured I'd keep this going with my experience, in case someone's listening.
I built Xara without any difficulties at all, first try, by following the XCode instructions on the site. Now, I'm running XCode 2.3 on a PowerBook G4 (1.25 gig of ram) with fink 0.80 and OSX 10.4.7. Because of Blender I also have my gcc set to v3.3; this might make a difference.
Great! It should compile with gcc 3.3 and gcc 4.x just fine.
Quote:
Originally Posted by
kattkieru
Heya all,
First run was much as stated above -- I got windows, and the menus are built, but Xara->About did nothing and any attempt to use a tool caused a crash. On reload of the program I got the lock file message above. I tried deleting the .xara-xtreme folder and restarting, but that didn't seem to have any effect.
Don't worry about the lockfile message (that's probably rerunning the program). Ditto the ImageMagick message is harmless (except to the extent you want more import filters).
If it locks up when you use a tool, that's normally a symptom of not running from the package.
Quote:
Originally Posted by
kattkieru
Heya all,
[Debug] 21:09:58: Launching: convert
[Debug] 21:09:58: wxMacExecute Bad bundle: convert
OK so that sounds like the source of the ImageMagick problem. I wonder why wxMacExecute needs convert to be a bundle.
Quote:
Originally Posted by
kattkieru
Heya all,
Things about the build that I noticed right off the bat:
- Two windows -- wxWindows is attempting to set up an MDI interface which is basically not possible / not preferred on the Mac. Once it stops crashing and starts displaying icons that's the first thing that needs to be fixed.
It does whatever wxWidgets does with a wxMDIWindow on the Mac (at the moment). This isn't intended to be a permanent proposition...
Quote:
Originally Posted by
kattkieru
Heya all,
- The icons -- is that part of the endian troubles that were mentioned? I thought I'd read that the icons are 32-bit .png files, in which case endian troubles don't make any sense. (I've compiled the same code using libpng on both PC and Mac and run across no problems.) Unless the icons are put into those .xar files? I haven't really given it more than a five-minute look.
Yes that's odd, especially as other people have got the icons working on the Mac.
What happens is a script called buildresources.pl is run which makes a zip file (called "resources.xrs") containing all the png files. This is then converted to an .h file (don't ask) with an array of all the bytes in the zip file and bound into the executable. wxWidgets contains a VFS like thing (wxFileSystem) which can be used to load files from it. Somewhere or other this process is failing. However, the resource file itself is clearly being build OK, because the xrc (XML) for the bar definitions is in there (also loaded through the wxFileSystem) as are the strings. Somewhere or other the bitmaps (only) are failing to load. The relevant file is wxOil/camresource.cpp if you want a poke around.
Quote:
Originally Posted by
kattkieru
Heya all,
- The splash screen says Linux Edition. Mac version should say Mac Edition, in my opinion. (I won't go into how the color scheme makes me think of the good old CGA days, either. ^_^; )
Right now it says Linux Edition even if it's run on FreeBSD. That's just a matter of putting in a different bitmap.
Quote:
Originally Posted by
kattkieru
Heya all,
Anyway, I'd like to play with it more. Where's a good place to start for Mac folks? Are there any code primers?
www.xaraxtreme.org and look at the "Developers" section. If you are debugging bitmap loading, look specifically at the section marked "Resource System". Also, the -dev mailing list is pretty friendly.
Alex
Re: MacOS X building instructions
Quote:
Originally Posted by
abligh
OK so that sounds like the source of the ImageMagick problem. I wonder why wxMacExecute needs convert to be a bundle.
Yeah, I have 6.18 installed with Fink, but I haven't gone and tried to get the two working yet.
You mentioned bundles -- I ran the executable outside the bundle. Trying to run it from within the bundle simply didn't work.
Quote:
It does whatever wxWidgets does with a wxMDIWindow on the Mac (at the moment). This isn't intended to be a permanent proposition...
I hope I didn't sound rude; I sometimes come off as more acidic than I intend over text. I just mean that the Mac will need its own set of rules for that, as MDI is the one thing that doesn't port. Photoshop's a good example-- MDI on PC, but it uses those... weird window types (the ones that are only visible when the program has focus, I forget the name right now) for everything else.
I also assume that the people behind Xara already know this. ^_^;
Quote:
Yes that's odd, especially as other people have got the icons working on the Mac. What happens is a script called buildresources.pl is run which makes a zip file (called "resources.xrs") containing all the png files. This is then converted to an .h file (don't ask) with an array of all the bytes in the zip file and bound into the executable. wxWidgets contains a VFS like thing (wxFileSystem) which can be used to load files from it. Somewhere or other this process is failing. However, the resource file itself is clearly being build OK, because the xrc (XML) for the bar definitions is in there (also loaded through the wxFileSystem) as are the strings. Somewhere or other the bitmaps (only) are failing to load. The relevant file is wxOil/camresource.cpp if you want a poke around.
That's really interesting... Stranger still, I changed PRELOAD_BITMAPS to 1 in cameresource.cpp and the program now loads and exits properly. I also seem to have some icons loading:
http://ministryofdoom.org/cloud/xara...ome-icons1.jpg
I get the message "No handler found for image type" twice now on each startup; that's a new one.
If I mouseover the icons, the icons appear perfectly, though. That wasn't the case before, so for whatever reason the issue is in the generation of those grey icons.
I'm going to keep playing. One more note that should be added to the Mac notes -- the project file comes with ZeroLink turned off, and turning it on actually seems to make the program load faster.
Oh, now that the debugger is loaded, the crash when clicking on the canvas comes from wxWindowBase::ScreenToClient(), at DoScreenToClient(). I think I'll leave that one alone for a moment; if you don't click, the program allows a graceful exit.
If you crash the program out, on subsequent reloads it always crashes in CCamApp::HandleKeyPress (camelot.cpp line 1311). This continues happening until you either relink the program or close and reopen XCode. I think it also happens when you hit run, but then switch immediately to another program before Xara has a chance to load.
Oh, and since you're the same Alex who wrote this code, I can't thank you enough for how beautiful and well-commented it is. This is the first time, ever, for me where I downloaded an open-source project and was able to step through the program flow without some sort of Rosetta stone. (Especially one written by a commercial software vendor.) Kudos! A lot of it's over my head, and I've only used wxWindows once before, but it's still very followable with grep and a cup of coffee. ^_^
Re: MacOS X building instructions
Quote:
Originally Posted by
gpetty
You wrote this in response to my comment about it not finding ImageMagick. But interestingly, that initial failure to find it explains the difference in behavior I got when I started the program from the command line versus opening it via the GUI.
...
I opened it a second time and then closed it without doing anything else in order to create a preferences file, which I then edited to give the path to ImageMagick. I then found that when I opened it again via the GUI, it behaved exactly the same as when I had previously executed it from the command line (for which paths to ImageMagick were defined by my shell).
If that is the case, there is a preference to disable ImageMagick (ImageMagickDisable in the Filters section) that will stop it looking for ImageMagick.
Alex
Re: MacOS X building instructions
Anyone have an executable file for mac yet? I would love to try out what is done so far but am not very experienced with code stuff. Thanks.
Re: MacOS X building instructions
Code:
/usr/bin/ld: Undefined symbols:
CBrushEditDlg::Init()
CNameBrushDlg::Init()
OpSelectBrush::Declare()
CInitBrushNameDlg::Init()
OpDeactivateBrush::Declare()
OpChangeBrushDefinition::Declare()
CBrushEditDlg::GetState(String_256*, OpDescriptor*)
/Users/Kyle/Desktop/XaraLX/builddebug/XaraLX.build/Development/XaraLX_Debug.build/Objects-normal/i386/main2.o reference to undefined CBrushEditDlg::Init()
/Users/Kyle/Desktop/XaraLX/builddebug/XaraLX.build/Development/XaraLX_Debug.build/Objects-normal/i386/main2.o reference to undefined CNameBrushDlg::Init()
/Users/Kyle/Desktop/XaraLX/builddebug/XaraLX.build/Development/XaraLX_Debug.build/Objects-normal/i386/main2.o reference to undefined OpSelectBrush::Declare()
/Users/Kyle/Desktop/XaraLX/builddebug/XaraLX.build/Development/XaraLX_Debug.build/Objects-normal/i386/main2.o reference to undefined CInitBrushNameDlg::Init()
/Users/Kyle/Desktop/XaraLX/builddebug/XaraLX.build/Development/XaraLX_Debug.build/Objects-normal/i386/main2.o reference to undefined OpDeactivateBrush::Declare()
/Users/Kyle/Desktop/XaraLX/builddebug/XaraLX.build/Development/XaraLX_Debug.build/Objects-normal/i386/main2.o reference to undefined OpChangeBrushDefinition::Declare()
/Users/Kyle/Desktop/XaraLX/builddebug/XaraLX.build/Development/XaraLX_Debug.build/Objects-normal/i386/freeinfo.o reference to undefined CBrushEditDlg::GetState(String_256*, OpDescriptor*)
collect2: ld returned 1 exit status
This is the error I get when compiling. I am sure it is pretty easy t fix but I have no idea what I am doing when it comes to Xcode. If anyone knows how to fix this error, please let me know how.
If someone can send me the executable or tell me how to fix this build error, I will go ahead and host it for everyone.
If I forget to come back to this thread, my email is daykyle (at) gmail (dot) com