C::B working on Intel MAC OS X, but requires Makefile changes

[Paco.Blasco]

Hi all:

In order to compile C::B on Intel Macs, using native wx support (_WXMAC_), I did some changes:
- Patch the code for the problem with InfoWindow (attached file thanks to Pecan)
- Modify all plugins Makefiles changing the line "LDFLAGS="  by "LDFLAGS=`wx-config --libs`

I understand that the InfoWindow problem is due to limitations on wx, but I believe that (configure.in? Makefile.in?) must be changed in order to get a right link process.

Thx.


[attachment deleted by admin]

[Game_Ender]

If you have a set of steps that gets codeblocks compiling on Mac OS X with autotools, please post it on the wiki.  With the way things are going it looks like it might be possible to have some kind of preliminary Mac support in the next release.  I developing with wxWidgets on OS X is my day job, and could help working out the issues related to that platform but I don't have time to slog through autotools and get it compiling.

[Paco.Blasco]

Of course.
Once wxWidgets are compiled for mac, you can do next steps:
- Patch the code with the previous firmware
- Call bootstrap
- ./configure --enable-shared
- Add to LDLIBS "`wx-config --libs`"

I must to probe with LDFLAGS="`wx-config --libs`" ./configure

Is it enough?

[Game_Ender]

Where did you get the most up to date autotools versions?  Darwin ports?

EDIT: By firmware do you mean you have to downgrade the firmware you Mac, or do you mean apply the patch you have attached to your post above.  You apply the patch to the current SVN head correct?

[Paco.Blasco]

Yes. I used DarwinPorts. I have also Fink, but some command line tools are updated on DarwinPorts.
Also I've used the wxWidgets version of Darwinports to compile CodeBlocks.

Have you more information about DarwinPorts? Can be used?
My C::B for OSX don't compile any project and it have a lot of problems in order to manage projects.
I'm compiling the debig version in order to test the check the program.

[skyjunky]

I've managed to get it to build (revision 2879)
The linking problem can be fixed by:

Index: configure.in
===================================================================
--- configure.in        (revision 2879)
+++ configure.in        (working copy)
@@ -77,7 +77,7 @@
 dnl            CPPFLAGS="$CPPFLAGS $WX_CPPFLAGS"
 dnl            CXXFLAGS="$CXXFLAGS $WX_CXXFLAGS_ONLY"
 dnl            CFLAGS="$CFLAGS $WX_CFLAGS_ONLY"
-dnl            LIBS="$LIBS $WX_LIBS"
+LIBS="$LIBS $WX_LIBS"
 
 AC_SUBST(CPPFLAGS)
 AC_SUBST(CXXFLAGS)

I'm using autoconf 2.59 built from source.
glibtool 1.5.20 from darwin ports.
automake etc. 1.7.9 from source.
wxMac 2.6.3 built from source with --enable-unicode in addition to the other options in the build instructions.
gcc 4.01 (xcode 2.4 installed)

There are enough problems to make it unusable. The exception handlers do work well however.
If I find time I'll have a look at the code.

[afb]

Oops, saw the infowindow patch in this topic too late.

I posted a similar (but simpler) workaround patch to:
http://developer.berlios.de/patch/?func=detailpatch&patch_id=1376&group_id=5358

[Paco.Blasco]

I've compiled it, and I have now a bundle application....that crashes too easily on my MBP.
We must to fix C::B on this platform.
Or we must to get a right build process, I don0t know.

Can anyone compile with C::B on Intel-Mac platform (x86 no PPC)?

Thx!!

[afb]

Not that it's stable here either, but it usually succeeds in building at least.
The main things missing are plugins (AngelScript) and double-clicking etc.

[Paco.Blasco]

Then I have problems. Is it possible to send me your app bundle (compressed)?
I can use it as a base to compile C::B with C::B.

[sethjackson]

Not that it's stable here either, but it usually succeeds in building at least.
The main things missing are plugins (AngelScript) and double-clicking etc.

AngelScript? Code::Blocks doesn't use that anymore...... :?

[afb]

AngelScript? Code::Blocks doesn't use that anymore...... :?

Great. one less thing to worry about... :-)

Wonder what else happened since last time ?

[afb]

Then I have problems. Is it possible to send me your app bundle (compressed)?
I can use it as a base to compile C::B with C::B.

I have uploaded rev 2886 to BerliOS, was hoping to get it deployed ?

http://developer.berlios.de/project/showfiles.php?group_id=5358&release_id=9217

[Paco.Blasco]

Sorry, but I didn't find the link.
Is the PPC executable? Revision 2411?
Please, post the right link!!!!
I want to probe it!!!!!!!!

ARGHHHHHHHHHHHHHHHH!

[afb]

Please, post the right link!!!!
I want to probe it!!!!!!!!

I don't have release priviledges, so it's left in "incoming".
Will email you a temporary location in private, for now...

[sethjackson]

AngelScript? Code::Blocks doesn't use that anymore...... :?

Great. one less thing to worry about... :-)

Wonder what else happened since last time ?

Lots.
Anyways C::B uses Squirrel for scripting now anyways.

[afb]

Okay, hope it won't be another 6 months until I check in again :-)

(Hmm, still no RC3 ? I would have thought that to be out by now)

[Paco.Blasco]

Thanks. It works better than rev2411, but Rosetta is not working fine with this executable.
When I used it I can n ot create new projects, it can not open (right) created projects....It doesn't compile....
Am I the only one that it is trying to work with C::B on IntelMacs?
 

[afb]

