Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
New Mac OS X (PPC/10.3) build
afb:
--- Quote from: Pecan on September 16, 2006, 02:33:45 pm ---
--- Quote ---* contrib mac - http://developer.berlios.de/patch/?func=detailpatch&patch_id=1424&group_id=5358
--- End quote ---
You've submitted fixes to berlios for which you have submitted no bug reports or discussion. I don't seem to need these patches to either compile or run the contribs on my mac ppc.
It's possible I've already fixed them and didn't submit a fix, or the fix just got too out of date. For awhile there, I quite submitting fixes for the latter reason.
For this particular contrib fix, however, I can do something about it if you'd indicate the reasons for your fix.
--- End quote ---
I had two incidents in the contribs where it wouldn't link since it was missing symbols that seemed to only be defined in the #ifdef __WXMSW__ or #ifdef __WXGTK__ blocks, so I added stubs/dummy functions to make it link correctly when compiling for __WXMAC__ ?
I'm pretty used to this "if (Windows) else (Linux)" logic by now, so I normally do it without reflecting too much on why it is needed... :-P If it isn't needed anymore, just ignore this patch but at the time it was submitted it wouldn't link with --enable-contrib without it.
afb:
--- Quote ---plugins libs - http://developer.berlios.de/patch/?func=detailpatch&patch_id=1395&group_id=5358
--- End quote ---
The reason to add the WX_LIBS to the plugins was so that it would ./configure && make without giving any extra LDFLAGS, but I think this was described in detail in the comments to the patch ?
afb:
I should also mention that the CodeCompletion plugin makes it hang indefinitely when creating or opening a project, so this was probably a mistake to include in the default installation...
There seems to be another crash when trying to save the settings, so the easiest is probably to just delete the plugin .so itself from the application bundle ("plugins/libcodecompletion.so")
Will try to report all these as bugs, if they aren't entered already.
Pecan:
afb,
I've been compiling SVN CB using the Unicode version of wxWidgets with Mac CodeBlocks for about two months. It's one problem after another.
No problem compiling, that runs fine. It's the executable behavior. For example, a unicode pgm will not accept clipboard input. Some source files load as if empty. I can't find an encoding that works with all the files in a project. etc, etc.
I've decided to give it up and go back to the ansi version.
Could you tell me why you're using the ansi version of wxWidgets. Just for my education.
thanks
pecan
afb:
--- Quote from: Pecan on September 22, 2006, 04:36:43 pm ---I've been compiling SVN CB using the Unicode version of wxWidgets with Mac CodeBlocks for about two months.
--- End quote ---
I'm using "ANSI" for the manual build in /usr/local, and "UNICODE" for the DarwinPorts build in /opt/local...
Mostly because those are the respective defaults, but also since that's one way to test with and compare both...
--- Quote ---It's one problem after another.
No problem compiling, that runs fine. It's the executable behavior. For example, a unicode pgm will not accept clipboard input. Some source files load as if empty. I can't find an encoding that works with all the files in a project. etc, etc.
--- End quote ---
The app is not working very good for me either, especially not the Intel version, but I haven't narrowed it down.
--- Quote ---I've decided to give it up and go back to the ansi version.
Could you tell me why you're using the ansi version of wxWidgets. Just for my education.
--- End quote ---
I am using wxWidgets for the D bindings project, and we haven't finished all Unicode "porting"...
Besides, I've found the "ANSI" version to be less buggy on Mac and Win but that could be just me.
Navigation
[0] Message Index
[*] Previous page
Go to full version