Code::Blocks

Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => Topic started by: afb on February 20, 2006, 07:47:26 pm

Title: Mac Binaries
Post by: afb on February 20, 2006, 07:47:26 pm
Not that it looks like much at the moment,
but I have a Mac OS X binary of rev. 2040:

 19M    CodeBlocks.app (unpacked, that is)

It has wxWidgets and wxscintilla libraries inside,
so it should be all self-contained and relocatable.

6.7M    CodeBlocks-2040.zip

Is there any place to put it ? (and how I made it)
Don't have the disk space and bandwidth myself.


Asking now, since there'll probably be more later...
(will help with listing all the "issues" on Mac OS X)
Title: Re: Mac Binaries
Post by: takeshi miya on February 21, 2006, 09:11:41 am
Is there any place to put it ? (and how I made it)
Don't have the disk space and bandwidth myself.

AFAIK, Berlios, but it has been with lot's of downtimes lately. Better than nothing at least.
I think you can be the official mantainer for MacOS X port, as there's a lack of Apples. :P
And the specific bugs with MacOS X could be assigned to you, if you want.

Just a question: it's an Universal binary?

Regards,
Takeshi Miya
Title: Re: Mac Binaries
Post by: afb on February 21, 2006, 09:18:27 am
Just a question: it's an Universal binary?

Nope, it's for Mac OS X 10.3 and a PPC build.
Title: Re: Mac Binaries
Post by: afb on February 21, 2006, 09:20:20 am
Quote from: Takeshi Miya
I think you can be the official mantainer for MacOS X port, as there's a lack of Apples. :P
And the specific bugs with MacOS X could be assigned to you, if you want.

I'm happy to help, but don't have the time to be an official maintainer. Thanks :)
Title: Re: Mac Binaries
Post by: takeshi miya on February 21, 2006, 09:29:37 am
I'm happy to help, but don't have the time to be an official maintainer. Thanks :)

No problem, just spread the word. :)
Title: Re: Mac Binaries
Post by: mandrav on February 21, 2006, 09:30:41 am
6.7M    CodeBlocks-2040.zip

Is there any place to put it ? (and how I made it)
Don't have the disk space and bandwidth myself.

Rename it to something more descriptive.
codeblocks-r2040_ppc.zip would be fine.

Then upload it (anonymous ftp) to ftp.berlios.de/incoming and notify me so that I can put it in the project's file release system.

Thanks a lot for this contribution :)
Title: Re: Mac Binaries
Post by: afb on February 21, 2006, 09:45:51 am
Uploaded it as:
codeblocks-rev2040_macppc.zip

Users will need to have the Xcode Tools installed, to get GCC and Make and so on...
But those come with the system and as a free download so it shouldn't be a problem.
Title: Re: Mac Binaries
Post by: mandrav on February 21, 2006, 09:52:11 am
Uploaded it as:
codeblocks-rev2040_macppc.zip

Users will need to have the Xcode Tools installed, to get GCC and Make and so on...
But those come with the system and as a free download so it shouldn't be a problem.


Thanks, the results are here (https://developer.berlios.de/project/showfiles.php?group_id=5358) :)
Title: Re: Mac Binaries
Post by: afb on February 21, 2006, 09:58:49 am
Cool.

Now all that needs to be done is fix the bugs :-)
(as it looks kind of terrible, at the moment...)

The nice part is that if you are able to navigate
past the broken notebooks, it did compile alright.


Will post some bloggish building details on:
http://www.algonet.se/~afb/wx/codeblocks.html

And perhaps write it on the Wiki, if in public interest.
(code things should come in the way of patches, tho)
Title: Re: Mac Binaries
Post by: mandrav on February 21, 2006, 10:06:24 am
I suggest using the wiki. It would be the first place (together with these forums) someone would look for info.
Title: Re: Mac Binaries
Post by: afb on February 21, 2006, 10:23:03 am
Will use the wiki.codeblocks.org, if I can figure out how to register...

Or do I need an account created for me by the adminstrators first ?
Title: Re: Mac Binaries
Post by: mandrav on February 21, 2006, 10:36:14 am
Or do I need an account created for me by the adminstrators first ?

Because of spammers, an admin must create your account.
You 've got PM ;)
Title: Re: Mac Binaries
Post by: afb on February 21, 2006, 11:07:00 am
A stub is now up at:
http://wiki.codeblocks.org/index.php?title=Compiling_Code::Blocks_in_Mac_OS_X

Will migrate some more info to it from my own pages and from the forum,
but it will have to wait until lunchtime or tonight even. Got work to do... :-)
Title: Re: Mac Binaries
Post by: Trikko on March 09, 2006, 09:29:59 am
Read this!!

http://forums.codeblocks.org/index.php?topic=2582.msg20477#msg20477
Title: Re: Mac Binaries
Post by: afb on March 09, 2006, 09:35:13 am
Read this!!

Yes, I have patched wxAUI. No, it doesn't work fully anyway.
Those changes should be released with 0.9.2, so it's all good.

Getting other crashes now, with latest Code::Blocks SVN,
so it has been a while since the last "working" Mac build...
Title: Re: Mac Binaries
Post by: Pecan on April 01, 2006, 11:22:55 pm
In the wiki "Compiling Code::Blocks in Mac OS X" it states
that the user has to install Xcode Tools from http://developer.apple.com/tools/.

Yet I can find no xtools to download that will run on any system other than
OS X 10.4. It states that Xtools 2.2 will run on no earlier OS X system. And,
evidently, apple has hidden any earlier versions of the tools.

Yet the wiki also says that this (wiki) system has been tested on OS X 10.3.

To follow these instructions, where can we find a version of Xtools
(or the necessary apple tools) that will work on OS X earlier than 10.4 (tiger)
and allow us to build CB?

thanks
pecan
Title: Re: Mac Binaries
Post by: afb on April 02, 2006, 09:53:14 am
In the wiki "Compiling Code::Blocks in Mac OS X" it states
that the user has to install Xcode Tools from http://developer.apple.com/tools/.

Yet I can find no xtools to download that will run on any system other than
OS X 10.4. It states that Xtools 2.2 will run on no earlier OS X system. And,
evidently, apple has hidden any earlier versions of the tools.

Apple pulled all the old links in order to promote Mac OS X 10.4, but all the
old developer tools can be downloaded from ADC at http://connect.apple.com/

You need a (free) developer registration with Apple first, in order to log in there.
For Mac OS X 10.3, you want Xcode 1.5. For Mac OS X 10.1-10.2, latest Dev Tools.
Title: Re: Mac Binaries
Post by: Pecan on April 02, 2006, 02:22:02 pm

Apple pulled all the old links in order to promote Mac OS X 10.4, but all the
old developer tools can be downloaded from ADC at http://connect.apple.com/

You need a (free) developer registration with Apple first, in order to log in there.
For Mac OS X 10.3, you want Xcode 1.5. For Mac OS X 10.1-10.2, latest Dev Tools.


Thanks, getting it!

I'm off to downloading at 48k/sec light speed for 31 hrs.
Half the time of the Ubunto download though.

thanks
pecan
Title: Re: Mac Binaries
Post by: Mithos on April 13, 2006, 04:20:02 am
I did made a Mac OS version also. But since I made a full package including many things (basicaly many things not needed) It it too big to distribute right now. But it is the last svn source and has not many visual bugs that I could find. The only major problem is the debugger witch isnīt working yet.

Title: Re: Mac Binaries
Post by: afb on April 13, 2006, 08:24:46 am
I did made a Mac OS version also. But since I made a full package including many things (basicaly many things not needed) It it too big to distribute right now. But it is the last svn source and has not many visual bugs that I could find. The only major problem is the debugger witch isnīt working yet.

Sounds good! (you could always post a screenshot?)

Did you have to make many new modifications ?
And which version of wxWidgets were you using ?

Trying to build the 2341 revision here right now.
Title: Re: Mac Binaries
Post by: Mithos on April 14, 2006, 04:22:03 am
Version 2.6.3

Not big modifications but I had to suffer a little to get all the right libs on 10.3 witch is my os.

Screen Shots I could post if I had installed any image manipulation programs in this machine. I will fix this in the next days and post one
Title: Re: Mac Binaries
Post by: Mithos on April 14, 2006, 06:39:45 am
HA I made the compiler work .... hehehehehe just a small adjustment was needed (mac gdb needs run instead of start) and now it works...

Well havenīt checked all windows in compiler but at least the basic works. Code blocks running smooth in MacOS :-)
Title: Re: Mac Binaries
Post by: mandrav on April 14, 2006, 08:58:52 am
Code blocks running smooth in MacOS :-)

Great!
And the patch is... where? :lol:
Title: Re: Mac Binaries
Post by: Mithos on April 14, 2006, 05:49:10 pm
Bascialy what you need is this change in src/plugins/debuggergdb/gdb_driver.cpp

change
Code: [Select]
#ifdef __WXMSW__
    m_BreakOnEntry = false;
    m_ManualBreakOnEntry = false;
    // start the process
    QueueCommand(new DebuggerCmd(this, _T("run")));
#else
    m_BreakOnEntry = breakOnEntry;
    m_ManualBreakOnEntry = true;
    // start the process
    QueueCommand(new DebuggerCmd(this, _T("start")));
#endif


for this

Code: [Select]
#ifdef __WXMSW__
    m_BreakOnEntry = false;
    m_ManualBreakOnEntry = false;
    // start the process
    QueueCommand(new DebuggerCmd(this, _T("run")));
#else

#ifdef __WXMAC__
    m_BreakOnEntry = false;
    m_ManualBreakOnEntry = false;
    // start the process
    QueueCommand(new DebuggerCmd(this, _T("run")));
#else
    m_BreakOnEntry = breakOnEntry;
    m_ManualBreakOnEntry = true;
    // start the process
    QueueCommand(new DebuggerCmd(this, _T("start")));
#endif
#endif
Title: Re: Mac Binaries
Post by: Mithos on April 14, 2006, 05:50:50 pm
I can distribute my CodeBlocks.app but it is too big right now. I think because I must have compiled things with -g on.

Wen I have some spare time I can see if I re-compile it for size reduction. Iīm also planing a plugin to create mac aplications directly with default Structure because without it doesnīt work well. But this should be simple after I study a little the framework for this.
Title: Re: Mac Binaries
Post by: takeshi miya on April 14, 2006, 06:03:29 pm
Reduced ver.:

Code: [Select]
#if defined (__WXMSW__) || defined (__WXMAC__)
    m_BreakOnEntry = false;
    m_ManualBreakOnEntry = false;
    // start the process
    QueueCommand(new DebuggerCmd(this, _T("run")));
#else
    m_BreakOnEntry = breakOnEntry;
    m_ManualBreakOnEntry = true;
    // start the process
    QueueCommand(new DebuggerCmd(this, _T("start")));
#endif
Title: Re: Mac Binaries
Post by: mandrav on April 14, 2006, 06:49:25 pm
Quote
Bascialy what you need is this change in src/plugins/debuggergdb/gdb_driver.cpp

I wasn't asking about the debugger, but about anything else you had to do to make it work. According to afb's posts, C::B had layout problems in MAC. Have you solved them? Did you do anything special? That's the patch I 'm talking about :)
Title: Re: Mac Binaries
Post by: Mithos on April 14, 2006, 08:31:37 pm
Well I had lotīs of problems to make autoconf and automake works right. But wat I did was basicaly folow what is described on this link and use wxwidgets 2.6.3.


There was some problems with libtool. But basicaly what you need to do is use dynamic libs.


There are some minor problems like the stats on the windows not refreshing right. Those I will try to look better latter but apears to be wxwindows bugs.

