Author Topic: Mac Binaries  (Read 83305 times)

Offline afb

  • Developer
  • Lives here!
  • *****
  • Posts: 884
Re: Mac Binaries
« Reply #60 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
#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
#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 ?

Offline afb

  • Developer
  • Lives here!
  • *****
  • Posts: 884
Re: Mac Binaries
« Reply #61 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).

Offline afb

  • Developer
  • Lives here!
  • *****
  • Posts: 884
Re: Mac Binaries
« Reply #62 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 (!) )

Offline Game_Ender

  • Lives here!
  • ****
  • Posts: 551
Re: Mac Binaries
« Reply #63 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.

Offline afb

  • Developer
  • Lives here!
  • *****
  • Posts: 884
Re: Mac Binaries
« Reply #64 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.

Offline afb

  • Developer
  • Lives here!
  • *****
  • Posts: 884
Re: Mac Binaries
« Reply #65 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...

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2750
Re: Mac Binaries
« Reply #66 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


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.
« Last Edit: May 04, 2006, 08:50:26 pm by Pecan »

Offline Sonic McTails

  • Multiple posting newcomer
  • *
  • Posts: 12
Re: Mac Binaries
« Reply #67 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.
« Last Edit: May 05, 2006, 07:00:03 am by Sonic McTails »

Offline afb

  • Developer
  • Lives here!
  • *****
  • Posts: 884
Re: Mac Binaries
« Reply #68 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 ?

Offline afb

  • Developer
  • Lives here!
  • *****
  • Posts: 884
Re: Mac Binaries
« Reply #69 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 ?

Offline Sonic McTails

  • Multiple posting newcomer
  • *
  • Posts: 12
Re: Mac Binaries
« Reply #70 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.

Offline afb

  • Developer
  • Lives here!
  • *****
  • Posts: 884
Re: Mac Binaries
« Reply #71 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 ?

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2750
Re: Mac Binaries
« Reply #72 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.
« Last Edit: May 05, 2006, 02:34:44 pm by Pecan »

Offline afb

  • Developer
  • Lives here!
  • *****
  • Posts: 884
Re: Mac Binaries
« Reply #73 on: May 05, 2006, 02:38:41 pm »
BTW; I uploaded "codeblocks-rev2411_macppc.zip" to BerliOS

Offline Sonic McTails

  • Multiple posting newcomer
  • *
  • Posts: 12
Re: Mac Binaries
« Reply #74 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/
« Last Edit: May 05, 2006, 03:22:55 pm by Sonic McTails »