Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Mac Binaries

<< < (14/25) > >>

afb:

--- Quote from: Game_Ender on May 04, 2006, 07:48:42 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.
--- End quote ---

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...

Pecan:

--- Quote from: 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.

--- End quote ---

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.

Sonic McTails:
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.

afb:

--- Quote from: Sonic McTails on May 05, 2006, 03:49:02 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.

--- End quote ---

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 ?

afb:

--- Quote from: Sonic McTails on May 05, 2006, 03:49:02 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.
--- End quote ---

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 ?

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version