It took me something like 3 days to make it work like I wanted. I should have donne somthing like a walk trought with all that was needed. Well if can help anyone latter I will
Title: Re: Mac Binaries
Post by: afb on April 17, 2006, 01:35:06 pm
Well I had lotīs of problems to make autoconf and automake works right. But wat I did was basicaly folow what is described on this link and use wxwidgets 2.6.3.

It still looks "bad" in wx 2.6.1, so I will try upgrading to 2.6.3...

What problems did you have with autoconf/automake/glibtool ?
Beyond the need for a newer version, I didn't have any of those.
Title: Re: Mac Binaries
Post by: Mithos on April 19, 2006, 02:20:43 am
They didnīt reconized some installed features and I had a problem making them build the right dynlib

But just some configuration paramters. And needing to upgrade wasnīt so funny :-)
Title: Re: Mac Binaries
Post by: Pecan on April 25, 2006, 01:14:55 am
I'm trying to compile CB under 10.3

I got the message "you should add the contents of /user/share/aclocal/libtool.m4 to aclocal.m4"

so I concatenated it to /usr/share/libtool/libltdl/aclocal.m4
It's the only aclocal I could find on my mac.

Now I get the messages:
Code: [Select]
iMacG3:~/devel/mac/trunk pecan$ glibtoolize --force --copy &&  aclocal-1.7 &&  autoheader &&  automake-1.7 --include-deps --add-missing --foreigh --copy &&  autoconf
You should update your `aclocal.m4' by running aclocal.
autoheader: error: AC_CONFIG_HEADERS not found in configure.in

I entered the command: aclocal
but I  couldn't see that it did anything...

I also entered the command: aclocal-1.7
but still, the error persists

Could anyone tell me what I've done wrong, or how to continue.

thanks
pecan
Title: Re: Mac Binaries
Post by: Pecan on April 25, 2006, 02:24:12 am
Ok, I got pass the aclocal.m4 problem by concatenating to the aclocal.m4 in
the CodeBlocks trunk directory.

But I still have the follow error:

Code: [Select]
iMacG3:~/devel/mac/trunk pecan$ cp aclocal.m4.all aclocal.m4
iMacG3:~/devel/mac/trunk pecan$ glibtoolize --force --copy &&  aclocal-1.7 &&  autoheader &&  automake-1.7 --include-deps --add-missing --foreigh --copy &&  autoconf
autoheader: error: AC_CONFIG_HEADERS not found in configure.in
iMacG3:~/devel/mac/trunk pecan$

Can anyone suggest a solution?

thanks
pecan
Title: Re: Mac Binaries
Post by: afb on April 25, 2006, 04:40:42 pm
Quote
autoheader: error: AC_CONFIG_HEADERS not found in configure.in

I couldn't duplicate that error here, on my Mac OS X (10.3)
Sorry.

Code: [Select]
# autoheader --version
autoheader (GNU Autoconf) 2.57
Written by Roland McGrath and Akim Demaille.

Copyright 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Title: Re: Mac Binaries
Post by: Pecan on April 25, 2006, 05:36:38 pm
Quote
autoheader: error: AC_CONFIG_HEADERS not found in configure.in

I couldn't duplicate that error here, on my Mac OS X (10.3)
Sorry.


Where on the tree are you executeing these commands. I'm sitting in the trunk folder.
Does that make a difference, Here's what is happening.

Code: [Select]
iMacG3:/volumes/seagate/mac/trunk pecan$ cp ~/devel/mac/temp/aclocal.m4.all aclocal.m4
iMacG3:/volumes/seagate/mac/trunk pecan$ glibtoolize --version
libtoolize (GNU libtool) 1.5

Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
iMacG3:/volumes/seagate/mac/trunk pecan$ autoheader --version
autoheader (GNU Autoconf) 2.57
Written by Roland McGrath and Akim Demaille.

Copyright 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

iMacG3:/volumes/seagate/mac/trunk pecan$ autoconf --version
autoconf (GNU Autoconf) 2.57
Written by David J. MacKenzie and Akim Demaille.

Copyright 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
iMacG3:/volumes/seagate/mac/trunk pecan$ glibtoolize --force --copy
iMacG3:/volumes/seagate/mac/trunk pecan$ aclocal-1.7
iMacG3:/volumes/seagate/mac/trunk pecan$ autoheader
autoheader: error: AC_CONFIG_HEADERS not found in configure.in
iMacG3:/volumes/seagate/mac/trunk pecan$


What's in your configure.in at AC_CONFIG_HEADERS ?
Here is the line from the current configure.in file in CodeBlocks ../trunk

AC_CONFIG_HEADER([src/sdk/config.h])

There is no such file as src/sdk/config.h . Could that be causing the problem?

What version is your glibtoolize?

thanks
pecan
Title: Re: Mac Binaries
Post by: afb on April 25, 2006, 05:52:33 pm
Quote
Where on the tree are you executeing these commands. I'm sitting in the trunk folder.
Yup, same here (rev 2380 now)

Quote
Here is the line from the current configure.in file in CodeBlocks ../trunk

AC_CONFIG_HEADER([src/sdk/config.h])

There is no such file as src/sdk/config.h . Could that be causing the problem?
Nah, it should be created later:
/* src/sdk/config.h.  Generated by configure.  */
/* src/sdk/config.h.in.  Generated from configure.in by autoheader.  */

Quote
What version is your glibtoolize?

Same as yours, 1.5 (standard Apple version)
Title: Re: Mac Binaries
Post by: Pecan on April 25, 2006, 06:39:10 pm
Well... I just can't win this one. Even attempting to download the file
from berlios

[usr]
http://prdownload.berlios.de/codeblocks/codeblocks-rev2040_macppc.zip
[/url]

gets the message:

Code: [Select]
Your are requesting file: /codeblocks/codeblocks-rev2040_macppc.zip
File Doesn't Exist


Title: Re: Mac Binaries
Post by: Pecan on April 25, 2006, 08:55:57 pm
Someone has deleted the mac codeblocks version off berlios
download, but the link is still there.

Is there any way we could get it back so some of us could
jump-start into OS X 10.3?

thanks
pecan
Title: Re: Mac Binaries
Post by: afb on April 25, 2006, 09:08:18 pm
I still have the old binary kicking around, if you want it emailed/uploaded to you ?
Send me a message if so, where to... (6.7M    codeblocks-rev2040_macppc.zip)

Wonder why it was deleted, though ?
(and what will happen to next build)
Title: Re: Mac Binaries
Post by: takeshi miya on April 25, 2006, 10:02:29 pm
It's probably a berlios issue, because the link (at berlios) is still there.
Title: Re: Mac Binaries
Post by: Pecan on April 25, 2006, 10:17:36 pm
I still have the old binary kicking around, if you want it emailed/uploaded to you ?
Send me a message if so, where to... (6.7M    codeblocks-rev2040_macppc.zip)
...

Thanks, Michael uses http://www.savefile.com/ as a free
hosting server. It has a few ads but it works.

Would you consider uploading to there and telling us what
the download name is.

That way, I'll hopefully be able to use it to compile the
current CB.

It seems this problem with autoheader is not uncommon. People
say it's because autoconf scans only the local install folder. So alot of
copying back and forth is necessary. I just dont know what to copy.

Could you also tell us what you're /devel tree looks like. Maybe I've
put wxMac in the wrong place.

thanks
pecan
Title: Re: Mac Binaries
Post by: Pecan on April 28, 2006, 10:50:24 pm
Quote from: afb

I'm not sure you can use it for compiling (?),
but I uploaded the file to SourceForge instead:

http://wxd.sf.net/codeblocks-rev2040_macppc.zip

This is not a permanent location for it, though,
hope BerliOS is working for the next C::B build.

HTH,
--anders



Anders, I received the .app and am attempting to compile CB using the unix.cbp
thanks

I just cannot seem to find the right combo of autoconf-HELL to create a configure.

I noticed there are a few errors in the code using "#ifdef __FreeBSD__".
I've changed them to "#if defined (__FreeBSD__) || defined (__WXMAC__)"

Should I have just defined __FreeBSD__ in the build options and left the code alone, or is adding __WXMAC__  and adding that to the build options appropriate.

thanks
pecan
Title: Re: Mac Binaries
Post by: Pecan on April 29, 2006, 12:29:11 am
While compiling svn source under the afb Mac binary, I'm getting the following error. I'm using the CodeBlocks-unix.cbp

Code: [Select]
Compiling: sdk/wxscintilla/src/scintilla/src/StyleContext.cxx\
Compiling: sdk/wxscintilla/src/scintilla/src/UniConversion.cxx\
Compiling: sdk/wxscintilla/src/scintilla/src/ViewStyle.cxx\
Compiling: sdk/wxscintilla/src/scintilla/src/WindowAccessor.cxx\
Compiling: sdk/wxscintilla/src/scintilla/src/XPM.cxx\
Compiling: sdk/wxscintilla/src/PlatWX.cpp\
Linking dynamic library: devel/libwxscintilla.so\
g++: unrecognized option `-shared'\
ld: Undefined symbols:\

I cannot find "-shared" in the .cbp

Wherever it is, I think I should change it to "-dynamic".
Can anyone tell me where this flag is comming from.

thanks
pecan
Title: Re: Mac Binaries
Post by: mandrav on April 29, 2006, 01:15:14 am
Quote
I cannot find "-shared" in the .cbp

Wherever it is, I think I should change it to "-dynamic".
Can anyone tell me where this flag is comming from.

In advanced compiler options, look inside the "Link DLL" command.
Title: Re: Mac Binaries
Post by: afb on April 29, 2006, 09:51:22 am
I cannot find "-shared" in the .cbp

Wherever it is, I think I should change it to "-dynamic".

For doing plugins, the flag to use is: -bundle
-dynamic is used for .dylib (shared libraries)

On Linux, both of these are using a .so suffix.
Title: Re: Mac Binaries
Post by: Pecan on April 29, 2006, 02:55:49 pm
I cannot find "-shared" in the .cbp

Wherever it is, I think I should change it to "-dynamic".

For doing plugins, the flag to use is: -bundle
-dynamic is used for .dylib (shared libraries)

On Linux, both of these are using a .so suffix.

wxscintilla ends up being a .dll on windows, so I assumed it needed -dynamic on the MAC. 

Is -dynamic correct for wxscintilla ?


EDIT: Oh.. Anders.. will looking inside your .app tell me which flag to use. Could you post your make file, so we could see the options used?

thanks
pecan
Title: Re: Mac Binaries
Post by: afb on April 29, 2006, 02:59:17 pm
scintilla ends up being a .dll on windows, so I assumed it needed -dynamic on the MAC. 

Is -dynamic correct for wxscintilla ?

Sorry for being so confused, -dynamic is correct for libwxscintilla.dylib

-bundle is used for the plugins of C::B, share/codeblocks/plugins
Title: Re: Mac Binaries
Post by: Pecan on April 29, 2006, 03:26:21 pm
scintilla ends up being a .dll on windows, so I assumed it needed -dynamic on the MAC. 

Is -dynamic correct for wxscintilla ?

Sorry for being so confused, -dynamic is correct for libwxscintilla.dylib

-bundle is used for the plugins of C::B, share/codeblocks/plugins

Ok, in that case it would sure be nice to have the .cbp override the compiler option.

Yiannis, how can we put (in the .cbp) -dynamic for core/sdk and -bundle for plugins/contribs ?

thanks
pecan
Title: Re: Mac Binaries
Post by: mandrav on April 29, 2006, 04:18:25 pm
Quote
Yiannis, how can we put (in the .cbp) -dynamic for core/sdk and -bundle for plugins/contribs ?

In the respective targets' other linker options.
Title: Re: Mac Binaries
Post by: Pecan on April 29, 2006, 10:47:43 pm

EDIT: finally figured out I should use libtool on the Mac, not ld
   Will leave this message for the benefit of others.