I am currently using Mac OS X 10.3 on PPC still, since Tiger has been so buggy for me.

[Paco.Blasco]

Ops...I'm working on Tiger with IntelMac.
 :?

[afb]

Once I get the funds for a new Mac, I'll upgrade to Tiger and Intel as well...
Meanwhile I am running Fedora Core instead, which works just fine on Macs.

[afb]

Thanks. It works better than rev2411, but Rosetta is not working fine with this executable.

I'll see if I can build a Universal Binary as well, that might work better for you.

[mandrav]

Then I have problems. Is it possible to send me your app bundle (compressed)?
I can use it as a base to compile C::B with C::B.

I have uploaded rev 2886 to BerliOS, was hoping to get it deployed ?

http://developer.berlios.de/project/showfiles.php?group_id=5358&release_id=9217

Oops, sorry I missed it. It's in the Files section now. Thanks .

[Paco.Blasco]

Thanks. It works better than rev2411, but Rosetta is not working fine with this executable.

I'll see if I can build a Universal Binary as well, that might work better for you.

It will be very good if you can build an Universal binary. At the moment, I have no too much solutions to get a C::B for my Mac. PPC version has a lot of problems (due to Rosetta I think), and Intel version is not compiling too much right (it is unusable).
Anyone can help us to create a check list to begin to solve all problems of C::B on Tiger/Intel?
It is complicated for anyone that has been never debug the C::B code.
I need a small help in order to begin to patch C::B.

Thx.

[afb]

I don't see any real problems with an Universal Binary / on Intel,
just need to get it wrapped and then tested on a real Intel as well.

But I would also be interested in what kinds of problems people are
seeing, if they are specific to Intel or if they're more of generic Mac.

[Auria]

I remember i had downloaded the previous version you posted (24 something?) i don't quite remember this version, but i think it was more functional than this one :? almost nothing reacts. 'new file' doesn't react, 'new project' doesn't either. trying to open various 'configure' options trigger no reaction either. So it  looks nice, but is yet impossible to use on its own...

However i was able to create a file in a third-part text-editor, then open it in code blocks and build. The text in the console and build messages is so small it's almost impossible to read

i'm on PPC, mac OS X 10.3.9 ( if i was just a little bit better at programming i could trying helping, but i'm not ) Well good job anyway keep trying i'll try helping if i can :lol

[afb]

I remember i had downloaded the previous version you posted (24 something?) i don't quite remember this version, but i think it was more functional than this one :? almost nothing reacts. 'new file' doesn't react, 'new project' doesn't either. trying to open various 'configure' options trigger no reaction either. So it  looks nice, but is yet impossible to use on its own...

Yeah, I'm trying to run it through the debugger here (in debug build) to see what I can find...

Just thought I'd upload, once I got it to build ;-)

[afb]

The 2890 revision looks a whole lot better for project/file "Open"...
So I guess it was just one of those "nightly" / reorganization issues.

Or it was the zip files containing old (!) xrc files when doing a build,
and it got better when wiping all the old files out with a clean build.

[afb]

The LDFLAGS="`wx-config --libs`" ./configure workaround doesn't work for Universal builds, as it will pass the -isysroot /Developer/SDKs/MacOSX10.4u.sdk to GCC twice - making it cry and killing the build.

Will patch all the Makefile.am for the plugins instead.

The issue is that you can't link with libcodeblocks.dylib, without also linking with the wxWidgets libraries that it (indirectly) requires. A little Mac OS X quirk there...

Code

ld: object_file illegal reference to symbol: ***
defined in indirectly referenced dynamic library: ***

[afb]

'new file' doesn't react, 'new project' doesn't either. trying to open various 'configure' options trigger no reaction either. So it  looks nice, but is yet impossible to use on its own...

However i was able to create a file in a third-part text-editor, then open it in code blocks and build. The text in the console and build messages is so small it's almost impossible to read

These issues are fixed in the 2890 build, which should be available on BerliOS shortly.

[Auria]

These issues are fixed in the 2890 build, which should be available on BerliOS shortly.

This one doesn't even open

This is what it prints when i run it via terminal:

can't open library: /usr/local/lib/libcodeblocks.0.dylib  (No such file or directory, errno = 2)
Trace/BPT trap

Though i have no experience with dylibs so i might have done something  dumb (or maybe the error message is meaningless)

[afb]

It is supposed to be bundled with the application...
(CodeBlocks.app/Contents/lib/libcodeblocks.0.dylib)

It doesn't happen to be in a directory with spaces ?

[afb]

This one doesn't even open

This is what it prints when i run it via terminal:

By the way, what do you mean with "via terminal" ?
It is supposed to just be double-clicked in the Finder...

In the Terminal, you need to use "open CodeBlocks.app"

[Auria]

If i open it by double-clicking nothing happens. The icon briefly appears in the dock and goes away.

Forget the thing i wrote about the terminal is probably meaningless, i didn't think enough and the idea i had didn,t make sense. I was trying to get an error message but realised shortly after my very limiotd knowledge didn't allow me to make any assertion on what was wrong

in fact i just don't know why it doesn't work

[afb]

Any messages from GUI apps should show in the system log,
which can be viewed using /Applications/Utilities/Console.app

I've duplicated a problem with the current script hack when run
in directories with spaces (missing quotes), and that'll be fixed.

[Auria]

Any messages from GUI apps should show in the system log,
which can be viewed using /Applications/Utilities/Console.app

I've duplicated a problem with the current script hack when run
in directories with spaces (missing quotes), and that'll be fixed.

That's it i moved it and it works

thanks