//----------------------------------------------------------------------

This is the result of compiling scintilla under MAC CodeBlocks with the Linux codeblocks-unix.cbp

Would anyone venture to point me in the direction as to what to do about this?
 
Code: [Select]
g++ -dynamic -Lsdk/tinyxml -L/usr/lib  .objs/sdk/wxscintilla/src/wxscintilla.o .
objs/sdk/wxscintilla/src/ScintillaWX.o .objs/sdk/wxscintilla/src/scintilla/src/A
utoComplete.o .objs/sdk/wxscintilla/src/scintilla/src/CallTip.o .objs/sdk/wxscin
tilla/src/scintilla/src/CellBuffer.o .objs/sdk/wxscintilla/src/scintilla/src/Con
tractionState.o .objs/sdk/wxscintilla/src/scintilla/src/Document.o .objs/sdk/wxs
cintilla/src/scintilla/src/DocumentAccessor.o .objs/sdk/wxscintilla/src/scintill
a/src/Editor.o .objs/sdk/wxscintilla/src/scintilla/src/ExternalLexer.o .objs/sdk
/wxscintilla/src/scintilla/src/Indicator.o .objs/sdk/wxscintilla/src/scintilla/s
rc/KeyMap.o .objs/sdk/wxscintilla/src/scintilla/src/KeyWords.o .objs/sdk/wxscint
illa/src/scintilla/src/LexAPDL.o .objs/sdk/wxscintilla/src/scintilla/src/LexAU3.
o .objs/sdk/wxscintilla/src/scintilla/src/LexAVE.o .objs/sdk/wxscintilla/src/sci
ntilla/src/LexAda.o .objs/sdk/wxscintilla/src/scintilla/src/LexAsm.o .objs/sdk/w
xscintilla/src/scintilla/src/LexAsn1.o .objs/sdk/wxscintilla/sr\
ld: Undefined symbols:\
_main\
Process terminated with status 1 (12 minutes, 37 seconds)\

thanks
pecan

Anders, could you attach your make file to a message here?
thanks
Title: Re: Mac Binaries
Post by: Pecan on April 30, 2006, 02:13:18 am
EDIT: 2006/04/30
This macro error was caused by an editing fault (human or otherwise)
// -----------------------------------------------------------------------

There is an advanced linker option for making dynamic libs in CodeBlocks:
Code: [Select]
$linker -dynamic $libdirs $link_objects $link_resobjects -o $exe_output $link_options  $libslibtooll

For the Mac, I changed $linker to libtool. When running this line against the scintilla target, I get the following:
Code: [Select]
-------------- Build: AutoRevision in Code::Blocks - Unix ---------------
Target is up to date.

-------------- Build: ConsoleRunner in Code::Blocks - Unix ---------------
Target is up to date.

-------------- Build: tinyXML in Code::Blocks - Unix ---------------
Target is up to date.

-------------- Build: AngelScript in Code::Blocks - Unix ---------------
Target is up to date.

-------------- Build: scintilla in Code::Blocks - Unix ---------------
libtool -dynamic -Lsdk/tinyxml -L/usr/lib  .objs/sdk/wxscintilla/src/wxscintilla.o .objs/sdk/wxscintilla/src/ScintillaWX.o .objs/sdk/wxscintilla/src/scintilla/src/AutoComplete.o .objs/sdk/wxscintilla/src/scintilla/src/CallTip.o .objs/sdk/wxscintilla/src/scintilla/src/CellBuffer.o .objs/sdk/wxscintilla/src/scintilla/src/ContractionState.o .objs/sdk/wxscintilla/src/scintilla/src/Document.o .objs/sdk/wxscintilla/src/scintilla/src/DocumentAccessor.o .objs/sdk/wxscintilla/src/scintilla/src/Editor.o .objs/sdk/wxscintilla/src/scintilla/src/ExternalLexer.o .objs/sdk/wxscintilla/src/scintilla/src/Indicator.o .objs/sdk/wxscintilla/src/scintilla/src/KeyMap.o .objs/sdk/wxscintilla/src/scintilla/src/KeyWords.o .objs/sdk/wxscintilla/src/scintilla/src/LexAPDL.o .objs/sdk/wxscintilla/src/scintilla/src/LexAU3.o .objs/sdk/wxscintilla/src/scintilla/src/LexAVE.o .objs/sdk/wxscintilla/src/scintilla/src/LexAda.o .objs/sdk/wxscintilla/src/scintilla/src/LexAsm.o .objs/sdk/wxscintilla/src/scintilla/src/LexAsn1.o .objs/sdk/wxscintill
libtool: can't open file: libtooll (No such file or directory)
Process terminated with status 1 (0 minutes, 3 seconds)
0 errors, 0 warnings

If I remove $libslibtooll from the advanced linker options, I get the following:
Code: [Select]

-------------- Build: AutoRevision in Code::Blocks - Unix ---------------
Target is up to date.

-------------- Build: ConsoleRunner in Code::Blocks - Unix ---------------
Target is up to date.

-------------- Build: tinyXML in Code::Blocks - Unix ---------------
Target is up to date.

-------------- Build: AngelScript in Code::Blocks - Unix ---------------
Target is up to date.

-------------- Build: scintilla in Code::Blocks - Unix ---------------
libtool -dynamic -Lsdk/tinyxml -L/usr/lib  .objs/sdk/wxscintilla/src/wxscintilla.o .objs/sdk/wxscintilla/src/ScintillaWX.o .objs/sdk/wxscintilla/src/scintilla/src/AutoComplete.o .objs/sdk/wxscintilla/src/scintilla/src/CallTip.o .objs/sdk/wxscintilla/src/scintilla/src/CellBuffer.o .objs/sdk/wxscintilla/src/scintilla/src/ContractionState.o .objs/sdk/wxscintilla/src/scintilla/src/Document.o .objs/sdk/wxscintilla/src/scintilla/src/DocumentAccessor.o .objs/sdk/wxscintilla/src/scintilla/src/Editor.o .objs/sdk/wxscintilla/src/scintilla/src/ExternalLexer.o .objs/sdk/wxscintilla/src/scintilla/src/Indicator.o .objs/sdk/wxscintilla/src/scintilla/src/KeyMap.o .objs/sdk/wxscintilla/src/scintilla/src/KeyWords.o .objs/sdk/wxscintilla/src/scintilla/src/LexAPDL.o .objs/sdk/wxscintilla/src/scintilla/src/LexAU3.o .objs/sdk/wxscintilla/src/scintilla/src/LexAVE.o .objs/sdk/wxscintilla/src/scintilla/src/LexAda.o .objs/sdk/wxscintilla/src/scintilla/src/LexAsm.o .objs/sdk/wxscintilla/src/scintilla/src/LexAsn1.o .objs/sdk/wxscintill
libtool: internal link edit command failed
ld: for architecture ppc
ld: Undefined symbols:
__Unwind_Resume
__ZTVN10__cxxabiv117__class_type_infoE
__ZTVN10__cxxabiv120__si_class_type_infoE
__ZdaPv
__ZdlPv
__Znam
__Znwm
___gxx_personality_v0
___cxa_pure_virtual
__ZTVN10__cxxabiv121__vmi_class_type_infoE
Process terminated with status 1 (0 minutes, 46 seconds)
0 errors, 0 warnings

Where is $libslibtooll defined ?

Anyone have some advice for me ?  I'm ready for some...

thanks
pecan
Title: Re: Mac Binaries
Post by: Pecan on April 30, 2006, 04:53:07 pm
There is an advanced linker option for making dynamic libs in CodeBlocks:
Code: [Select]
$linker -dynamic $libdirs $link_objects $link_resobjects -o $exe_output $link_options  $libslibtooll

The above is a bogus error. It happened when I editited the line within advanced options.
Somehow "slibtooll/n/t" got appended to the macro line. From now on I'll edit the  .conf directly. (don't know if this was human or code bug..it can wait )

However, I am still getting the following error:
Code: [Select]
-------------- Build: AutoRevision in Code::Blocks - Unix ---------------
Target is up to date.
-------------- Build: ConsoleRunner in Code::Blocks - Unix ---------------
Target is up to date.
-------------- Build: tinyXML in Code::Blocks - Unix ---------------
Target is up to date.
-------------- Build: AngelScript in Code::Blocks - Unix ---------------
Target is up to date.

-------------- Build: scintilla in Code::Blocks - Unix ---------------
libtool -dynamic -Lsdk/tinyxml -L/usr/lib  .objs/sdk/wxscintilla/src/wxscintilla.o .objs/sdk/wxscintilla/src/ScintillaWX.o .objs/sdk/wxscintilla/src/scintilla/src/AutoComplete.o .objs/sdk/wxscintilla/src/scintilla/src/CallTip.o .objs/sdk/wxscintilla/src/scintilla/src/CellBuffer.o .objs/sdk/wxscintilla/src/scintilla/src/ContractionState.o .objs/sdk/wxscintilla/src/scintilla/src/Document.o .objs/sdk/wxscintilla/src/scintilla/src/DocumentAccessor.o .objs/sdk/wxscintilla/src/scintilla/src/Editor.o .objs/sdk/wxscintilla/src/scintilla/src/ExternalLexer.o .objs/sdk/wxscintilla/src/scintilla/src/Indicator.o .objs/sdk/wxscintilla/src/scintilla/src/KeyMap.o .objs/sdk/wxscintilla/src/scintilla/src/KeyWords.o .objs/sdk/wxscintilla/src/scintilla/src/LexAPDL.o .objs/sdk/wxscintilla/src/scintilla/src/LexAU3.o .objs/sdk/wxscintilla/src/scintilla/src/LexAVE.o .objs/sdk/wxscintilla/src/scintilla/src/LexAda.o .objs/sdk/wxscintilla/src/scintilla/src/LexAsm.o .objs/sdk/wxscintilla/src/scintilla/src/LexAsn1.o .objs/sdk/wxscintill
libtool: internal link edit command failed
ld: for architecture ppc
ld: Undefined symbols:
__Unwind_Resume
__ZTVN10__cxxabiv117__class_type_infoE
__ZTVN10__cxxabiv120__si_class_type_infoE
__ZdaPv
__ZdlPv
__Znam
__Znwm
___gxx_personality_v0
___cxa_pure_virtual
__ZTVN10__cxxabiv121__vmi_class_type_infoE
Process terminated with status 1 (0 minutes, 45 seconds)
0 errors, 0 warnings

Anders, we sure would like a look at that make file. :)
Title: Re: Mac Binaries
Post by: Pecan on April 30, 2006, 08:44:08 pm
MyGod! I can't believe it. scintilla actually linked under OS X 10.3
as shown here:
Code: [Select]
libtool -dynamic -Lsdk/tinyxml -L/usr/lib -L/usr/local/lib -L/usr/lib/gcc/darwin/3.3 -L/usr/lib/gcc/darwin/default -L/usr/lib  .objs/sdk/wxscintilla/src/wxscintilla.o .objs/sdk/wxscintilla/src/ScintillaWX.o .objs/sdk/wxscintilla/src/scintilla/src/AutoComplete.o .objs/sdk/wxscintilla/src/scintilla/src/CallTip.o .objs/sdk/wxscintilla/src/scintilla/src/CellBuffer.o .objs/sdk/wxscintilla/src/scintilla/src/ContractionState.o .objs/sdk/wxscintilla/src/scintilla/src/Document.o .objs/sdk/wxscintilla/src/scintilla/src/DocumentAccessor.o .objs/sdk/wxscintilla/src/scintilla/src/Editor.o .objs/sdk/wxscintilla/src/scintilla/src/ExternalLexer.o .objs/sdk/wxscintilla/src/scintilla/src/Indicator.o .objs/sdk/wxscintilla/src/scintilla/src/KeyMap.o .objs/sdk/wxscintilla/src/scintilla/src/KeyWords.o .objs/sdk/wxscintilla/src/scintilla/src/LexAPDL.o .objs/sdk/wxscintilla/src/scintilla/src/LexAU3.o .objs/sdk/wxscintilla/src/scintilla/src/LexAVE.o .objs/sdk/wxscintilla/src/scintilla/src/LexAda.o .objs/sdk/wxscintilla/src/scintilla
Process terminated with status 0 (7 minutes, 47 seconds)
0 errors, 0 warnings

I still don't know if I've picked the correct libs. But this is what worked. I'd appreciate any Mac types comment on the lib lists. Would you compare it to your make file. Maybe even upload your make file... :lol: :lol:

Code: [Select]
            <Target title="scintilla">
                <Option output="devel/libwxscintilla.so" />
                <Option working_dir="devel" />
                <Option type="3" />
                <Option compiler="gcc" />
                <Option includeInTargetAll="1" />
                <Compiler>
                    <Add option="-DSCI_LEXER" />
                    <Add option="-DLINK_LEXERS" />
                    <Add option="-DGTK" />
                    <Add directory="sdk/wxscintilla/include" />
                    <Add directory="sdk/wxscintilla/src/scintilla/include" />
                    <Add directory="sdk/wxscintilla/src/scintilla/src" />
                </Compiler>
                <ResourceCompiler>
                    <Add directory="sdk/wxscintilla/include" />
                </ResourceCompiler>
                <Linker>
                    <Add option="`wx-config --libs`" />
                    <!--Add library="addhere" /-->
                    <Add library="/usr/lib/libSystem.B.dylib" />
                    <Add library="/usr/lib/libSystem.dylib" />
                    <Add library="/usr/lib/gcc/darwin/3.3/libstdc++.a" />
                    <Add library="/usr/lib/gcc/darwin/3.3/libgcc.a" />
                    <!--Add library="/usr/local/lib/libwx_mac-2.6.0.dylib" /-->
                    <Add directory="/usr/lib" />
                    <Add directory="/usr/local/lib" />
                    <Add directory="/usr/lib/gcc/darwin/3.3" />
                    <Add directory="/usr/lib/gcc/darwin/default" />
                </Linker>
            </Target>


pecan
Title: Re: Mac Binaries
Post by: Pecan on April 30, 2006, 11:59:16 pm
While compiling the sdk for "MacCodeBlocks", finddlg.cpp got a bunch of errors because it couldn't see the header files.

I defined "#undef CB_PRECOMP" ahead of the #ifdef CB_PRECOMP and it compiled nicely.

EDIT: 2006/05/1
The above is also true of replacedlg.cpp

I had set "pecomp headers in directory along sideof..." option long ago.

Why is this happening. Is there anything I can do about it. I'd like to get that #undef out of there.

I also noticed that setting "along side of" option did not change the
entry for finddlg...
Code: [Select]
<Unit filename="sdk\filegroupsandmasks.h">
<Option compilerVar="" />
<Option compile="0" />
<Option link="0" />
<Option target="sdk" />
</Unit>
<Unit filename="sdk\finddlg.cpp">
<Option compilerVar="CPP" />
<Option target="sdk" />
</Unit>
<Unit filename="sdk\finddlg.h">
<Option compilerVar="" />
<Option compile="0" />
<Option link="0" />
<Option target="sdk" />


Is this significant ?

thanks
pecan
Title: Re: Mac Binaries
Post by: Pecan on May 01, 2006, 07:44:33 pm
sdk now compiles/links under mcCodeBlocks.
Note: This is not a definitive solution. At the moment it's still "trial" and error

Modifications necessary:

* cp src/devel/libwxscintilla.so src/devel/libwxscintilla.dylib
  This should have been output as a dylib in the first place.

* modify .cbp under  <Target title="sdk">
Code: [Select]
              <Linker>
                     ...
                    <!-- Additional libs and dirs for mcCodeBlocks -->
                    <Add library="/usr/lib/libSystem.B.dylib" />
                    <Add library="/usr/lib/libSystem.dylib" />
                    <Add library="/usr/lib/gcc/darwin/3.3/libstdc++.a" />
                    <Add library="/usr/lib/gcc/darwin/3.3/libgcc.a" />
                    <Add directory="/usr/lib" />
                    <Add directory="/usr/local/lib" />
                    <Add directory="/usr/lib/gcc/darwin/3.3" />
                    <Add directory="/usr/lib/gcc/darwin/default" />
                </Linker>
 
Code: [Select]
-------------- Build: sdk in Code::Blocks - Unix ---------------
Running target pre-build steps
tools/autorevision/auto_revision +wx +int +t . sdk/autorevision.h
libtool -dynamic -Lsdk/tinyxml -Ldevel -Lsdk/as -Lsdk/propgrid -Lsdk/wxFlatNotebook -L/usr/lib -L/usr/local/lib -L/usr/lib/gcc/darwin/3.3 -L/usr/lib/gcc/darwin/default -L/usr/lib  .objs/sdk/xtra_res.o .objs/sdk/as/bindings/const_bindings.o .objs/sdk/as/bindings/sc_io.o .objs/sdk/as/bindings/sc_wxarraystring.o .objs/sdk/as/bindings/sc_wxstring.o .objs/sdk/as/bindings/scriptbindings.o .objs/sdk/autodetectcompilers.o .objs/sdk/base64.o .objs/sdk/blockallocated.o .objs/sdk/cbeditor.o .objs/sdk/cbeditorprintout.o .objs/sdk/cbexception.o .objs/sdk/cbplugin.o .objs/sdk/cbproject.o .objs/sdk/cbthreadpool.o .objs/sdk/cbworkspace.o .objs/sdk/compileoptionsbase.o .objs/sdk/compiler.o .objs/sdk/compilercommandgenerator.o .objs/sdk/compilerfactory.o .objs/sdk/compileroptions.o .objs/sdk/compiletargetbase.o .objs/sdk/configmanager-revision.o .objs/sdk/configmanager.o .objs/sdk/configurationpanel.o .objs/sdk/configuretoolsdlg.o .objs/sdk/confirmreplacedlg.o .objs/sdk/crc32.o .objs/sdk/devcpploader.o .objs/sdk/editarrayfile
Process terminated with status 0 (5 minutes, 42 seconds)
0 errors, 0 warnings
Title: Re: Mac Binaries
Post by: Pecan on May 03, 2006, 11:06:49 pm
Finally, a macCodeBlocks thats usable.

It has problems with AngelScript, and I haven't tried the contribs yet. But this version was created from a hand written CodeBlocks-mac-cbp.

I'm waiting for a makefile to check and modify the .cbp. I have all notes for necessary changes and will make a .patch.

(http://img365.imageshack.us/img365/1008/mccodeblocks53200645509pm1vh.png)

thanks
pecan


EDIT: btw, except for the startup, with all those lexers loading, it's quite spritely (as the elders say) on a imacg3 with only 128meg.
Title: Re: Mac Binaries
Post by: afb on May 03, 2006, 11:13:03 pm
Finally, a macCodeBlocks thats usable.

It has problems with AngelScript, and I haven't tried the contribs yet.

Looks great, I'm trying to build with SVN and wxWidgets 2.6.3, then send to you.
Title: Re: Mac Binaries
Post by: mandrav on May 04, 2006, 08:40:18 am
Amazing work Pecan :lol:
Title: Re: Mac Binaries
Post by: afb on May 04, 2006, 09:12:56 am
I still don't know if I've picked the correct libs. But this is what worked. I'd appreciate any Mac types comment on the lib lists. Would you compare it to your make file. Maybe even upload your make file... :lol: :lol:

You shouldn't need to add /usr/lib or /usr/local/lib to the search paths, I think ?

Linking with C++ is something of a pain, but "generally" -lstdc++ should do (without having to add any compiler paths). However, on Mac OS X 10.3– (only) you also need to link with libgcc.a too. But you do not need to do so on Mac OS X 10.4+

In another project I am using GNU Makefile code like:
Code: [Select]
LDFLAGS = `wx-config --libs` -lstdc++ `test -r /usr/lib/libcc_dynamic.a && echo -lcc_dynamic`
i.e. link with libcc_dynamic.a, but only if it it exists...
Title: Re: Mac Binaries
Post by: afb on May 04, 2006, 09:34:05 am
While compiling the sdk for "MacCodeBlocks", finddlg.cpp got a bunch of errors because it couldn't see the header files.

I defined "#undef CB_PRECOMP" ahead of the #ifdef CB_PRECOMP and it compiled nicely.
...
Why is this happening. Is there anything I can do about it. I'd like to get that #undef out of there.

It seems like a bunch of the new code is using "CB_PRECOMP", without first including the file where it is properly defined (that would be "sdk_precomp.h") This makes it fail on the Mac, since it disables CB_PRECOMP with GCC 3.3 in that header file - for some obscure reason (Apple's GCC 3.3 supports precomp, so the check is probably broken?).

Code: [Select]
#ifdef __GNUC__
    #if ( (__GNUC__ < 3) || ( (__GNUC__ == 3) && (__GNUC_MINOR__ < 4) ) )
        #undef CB_PRECOMP
    #endif
#endif

In order to work properly, the canonical way of writing the includes should be:

Code: [Select]
* $Id$
* $HeadURL$
*/

#include "sdk_precomp.h"

#if CB_PRECOMP
#include "sdk.h"
#else

Bug report on this coming, once the build is complete (and thus the diff too)
Title: Re: Mac Binaries
Post by: killerbot on May 04, 2006, 10:10:37 am
first : sdk_precomp.h -> sdk_common.h

Usage for including headers, should be something like this :

#ifdef CB_PRECOMP
#include "sdh.h" // precompiled header supported platform
#else
# include headers we need here and that are part of sdk.h (sdk_common.h)
#endif
# include headers we need here and that are NOT part of sdk.h (sdk_common.h)

CB_PRECOMP should be defined on the make file level or cbp level or should we include a special header for that , like sdk_common.h.

Note that sdk_common.h has different responsibilities now : in case of no precompiled headers (at all : so also no "WX_PRECOMP", causing an include of "#include <wx/wx.h>" and even always includes "#include <wx/wxprec.h>". This brings a whole lot of wx stuff in the current translation unit that will not be needed. It is better to explicitly specify what you need (that makes things clear) then to rely upon the fact that stuff might come in through some other deeply nested headers.

Seems in case of header definition (or undef) of CB_PRECOMP we need just a little header for that.


So something like this would be the template for including (usage in cpp files, don't use this in headers)
Code: [Select]
#include "cb_precomp_determining_header_goes_here"
#ifdef CB_PRECOMP
#include "sdh.h" // precompiled header supported platform
#else
# include headers we need here and that are part of sdk.h (sdk_common.h)
#endif
# include headers we need here and that are NOT part of sdk.h (sdk_common.h)
Title: Re: Mac Binaries
Post by: afb on May 04, 2006, 11:00:49 am
So something like this would be the template for including (usage in cpp files, don't use this in headers)
Code: [Select]
#include "cb_precomp_determining_header_goes_here"
#ifdef CB_PRECOMP
#include "sdh.h" // precompiled header supported platform
#else
# include headers we need here and that are part of sdk.h (sdk_common.h)
#endif
# include headers we need here and that are NOT part of sdk.h (sdk_common.h)

Okay, I hadn't noticed this change - only that it didn't compile...

Will use this instead then:
Code: [Select]
#include "sdk_common.h"
#ifndef CB_PRECOMP
# include // headers we need here and that are part of sdk.h (sdk_common.h)
#endif
# include // headers we need here and that are NOT part of sdk.h (sdk_common.h)

OK ?
Title: Re: Mac Binaries
Post by: afb on May 04, 2006, 11:18:25 am
Anyway, the important part for GCC 3.3 is that "sdk_common.h" is somehow included before any checks of CB_PRECOMP. I had assumed that the way to do this was to include "sdk_precomp.h", but it would probably be better to use a smaller file ?

Either way, the makefiles define CB_PRECOMP and sdk_common.h undefines it again...
This is why you get different results (i.e. compile failures in the end), depending on whether the original source included sdk_common.h (somehow), or if it didn't (before the #ifndef).
Title: Re: Mac Binaries
Post by: afb on May 04, 2006, 04:12:16 pm
Quote
Looks great, I'm trying to build with SVN and wxWidgets 2.6.3, then send to you.

With some patches, it built OK from SVN (rev 2411) and with wxWidgets 2.6.3

My screenshot is at http://www.algonet.se/~afb/wx/codeblocks.html#rev2411

(I used autotools to build it, while Pecan used Code::Blocks to build itself (!) )
Title: Re: Mac Binaries
Post by: Game_Ender on May 04, 2006, 07:48:42 pm
If someone could post a guide on the wiki about how the autotools were installed/tweaked and how they installed/configured wxWidgets for Mac OS X, I would love to try a universal build on Tiger.  I still think in the end it an xcode project file needs to be created or possibly a pluggin/upgrade for CB that lets you make application bundles and frameworks.
Title: Re: Mac Binaries
Post by: afb on May 04, 2006, 08:31:43 pm
If someone could post a guide on the wiki about how the autotools were installed/tweaked and how they installed/configured wxWidgets for Mac OS X, I would love to try a universal build on Tiger.

You can always build one for "powerpc" and one for "i686", and lipo them together at the end ?

I don't think building an Universal Binary will be a problem, the big obstacle now is AngelScript.
Title: Re: Mac Binaries
Post by: afb on May 04, 2006, 08:34:46 pm
I still think in the end it an xcode project file needs to be created or possibly a pluggin/upgrade for CB that lets you make application bundles and frameworks.

It would be nice with an importer that could read files from ProjectBuilder and Xcode,
just like it can import Visual Studio files on that other platform...
Title: Re: Mac Binaries
Post by: Pecan on May 04, 2006, 08:48:44 pm
If someone could post a guide on the wiki about how the autotools were installed/tweaked and how they installed/configured wxWidgets for Mac OS X, I would love to try a universal build on Tiger.  I still think in the end it an xcode project file needs to be created or possibly a pluggin/upgrade for CB that lets you make application bundles and frameworks.

http://wiki.codeblocks.org/index.php?title=Compiling_Code::Blocks_in_Mac_OS_X
 (http://wiki.codeblocks.org/index.php?title=Compiling_Code::Blocks_in_Mac_OS_X)

Anders  did an excellent job on the above wiki article.

I was never able, however, to get pass autoheader on 10.3. There seems to be some magic versions combo of glibtool, autoconf, etc to get it to work.
So I resorted to hand coding a .gdb.


But the article also contains more info than just autotools usage. It show how to get the generated dylib, module, and bundles working together in order to execute a development environment.
Title: Re: Mac Binaries
Post by: Sonic McTails on May 05, 2006, 03:49:02 am
I'm working on compiling CodeBlocks on mac OS X 10.4 Intel. I must be the only one to ever try this because it's totally broken on 10.4 due to the change in vesions to GCC. Autotools are passing the wrong options to build a library causing the compile to annilate itself. Since the hack of a package causes Mac OS X not to recongize it's a Rosetta binary, it fails to laucnh all together. Autotools needs to be upgraded to 1.9 or badly hacked to build.

That being said, why the hell are we using autotools, it's one of the worst POSes these days.

EDIT: Ok, I mutated libtool, and made a few code patches in place, and got it to build a i686-apple-darwin binary. Since so few of us have Intel macs, I'll make it a universal binary, give me a minute.

EDIT 2.0: Ugh. Some of my system tools built against non-universal binaries, I'm going to have to do massive work to make this compile properly as a universal binary. I should be able to do a seperate PPC binary build though.

EDIT 3.0: It seems only wxMac is actually failing a universal binary build, it's got an XCode project file, so I'm trying to use that. With any luck, I can them simply recompile CodeBlocks for a universal binary :)

EDIT 4.0: wxMac's XCode project is broken, it doesn't properly build a dymanic library (it fails out of linking). I tweaked its configure scripts a tad, and built universal binaries (;-). Unfortunity, Code::Blocks, when seeing the powerpc compiler (or maybe this is libtool/autotools) tries to create a universal binary, but not all if properly compiles. I'm going to use lipo to stick all the bits together.
Title: Re: Mac Binaries
Post by: afb on May 05, 2006, 11:40:08 am
I should be able to do a seperate PPC binary build though.
...
I'm going to use lipo to stick all the bits together.

When autotools are involved, it is usually easier to do two separate builds.
One for target "powerpc-apple-darwin8", and one for "i686-apple-darwin8".

This is also half the size of what a Universal Binary is, but if that is required
one can use lipo to combine the binaries (programs and libraries) at the end ?
Title: Re: Mac Binaries
Post by: afb on May 05, 2006, 11:47:40 am
Since the hack of a package causes Mac OS X not to recongize it's a Rosetta binary, it fails to laucnh all together.

I guess the shell script wrapper won't work in that case, what we really need is a patch to get the application "prefix" from the program instead of hardcoding it to "." like now...

If we then link wxWidgets statically, or use the wx.framework instead of dylibs, we should be able to put the program into the MacOS/CodeBlocks executable instead of using bin/lib.

However, any solution picked should still be able to run from the commandline too - for instance when being packaged up "unix-style" by DarwinPorts or Fink or similar ?
Title: Re: Mac Binaries
Post by: Sonic McTails on May 05, 2006, 02:15:25 pm
I should be able to do a seperate PPC binary build though.
...
I'm going to use lipo to stick all the bits together.

When autotools are involved, it is usually easier to do two separate builds.
One for target "powerpc-apple-darwin8", and one for "i686-apple-darwin8".

This is also half the size of what a Universal Binary is, but if that is required
one can use lipo to combine the binaries (programs and libraries) at the end ?


There is actually a long set of compiler flags you can pass to do it one pass, which is how I did it with wxMac. Howeve, due to the braindead design of autotools, codeblocks hangs itself trying this stunt. I was trying seperate buids, but I got extremely tired last ight so here I go again.
Title: Re: Mac Binaries
Post by: afb on May 05, 2006, 02:21:30 pm
There is actually a long set of compiler flags you can pass to do it one pass,

Yeah, but it doesn't always work :P

Q: Do we want one PPC build and one X86 build, or a Universal Binary ?
Title: Re: Mac Binaries
Post by: Pecan on May 05, 2006, 02:31:12 pm

Q: Do we want one PPC build and one X86 build, or a Universal Binary ?


I vote separate pkgs. Faster downloading and install. For us older imacgx users, the Universal is just extra weight.

And the macNtel users most likely will not use the ppc.
Title: Re: Mac Binaries
Post by: afb on May 05, 2006, 02:38:41 pm
BTW; I uploaded "codeblocks-rev2411_macppc.zip" to BerliOS
Title: Re: Mac Binaries
Post by: Sonic McTails on May 05, 2006, 03:03:17 pm

Q: Do we want one PPC build and one X86 build, or a Universal Binary ?


I vote separate pkgs. Faster downloading and install. For us older imacgx users, the Universal is just extra weight.

And the macNtel users most likely will not use the ppc.


Seperate packages mean double the work for packing. Universal binaries in this case are preferable, because I also keep apps on a network share and use them between both PPC and i686. You can use Monolingual to strip out the excess arch: http://monolingual.sourceforge.net/
Title: Re: Mac Binaries
Post by: afb on May 05, 2006, 03:10:28 pm
Seperate packages mean double the work for packing.

What kind of packaging did you have in mind, for Code::Blocks ?
Title: Re: Mac Binaries
Post by: Sonic McTails on May 05, 2006, 03:42:49 pm
Seperate packages mean double the work for packing.

What kind of packaging did you have in mind, for Code::Blocks ?

I believe he means one PPC and one Intel binary, instead of having a single universal binary. It seems when cross-compiling for powerpc-apple-darwin, it doesn't properly build shared libraries, but I think I got it fixed.
Title: Re: Mac Binaries
Post by: Sonic McTails on May 05, 2006, 04:42:45 pm
Ugh, ok, I got it to compile as a universal binaries but the plugins and libraries got mutated. libtool obviously has no idea what to do :-/. Having universal binaries is going to be a lot of work unless either Code::Blocks add universal binary support, or C::B switchs build systems.

EDIT: Well, I got a universal binary, but plugins are completely broken -  it only loads if I move it out of the way. It appears the problem is the plugins are built as bundles instead of libraries, which are not universally supported, hence why it blows it. The build system going to require major work to make this work well.
Title: Re: Mac Binaries
Post by: Trikko on May 07, 2006, 07:25:16 pm
I've tried the latest mac binary. It works. I compiled also a simple wxWidgets project. By the way it has yet many bugs, have i to report them?
Title: Re: Mac Binaries
Post by: Game_Ender on May 07, 2006, 08:26:01 pm
Maybe I am a little bit of newb here but I got wxMac to compile on an Intel iMac by just configureing with a configure option like "--enable-universal".  It worked without any problems, I was also able to compile the sample wxwidgets apps.  I also got another library, OpenSceneGraph to compile as universal by just including the proper "-arch" options in its makefiles.  From all I have been able to find GCC will do all the universal magic if you just pass it both "-arch ppc" and "-arch ix86" to it on both linking and compiling.  That is all I had to do OpenSceneGraph to get it as a universal library.

It also seems all these build headaches could be fixed if one of us just broke down and made an xcode project.  There will be more maintenance overhead but in the end I think it would be very cool if would could put together a Universal CodeBlocks.app for Mac users.  Although, I do hope the autotools can be made to place nice, less maintenance is always better.

Just a helpfull pointer: You must have the proper dev tools installed, there is a version on Apples website that includes non-universal builds of some libraries.  The dev tools that come with the iMac, on the CD/DVD should include universal versions of all the libraries.
Title: Re: Mac Binaries
Post by: afb on May 07, 2006, 08:52:24 pm
By the way it has yet many bugs, have i to report them?

Plugins doesn't work, that's a known bug. (no AngelScript support for Mac yet...)
Otherwise, reporting - or better yet, fixing ;-) - the bugs isn't a bad idea I think?

I think I'll upload another build later today, that has the GDC compiler activated:
http://gdcmac.sourceforge.net/
Title: Re: Mac Binaries
Post by: afb on May 08, 2006, 08:59:04 am
It also seems all these build headaches could be fixed if one of us just broke down and made an xcode project.  There will be more maintenance overhead but in the end I think it would be very cool if would could put together a Universal CodeBlocks.app for Mac users.  Although, I do hope the autotools can be made to place nice, less maintenance is always better.

I will not be using Xcode with Code::Blocks, other than importing .pbproj/.xcode projects.

However, I will try to build a universal (or at least X86) build with Mac OS X 10.4 soonish.
Title: Re: Mac Binaries
Post by: Trikko on May 08, 2006, 12:27:53 pm
http://www.gamedev.net/community/forums/topic.asp?topic_id=321624

Why can't we convert function in that way? So it works for win and mac!
Title: Re: Mac Binaries
Post by: Pecan on May 08, 2006, 02:27:20 pm
http://www.gamedev.net/community/forums/topic.asp?topic_id=321624

Why can't we convert function in that way? So it works for win and mac!


Thanks, I've been looking for some info like that.

I tried the AS_MAX_PORTABILITY, but still get scripting errs.
Will look deeper into it unless afb or someone beats me to it.

Now... for some IBM assembler.....

pecan
Title: Re: Mac Binaries
Post by: afb on May 08, 2006, 04:36:45 pm
I posted some thoughts in this AngelScript thread:
http://www.gamedev.net/community/forums/topic.asp?topic_id=371730

But I haven't gotten it to actually work for PowerPC yet,
just the same "basic" ones as AS_MAX_PORTABILITY gives
Title: Re: Mac Binaries
Post by: Pecan on May 08, 2006, 04:50:17 pm
I posted some thoughts in this AngelScript thread:
http://www.gamedev.net/community/forums/topic.asp?topic_id=371730

But I haven't gotten it to actually work for PowerPC yet,
just the same "basic" ones as AS_MAX_PORTABILITY gives


Just read the thread on gamedev...

So... if you're porting AS to ppc, I'll back off and do something else useful.

However, if you need a helping hand, just give some direction in which I can help you.

pecan

ps: maybe send me a makefile so I can check out my .cbp :D


Title: Re: Mac Binaries
Post by: afb on May 08, 2006, 04:57:12 pm
So... if you're porting AS to ppc, I'll back off and do something else useful.

I was, and still want it to work, but I'm not working on it at the moment. (no time)

So if you are able to make it "go" with those temp hacks, feel free to continue...
Title: Re: Mac Binaries
Post by: Trikko on May 08, 2006, 08:27:05 pm
In my opinion it should be useful to convert all angelscript piece of software using second method, is the same as complexity (they say it need a wrapper that call a function, i think it just need a wrapper with function inside it, it's not more complex than first solutions).
Title: Re: Mac Binaries
Post by: Pecan on May 09, 2006, 05:09:32 pm

Okay, I hadn't noticed this change - only that it didn't compile...

Will use this instead then:
Code: [Select]
#include "sdk_common.h"
#ifndef CB_PRECOMP
# include // headers we need here and that are part of sdk.h (sdk_common.h)
#endif
# include // headers we need here and that are NOT part of sdk.h (sdk_common.h)

OK ?

Anders --
what did you decide to do here for precomp headers.

Shall I use your diff file ??:
Code: [Select]
+
+#include "sdk_precomp.h"

Title: Re: Mac Binaries
Post by: afb on May 09, 2006, 05:47:22 pm
what did you decide to do here for precomp headers.

Fix it :-)

http://developer.berlios.de/bugs/?func=detailbug&bug_id=7415&group_id=5358
It compiles a lot faster on Panther, when using the pre-compiled headers...

I'm not 100% sure how the headers are supposed to look, so I left the
current ones and didn't do any more patches or rearranging of them myself.
Title: CompilerGDB missing from unix .cbp
Post by: Pecan on May 11, 2006, 06:02:17 pm
I cannot link McCodeBlocks SVN 2438 because it needs something called CompilerGDB::CompilerGDB().

There seems to be one in the Codeblocks.cbp, but none in the CodeBlocks-unix.cbp.

Should I change the code or the .cbp??

thanks
pecan
Title: Re: CompilerGDB missing from unix .cbp
Post by: afb on May 12, 2006, 12:40:35 am
I cannot link McCodeBlocks SVN 2438 because it needs something called CompilerGDB::CompilerGDB().

If it says "CompilerGDC", then please add that...

http://gdcmac.sourceforge.net/
Title: Re: CompilerGDB missing from unix .cbp
Post by: Pecan on May 12, 2006, 01:07:25 am

If it says "CompilerGDC", then please add that...

http://gdcmac.sourceforge.net/

Acknowledge. Will add to CodeBlocks-mac.cbp
Also, am still verifying that the .cbp is correct.
Title: Re: Mac Binaries
Post by: Pecan on May 12, 2006, 03:27:38 pm
For anyone who would like to compile mcCodeBlocks with a cbp, here is the alpha patch containing the patches provided by afb and pecan.

It does not yet contain the contribs.

I have not yet tested the patched code  under windows and linux, so it most likely will change.

Remember; the .so files end up being .dylib files, so after running ./update, you will have to copy them to .../output if you do the update.

Also you will have to use a different ./run.sh: like:
Code: [Select]
#!/ bin/sh
#  ^remove this space(and this comment)

APP_DIR=/Users/pecan/devel/mac/trunk/src/devel/
export LD_LIBRARY_PATH=$APP_DIR:$LD_LIBRARY_PATH

LIB=$APP_DIR

DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$LIB
export DYLD_LIBRARY_PATH

#--exec $APP_DIR/codeblocks --prefix=$DIR
echo DIR=$APP_DIR
echo LIB=$LIB
echo DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH
echo command line =exec $APP_DIR/codeblocks --prefix="$APP_DIR"

exec $APP_DIR/codeblocks --prefix="$APP_DIR"
 

Find attached macdiff.zip

thanks
pecan


[attachment deleted by admin]
Title: Re: Mac Binaries
Post by: afb on May 12, 2006, 11:17:53 pm
For anyone who would like to compile mcCodeBlocks with a cbp, here is the alpha patch containing the patches provided by afb and pecan.

Find attached macdiff.zip

It seems like all these patches (except the new project) are regressions of previously reported bugs like the "propgrid" bug or the AngelScript "malloc.h" bug. So they'll need to be reopened or reported again, I suppose. (AngelScript is of course still awating a "final solution"...)
Title: Re: Mac Binaries
Post by: Pecan on May 16, 2006, 04:27:51 pm
It seems like all these patches (except the new project) are regressions of previously reported bugs like the "propgrid" bug or the AngelScript "malloc.h" bug. So they'll need to be reopened or reported again, I suppose. (AngelScript is of course still awating a "final solution"...)

Anders..
I can be blind as a bat sometimes, but I cannot find any of your patches on berlios. Maybe they're on another svn tree...??

Every time I svn update, I have to re-apply your patches. So I don't think they are "regressed". They just arn't there.

Could I have permission to test (against windows and linux) your mac patches and  submit them to berlios.

thanks
pecan
Title: Re: Mac Binaries
Post by: afb on May 16, 2006, 04:32:08 pm
I can be blind as a bat sometimes, but I cannot find any of your patches on berlios. Maybe they're on another svn tree...??

Every time I svn update, I have to re-apply your patches. So I don't think they are "regressed". They just arn't there.

Could I have permission to test (against windows and linux) your mac patches and  submit them to berlios.

I haven't checked where old patches go to die, but I'm pretty sure that I submitted them...
Either way, if you could resubmit them then that is quite alright with me as they're needed.

I think that AngelScript had a better fix coming from upstream, but until that happens so ?
Title: Re: Mac Binaries
Post by: afb on May 16, 2006, 04:33:55 pm
It's possible that they were on SourceForge, before the move...
Title: Re: Mac Binaries
Post by: Pecan on May 16, 2006, 04:55:17 pm
It's possible that they were on SourceForge, before the move...

Sorry they got lost; but I'm gonna resubmit them over the next couple of days anyway. We'll then have a record of them through berlios.
Title: Re: Mac Binaries
Post by: Pecan on May 17, 2006, 07:30:56 pm
Does anyone know of a GDB 6.3 for MAC Panther (10.3).

The current gdb 5.3-20030128 (apple version gdb-330.1) does not appear to work with CodeBlocks.

thanks
pecan
Title: Re: Mac Binaries
Post by: Michael on May 17, 2006, 09:29:42 pm
Does anyone know of a GDB 6.3 for MAC Panther (10.3).

The current gdb 5.3-20030128 (apple version gdb-330.1) does not appear to work with CodeBlocks.

Hello,

I do not know if the is a gdb 6.3 for Panther. May be you can build it from the sources.

I have found this info here (http://www.prowiki.org/wiki4d/wiki.cgi?GdcHacking):

Quote
Apple versions, for Mac OS X 10.4.x "Tiger":

New versions: (Xcode Tools 2.1-2.2)

    * gcc-???? (based on GCC 4.0.1)
    * gdb-???? (based on GDB 6.3)

Note: Xcode 2.0-2.1 use GCC 4.0 and are very buggy in general. Upgrade to Xcode 2.2 or 2.2.1 or later!

Best wishes,
Michael
Title: Re: Mac Binaries
Post by: afb on May 17, 2006, 10:15:10 pm
(it might be possible to build a FSF version of GDB 6.3 for Mac OS X 10.3, just as you might succeed building a FSF version of GCC 4.0 - but it is not supported by Apple)

What seems to be the problem with GDB 5.3, by the way ? (perhaps start a new topic though)

PS. Glad you liked the GDC page, I cleaned the info up a little.
Title: Re: Mac Binaries
Post by: Pecan on May 18, 2006, 02:57:10 am

What seems to be the problem with GDB 5.3, by the way ?


gdb 5.3 just stalls when used as a plugin. Even on a simple "hello world".

It shows no breaks, no watches, nothing. It recognizes "continue", but does nothing about it.

CodeBlocks appears to need 6.3 to debug correctly as a plugin.
gdb 5.3 works ok as a command line debugger only.

Lots of msgs about this on the forum.
 
Title: Re: Mac Binaries
Post by: Pecan on May 18, 2006, 10:51:14 pm
(it might be possible to build a FSF version of GDB 6.3 for Mac OS X 10.3, just as you might succeed building a FSF version of GCC 4.0 - but it is not supported by Apple)

Bad news. It appears that gdb 6.3 will not compile on Panther(10.3.9).
That means *no* integrated debugging with CodeBlocks.
That means I'm about to abandon the Panther ship. Buy some more memory and see If I can run Tiger on this imacg3.

Oh well.. it was worth the effort, maybe. :(
But if a user cannot easily compile 6.3 on Panther, then I think that might be the death nell of CB on 10.3

I ran ./configure from within the src folder, then make.
gdb 6.3 (apple gdb-434) gets the following errors. I've no idea what the errs mean.

Code: [Select]
gcc -c -g -O2 -DTARGET_POWERPC -I./macosx -I./macosx -DWITH_CFM=1 -DUSE_PTHREADS  =1 -Wall -Wimplicit -Wno-long-double  -I. -I. -I./config -DLOCALEDIR="\"/usr/loc  al/share/locale\"" -DHAVE_CONFIG_H -I./../include/opcode -I./../readline/.. -I..  /bfd -I./../bfd -I./../include -I./../mmalloc -I../intl -I./../intl  -DMI_OUT=1   -DTUI=1 -I/usr/include/libxml2 -Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -W  format -Wparentheses -Wpointer-arith -Wuninitialized -Wformat-nonliteral -Wunuse  d-label -Wunused-function  ./macosx/ppc-macosx-nat-exec.c
gcc -c -g -O2 -DTARGET_POWERPC -I./macosx -I./macosx -DWITH_CFM=1 -DUSE_PTHREADS  =1 -Wall -Wimplicit -Wno-long-double  -I. -I. -I./config -DLOCALEDIR="\"/usr/loc  al/share/locale\"" -DHAVE_CONFIG_H -I./../include/opcode -I./../readline/.. -I..  /bfd -I./../bfd -I./../include -I./../mmalloc -I../intl -I./../intl  -DMI_OUT=1   -DTUI=1 -I/usr/include/libxml2 -Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -W  format -Wparentheses -Wpointer-arith -Wuninitialized -Wformat-nonliteral -Wunuse  d-label -Wunused-function  ./macosx/macosx-nat-watchpoint.c
gcc -c -g -O2 -DTARGET_POWERPC -I./macosx -I./macosx -DWITH_CFM=1 -DUSE_PTHREADS  =1 -Wall -Wimplicit -Wno-long-double  -I. -I. -I./config -DLOCALEDIR="\"/usr/loc  al/share/locale\"" -DHAVE_CONFIG_H -I./../include/opcode -I./../readline/.. -I..  /bfd -I./../bfd -I./../include -I./../mmalloc -I../intl -I./../intl  -DMI_OUT=1   -DTUI=1 -I/usr/include/libxml2 -Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -W  format -Wparentheses -Wpointer-arith -Wuninitialized -Wformat-nonliteral -Wunuse  d-label -Wunused-function  ./macosx/macosx-nat-dyld.c

In file included from macosx/macosx-nat-dyld.c:57:
macosx/macosx-nat-inferior-debug.h:21: error: parse error before "mach_vm_addres  s_t"
macosx/macosx-nat-inferior-debug.h:22: error: parse error before "mach_vm_addres  s_t"
macosx/macosx-nat-dyld.c: In function `dyld_starts_here_p':
macosx/macosx-nat-dyld.c:369: error: `MH_MAGIC_64' undeclared (first use in this   function)
macosx/macosx-nat-dyld.c:369: error: (Each undeclared identifier is reported onl  y once
macosx/macosx-nat-dyld.c:369: error: for each function it appears in.)
macosx/macosx-nat-dyld.c:369: error: `MH_CIGAM_64' undeclared (first use in this   function)
macosx/macosx-nat-dyld.c: In function `macosx_dyld_init':
macosx/macosx-nat-dyld.c:613: error: `CPU_TYPE_POWERPC64' undeclared (first use   in this function)
macosx/macosx-nat-dyld.c: In function `dyld_info_process_raw':
macosx/macosx-nat-dyld.c:1003: warning: unsigned int format, long unsigned int a  rg (arg 3)
macosx/macosx-nat-dyld.c:1077: error: invalid application of `sizeof' to an inco  mplete type
macosx/macosx-nat-dyld.c:1093: error: `LC_SEGMENT_64' undeclared (first use in t  his function)
macosx/macosx-nat-dyld.c:1095: error: storage size of `segcmd' isn't known
macosx/macosx-nat-dyld.c:1097: error: invalid application of `sizeof' to an inco  mplete type
macosx/macosx-nat-dyld.c:1095: warning: unused variable `segcmd'
macosx/macosx-nat-dyld.c:1151: warning: unsigned int format, long unsigned int a  rg (arg 6)
macosx/macosx-nat-dyld.c: In function `info_sharedlibrary_raw_dyld_command':
macosx/macosx-nat-dyld.c:1979: warning: unused variable `task'
make[1]: *** [macosx-nat-dyld.o] Error 1
make: *** [all-gdb] Error 2
iMacG3:~/devel/mac/proj/gdb-434/src pecan$
Title: Re: Mac Binaries
Post by: afb on May 18, 2006, 11:17:26 pm
gdb 6.3 (apple gdb-434) gets the following errors. I've no idea what the errs mean.

As far as I can tell it says that you are missing support for PPC64 targets...
Title: Re: Mac Binaries
Post by: Pecan on May 18, 2006, 11:37:01 pm
gdb 6.3 (apple gdb-434) gets the following errors. I've no idea what the errs mean.

As far as I can tell it says that you are missing support for PPC64 targets...

Of course I'm missing PPC64 support. I only have an imacg3.

But I think the problems happened before the PPC64 errors.
The gcc 3.3 compiler could not handle some code and got two parseing errors.

That's what I meant about "..cannot easily compile..". Looks like the compiler cannot handle the apple gdb source code.
Title: Re: Mac Binaries
Post by: afb on May 18, 2006, 11:43:05 pm
Of course I'm missing PPC64 support. I only have an imacg3.

I meant that the OS (10.3) doesn't have PPC64, only PPC (32).
And you might be right about it requiring GCC 4.0 to compile...

The bottom line is that if C::B doesn't support GDB 5.3,
then it isn't going to work very well on Mac OS X 10.3
Title: Re: Mac Binaries
Post by: mandrav on May 18, 2006, 11:59:10 pm
Quote from: Pecan
Bad news. It appears that gdb 6.3 will not compile on Panther(10.3.9).
That means *no* integrated debugging with CodeBlocks.
That means I'm about to abandon the Panther ship. Buy some more memory and see If I can run Tiger on this imacg3.

Maybe it's a good time to see why gdb-5.x doesn't work with C::B?
Create a hello-world project, set a breakpoint somewhere and hit "Debug". Then send me (or post here) both the debugger's logs (i.e. "debugger's log" and "debugger's debug log").
Title: Re: Mac Binaries
Post by: Pecan on May 19, 2006, 02:20:52 am
Maybe it's a good time to see why gdb-5.x doesn't work with C::B?
Create a hello-world project, set a breakpoint somewhere and hit "Debug". Then send me (or post here) both the debugger's logs (i.e. "debugger's log" and "debugger's debug log").

Setting breakpoint shows (cf. image). When hitting the debug button, the gdb title shows in the debug window, but nothing else ever happens. You can hit any of the other buttons. No activity. All buttons are enabled.

The stop button works. The continue button show "continue in the debug window, but it does not in fact continue.

I don't know what else you may want/need. Just ask...
Be kind. I'm not an experienced mcUser. :?

(http://img487.imageshack.us/img487/1548/graphic518200680235pm9cm.png)

Code: [Select]
image
----------------------------------------------------------------
http://img487.imageshack.us/img487/1548/graphic518200680235pm9cm.png

Debugger window
------------------------------------------------------------------
Building to ensure sources are up-to-date
Build succeeded
Selecting target: default
Adding source dir: /Volumes/Seagate/MAC/temp/minimal/
Adding source dir: /Volumes/Seagate/MAC/temp/minimal/
Adding file: minimal
Starting debugger: done
Invalid debugger script: 'gdb_types.script'
Setting breakpoints
Debugger name and version: GNU gdb 5.3-20030128 (Apple version gdb-330.1) (Fri Jul 16 21:42:28 GMT 2004)
Continuing...
Continuing...
Continuing...
Continuing...

Code::Blocks Debug window
----------------------------------------------------------------------
[19:22:51.467]: Initialize EditColorSet .....
[19:22:51.669]: Loading lexer_rc.xml
[19:22:51.730]: Loading lexer_python.xml
[19:22:51.785]: Loading lexer_prg.xml
[19:22:51.825]: Loading lexer_nsis.xml
[19:22:51.887]: Loading lexer_matlab.xml
[19:22:51.947]: Loading lexer_masm.xml
[19:22:52.000]: Loading lexer_lua.xml
[19:22:52.040]: Loading lexer_hitasm.xml
[19:22:52.087]: Loading lexer_gm.xml
[19:22:52.130]: Loading lexer_glsl.xml
[19:22:52.189]: Loading lexer_f77.xml
[19:22:52.240]: Loading lexer_diff.xml
[19:22:52.276]: Loading lexer_d.xml
[19:22:52.320]: Loading lexer_css.xml
[19:22:52.370]: Loading lexer_cpp.xml
[19:22:52.425]: Loading lexer_cg.xml
[19:22:52.493]: Loading lexer_batch.xml
[19:22:52.537]: Loading lexer_angelscript.xml
[19:22:52.590]: Loading lexer_OgreMaterial.xml
[19:22:52.651]: Loading lexer_OgreCompositor.xml
[19:22:52.701]: Loading lexer_xml.xml
[19:22:52.889]: Initialize EditColorSet: done.
[19:22:54.168]: Loading toolbar...
[19:22:56.254]: AStylePlugin: loaded
[19:22:56.810]: Wizard: loaded
[19:22:57.597]: PluginWizard: loaded
[19:22:58.389]: FilesExtensionHandler: loaded
[19:22:59.665]: Debugger: loaded
[19:23:01.153]: Added compiler "GNU GCC Compiler"
[19:23:01.191]: Added compiler "Intel C/C++ Compiler"
[19:23:01.286]: Added compiler "SDCC Compiler"
[19:23:01.315]: Added compiler "GNU GDC Compiler"
[19:23:01.354]: Compiler: loaded
[19:23:02.353]: Concurrent threads for pool set to 1
[19:23:03.636]: CodeCompletion: loaded
[19:23:04.596]: ClassWizard: loaded
[19:23:05.938]: ToDoList: loaded
[19:23:06.073]: Files extension handler plugin loaded
[19:23:11.483]: Debugger plugin loaded
[19:23:13.279]: Compiler plugin loaded
[19:23:14.927]: Loading workspace "/Users/pecan/.codeblocks/default.workspace"
[19:23:14.979]: File does not exist.
[19:23:15.015]: Initializing plugins...
[19:23:31.054]: Loading project file...
[19:23:31.119]: Parsing project file...
[19:23:31.177]: Loading target default
[19:23:31.217]: Loading project files...
[19:23:31.283]: 1 files loaded
[19:23:31.325]: Done loading project in 271ms
[19:23:31.368]: Project's base path: /Volumes/Seagate/MAC/temp/minimal/
[19:23:31.413]: Project's common toplevel path: /Volumes/Seagate/MAC/temp/minimal/
[19:23:31.880]: project data set for /Volumes/Seagate/MAC/temp/minimal/minimal.cpp
[19:23:31.976]: Top Editor: /Volumes/Seagate/MAC/temp/minimal/minimal.cpp
[19:24:28.130]: Removed minimal from all deps
[19:24:33.897]: Loading project file...
[19:24:33.947]: Parsing project file...
[19:24:34.033]: Loading target default
[19:24:34.082]: Loading project files...
[19:24:34.134]: 1 files loaded
[19:24:34.183]: Done loading project in 286ms
[19:24:34.237]: Project's base path: /Volumes/Seagate/MAC/temp/minimal/
[19:24:34.292]: Project's common toplevel path: /Volumes/Seagate/MAC/temp/minimal/
[19:24:34.628]: project data set for /Volumes/Seagate/MAC/temp/minimal/minimal.cpp
[19:24:34.734]: Top Editor: /Volumes/Seagate/MAC/temp/minimal/minimal.cpp
[19:24:57.016]: Scanned 0 files for #includes, cache used 0, cache updated 0
[19:24:57.534]: Scanned 0 files for #includes, cache used 0, cache updated 0
[19:24:57.621]: Scanned 0 files for #includes, cache used 0, cache updated 0
[19:24:57.699]: Scanned 0 files for #includes, cache used 0, cache updated 0
[19:25:16.592]: Scanned 0 files for #includes, cache used 0, cache updated 0
[19:25:16.671]: Scanned 0 files for #includes, cache used 0, cache updated 0
[19:25:16.740]: Scanned 0 files for #includes, cache used 0, cache updated 0
[19:25:16.841]: Scanned 0 files for #includes, cache used 0, cache updated 0
[19:26:04.782]: Scanned 0 files for #includes, cache used 0, cache updated 0
[19:26:04.884]: Scanned 0 files for #includes, cache used 0, cache updated 0
[19:26:05.011]: Scanned 0 files for #includes, cache used 1, cache updated 0
[19:26:05.104]: Scanned 0 files for #includes, cache used 0, cache updated 0
[19:26:05.191]: Scanned 0 files for #includes, cache used 0, cache updated 0
[19:26:05.279]: Scanned 0 files for #includes, cache used 0, cache updated 0
[19:26:05.369]: Scanned 0 files for #includes, cache used 0, cache updated 0



command line gdb 5.3
---------------------------------------------------------------------------
iMacG3:~/devel/mac/temp/minimal pecan$ ls
minimal         minimal.cbp     minimal.cpp     minimal.depend  minimal.layout
iMacG3:~/devel/mac/temp/minimal pecan$ gdb minimal
GNU gdb 5.3-20030128 (Apple version gdb-330.1) (Fri Jul 16 21:42:28 GMT 2004)
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "powerpc-apple-darwin".
Reading symbols for shared libraries .. done
(gdb) l
1       #include <iostream>
2
3       int main()
4       {
5           int i = 0;
6           if (i==0) printf("Hello world");
7               std::cout << "Hello world!" << std::endl;
8           system("pause");
9               return 0;
10      }
(gdb) b 7
Breakpoint 1 at 0x2d84: file minimal.cpp, line 7.
(gdb) run
Starting program: /Volumes/Seagate/MAC/temp/minimal/minimal
Reading symbols for shared libraries . done

Breakpoint 1, main () at minimal.cpp:7
7               std::cout << "Hello world!" << std::endl;
(gdb) n
Hello worldHello world!
8           system("pause");
(gdb) n
sh: line 1: pause: command not found
9               return 0;
(gdb) n
10      }
(gdb) n

Program exited normally.
(gdb)


command line compiled (hacked) gdb 6.3 (apple gdb 434)
---------------------------------------------------------------
iMacG3:~/devel/mac/proj/gdb-434/src/gdb pecan$ ./gdb /users/pecan/devel/mac/temp/minimal/minimal
GNU gdb 2004-03-03-cvs (Thu May 18 21:10:29 GMT 2006)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=powerpc-apple-darwin7.9.0 --target="...Reading symbols for shared libraries .. done

Setting up the environment for debugging gdb.
Function "internal_error" not defined.
Function "info_command" not defined.
.gdbinit:8: Error in sourced command file:
No breakpoint number 0.
(gdb) l
1       #include <iostream>
2
3       int main()
4       {
5           int i = 0;
6           if (i==0) printf("Hello world");
7               std::cout << "Hello world!" << std::endl;
8           system("pause");
9               return 0;
10      }
(gdb) b 7
Breakpoint 1 at 0x2d84: file minimal.cpp, line 7.
(gdb) run
Starting program: /volumes/Seagate/MAC/temp/minimal/minimal

Breakpoint 1, main () at minimal.cpp:7
7               std::cout << "Hello world!" << std::endl;
(gdb) n
Hello worldHello world!
8           system("pause");
(gdb) n
sh: line 1: pause: command not found
9               return 0;
(gdb) n
10      }
(gdb) n

Program exited normally.
(gdb) q
Title: Re: Mac Binaries
Post by: mandrav on May 19, 2006, 06:12:37 pm
Quote
I don't know what else you may want/need. Just ask...

As written above, I want the debugger's debug log. Enable it with "Settings->Compiler and debugger->Debugger->Display debugger's log".
Title: Re: Mac Binaries
Post by: Pecan on May 19, 2006, 08:46:55 pm

As written above, I want the debugger's debug log. Enable it with "Settings->Compiler and debugger->Debugger->Display debugger's log".

"As written above...". Is that some sort of nasty reply? If so, I don't believe I deserve it. I'm trying the best I know how.


GDB 5.3 is now working with CB OSX 10.3
The moment I saw the output from the debuggers debug display I understood the problem.

mcCodeBlocks GDB needs a "run" not a "start". I'll include this in the patches I'm working on.

Code: [Select]
void GDB_driver::Start(bool breakOnEntry)
{
    ResetCursor();

    // under windows, 'start' segfaults with wx projects...
//-#ifdef __WXMSW__
#if defined(__WXMSW__) || defined(__WXMAC__)
    m_BreakOnEntry = false;
    m_ManualBreakOnEntry = false;
    // start the process
    QueueCommand(new DebuggerCmd(this, _T("run")));
#else
    m_BreakOnEntry = breakOnEntry;
    m_ManualBreakOnEntry = true;
    // start the process
    QueueCommand(new DebuggerCmd(this, _T("start")));
#endif
}

Code: [Select]
Command-line: /usr/bin/gdb -nx -fullname  -args minimal
Working dir : /Volumes/Seagate/MAC/temp/minimal/
> set prompt >>>>>>cb_gdb:
GNU gdb 5.3-20030128 (Apple version gdb-330.1) (Fri Jul 16 21:42:28 GMT 2004)
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "powerpc-apple-darwin".
Reading symbols for shared libraries .. done
(gdb) >>>>>>cb_gdb:
> set confirm off
>>>>>>cb_gdb:
> set width 0
>>>>>>cb_gdb:
> set height 0
>>>>>>cb_gdb:
> set breakpoint pending on
No symbol "breakpoint" in current context.
>>>>>>cb_gdb:
> set print asm-demangle on
>>>>>>cb_gdb:
> set disassembly-flavor att
No symbol "disassembly" in current context.
>>>>>>cb_gdb:
> directory /Volumes/Seagate/MAC/temp/minimal/
>>>>>>cb_gdb:
> delete breakpoints
>>>>>>cb_gdb:
> break minimal.cpp:7
Breakpoint 1 at 0x2d80: file minimal.cpp, line 7.
>>>>>>cb_gdb:
> run
Reading symbols for shared libraries
. done
Breakpoint 1, main () at minimal.cpp:7
/Volumes/Seagate/MAC/temp/minimal/minimal.cpp:7:92:beg:0x2d80
>>>>>>cb_gdb:
> next
Hello world
Hello world!
/Volumes/Seagate/MAC/temp/minimal/minimal.cpp:8:135:beg:0x2da8
>>>>>>cb_gdb:
> next
sh: line 1: pause: command not found
/Volumes/Seagate/MAC/temp/minimal/minimal.cpp:9:157:beg:0x2db4
>>>>>>cb_gdb:
> next
/Volumes/Seagate/MAC/temp/minimal/minimal.cpp:10:169:beg:0x2db8
>>>>>>cb_gdb:
> cont
Program exited normally.
>>>>>>cb_gdb:
> quit

Title: Re: Mac Binaries
Post by: mandrav on May 19, 2006, 09:24:53 pm
Quote
"As written above...". Is that some sort of nasty reply? If so, I don't believe I deserve it. I'm trying the best I know how.

What's wrong with everyone these days? Why are you all so jumpy?  :?:  :|
I just pointed out that I asked for it. And I even told you where to enable it. I didn't imply anything more or less...

Title: Re: Mac Binaries
Post by: afb on May 19, 2006, 10:18:46 pm
GDB 5.3 is now working with CB OSX 10.3

mcCodeBlocks GDB needs a "run" not a "start". I'll include this in the patches I'm working on.

Oops, that explains why I couldn't see the problem with GDB (had it patched locally...)

Anyway, it sounds a whole lot better than having to drop Mac OS X 10.3 support ! :-)
Title: Re: Mac Binaries
Post by: sethjackson on May 19, 2006, 10:25:53 pm
What's wrong with everyone these days? Why are you all so jumpy?  :?:  :|

OT: Yeah I have noticed this too...... What is the dea (maybe everyone is tired/has too much to do or something)l?  :?: I don't mean to offend anyone so please take my comments lightly........

Oh well looks like Pecan has fixed his problem (and got C::B to run on OS X 10.3). :D
Title: Re: Mac Binaries
Post by: Game_Ender on May 20, 2006, 06:35:45 am
Can't wait till Monday, when I get into work I will see if can get CB to compile on our new Intel iMac, the Core Duo is fast.  If everything turns out good, hopefully I can use it with/instead of xcode.
Title: Re: Mac Binaries
Post by: skyjunky on May 21, 2006, 10:55:11 pm
I've been trying to get cb working on mac intel.
It built but crashes at startup after clicking OK on the compiler dialog.
bool wxPropertyGrid::SetFont ( const wxFont& font ) in propgrid.cpp did not compile, res was out of scope, but simple to fix.

version 2481.
I did try the with the source of the 1.0-rc2 but it would not build (configure failed).

error report attached.



[attachment deleted by admin]
Title: Re: Mac Binaries
Post by: skyjunky on May 23, 2006, 12:52:41 am
It starts up if I disable the project wizard plugin.
The editor basically works. I did not try compiling or debugging.
I created a basic project and added a few files.

There are some problems.

Settings->environment causes a crash.
Expanding items in the management panel does not repaint if the panel already has focus. You have to resize or change focus to force a repaint. The scrollbars do not update unless you try to select an item on the edge of the panel.
Draging files into the main window causes a crash.
Cannot quit cb if a project is open.
Title: Re: Mac Binaries
Post by: Pecan on June 22, 2006, 03:13:24 am
Has anyone been successful building wxMac2.6.3 on OS X 10.4 having installed XCode 2.x? And using the ./configure method?

I get error after compiler error. Is it my system or is it wxWidgets?

Amazingly XCode will build it, but not ./configure.

thanks
pecan
Title: Re: Mac Binaries
Post by: Pecan on June 25, 2006, 05:38:42 pm
I can nolonger compile svn codeblocks on OS X 10.3.

threadpool.cpp crashes compiler gcc 3.3. I've tried -O0 and -fno-fast-math.
These flags do not seem to avoid the crash when CB is compiling CB itself.

Has anyone got any ideas?

thanks
pecan


Code: [Select]
g++ -Wall -g `wx-config --cflags` -fmessage-length=0 -fexceptions -Winvalid-pch -fPIC -DcbDEBUG -DCB_PRECOMP -D__WXMAC__ -O0 -fno-fast-math  -Isdk/wxscintilla/include -Isdk -Isdk/as/source -Isdk/as/include -Isdk/propgrid/include -Isdk/wxFlatNotebook -I/usr/include -Isdk -c sdk/cbthreadpool.cpp -o .objs/sdk/cbthreadpool.o
[address=45e533a4 pc=000e6b3c]
sdk/cbthreadpool.cpp: In member function `bool cbThreadPool::WaitingThread()':
sdk/cbthreadpool.cpp:151: internal compiler error: Segmentation Fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://developer.apple.com/bugreporter> for instructions.
Process terminated with status 1 (1 minutes, 19 seconds)
1 errors, 0 warnings
 
Title: Re: Mac Binaries
Post by: Pecan on June 28, 2006, 01:24:00 am
I can nolonger compile svn codeblocks on OS X 10.3.

threadpool.cpp crashes compiler gcc 3.3. I've tried -O0 and -fno-fast-math.
These flags do not seem to avoid the crash when CB is compiling CB itself.

Has anyone got any ideas?

Ceniza has generously spent the time to restructure the cbThreadPool.cpp/h code to enable us gcc 3.3 users to compile CodeBlocks without the segfaults
(svn 2617).

I've compiled and tested the code on OS X 10.3 with gcc3.3 with no problems.

Thank you Ceniza
pecan
Title: Re: Mac Binaries
Post by: Game_Ender on June 28, 2006, 03:22:03 am
If I had the proper autotools version could I compile SVN with wxWidgets 2.6.3 on OS X 10.4?  I don't really have much time to play around on the mac I use at work, but if it compiled straight from SVN at least I could keep the CB project file up to date for my project.
Title: Re: Mac Binaries
Post by: Pecan on June 28, 2006, 05:05:55 am
If I had the proper autotools version could I compile SVN with wxWidgets 2.6.3 on OS X 10.4?  I don't really have much time to play around on the mac I use at work, but if it compiled straight from SVN at least I could keep the CB project file up to date for my project.

I had a terrible time trying to do this. Never succeeded.

Finally compiled by makeing a handmade .cbp and using an
afb mac binary as a bootstrap.

I also was unable to get  good compilation of wx2.6.3 using ./configure. and gcc 4.

I have yet to try that with with the OSX3.3SDK.

Since 2.6.3 compiles just fine under 10.3 with gcc3.3, I suspect using the 3.3SDK and select_gcc 3.3 might work on Tiger. I plan to give it a try soon.

 

Title: Re: Mac Binaries
Post by: Game_Ender on July 11, 2006, 08:20:31 pm
I was trying to confirm that all the needed patches have made it into the the CB source.
Title: Re: Mac Binaries
Post by: Pecan on July 12, 2006, 03:14:36 am
I was trying to confirm that all the needed patches have made it into the the CB source.

No, some still remain uncommitted.
http://developer.berlios.de/patch/?func=detailpatch&patch_id=1177&group_id=5358