Author Topic: Compiling on Mac OS X  (Read 45346 times)

grv575

  • Guest
Re: Compiling on Mac OS X
« Reply #30 on: August 31, 2005, 08:05:36 pm »
cool.  If it fails you can check:
http://sourceforge.net/mailarchive/message.php?msg_id=12014390
http://64.233.167.104/search?q=cache:5-CtyzHOu-wJ:lists.wxwidgets.org/archive/wxPython-mac/msg00438.html+%22section+difference+reference%22&hl=en&client=firefox-a

Does mac tiger support .a files, btw?  One thing I would try (if needed) is to build that libwxDockit.a file as a shared lib instead (.so) and also use -fPIC.

Based on googling, it looks like either an ABI issue (application binary interface - which varies from gcc version to version) or some CFLAGS flag that is missing and needed for the macos build to go.  So, re the ABI thing, it's best to compile wxWidgets yourself and then codeblocks because this guarantees that they both have the same ABI, since they were compiled with the same compiler version.  (e.g.
in a lot of cases you can't mix libraries or binaries from gcc 3.4 and gcc 3.3 or gcc 4.0 compiled code).

TheWizzard

  • Guest
Re: Compiling on Mac OS X
« Reply #31 on: August 31, 2005, 08:10:40 pm »
Ok,

I used fPIC and it failed, wxWidgets is self-built. I got plenty .a files in /usr/lib so I would say yes, os x supports them (and shared libs are .dynlib on os x, btw)

It's all compiled with gcc 3.3 (you can do gcc_select and choose between 3.3 and 4.0 on tiger) and I'll now try to recompile wx with the options listed on the wxPython-mac list.

TheWizzard

  • Guest
Re: Compiling on Mac OS X
« Reply #32 on: August 31, 2005, 08:55:07 pm »
w00t!

That worked. It now fails at astyle, I hope I can figure that out on my own.

*EDIT*

I can't. ;)

Quote
__Z19wxGetTopLevelParentP8wxWindow
__ZN10wxFontBaseD2Ev
__ZN10wxSpinCtrl8SetValueEi
__ZN12wxDialogBase11RemoveChildEP12wxWindowBase
__ZN12wxDialogBase12OnChildFocusER17wxChildFocusEvent
__ZN12wxDialogBase14SetDefaultItemEP8wxWindow
__ZN12wxDialogBase17SetTmpDefaultItemEP8wxWindow
__ZN12wxDialogBase24SetFocusIgnoringChildrenEv
__ZN12wxDialogBase4InitEv
__ZN12wxDialogBase8SetFocusEv
__ZN12wxEvtHandler12ProcessEventER7wxEvent
__ZN12wxEvtHandler15DoSetClientDataEPv
__ZN12wxEvtHandler16SearchEventTableER12wxEventTableR7wxEvent
__ZN12wxEvtHandler17DoSetClientObjectEP12wxClientData
__ZN12wxStringBase4nposE
__ZN12wxStringBase8InitWithEPKcmm
__ZN12wxStringBaseaSEPKc
__ZN12wxStringBaseaSERKS_
__ZN12wxWindowBase10GetCaptureEv
__ZN12wxWindowBase10InitDialogEv
__ZN12wxWindowBase12LayoutPhase1EPi
__ZN12wxWindowBase12LayoutPhase2EPi
__ZN12wxWindowBase12SetValidatorERK11wxValidator
__ZN12wxWindowBase12TryValidatorER7wxEvent
__ZN12wxWindowBase14DoSetSizeHintsEiiiiii
__ZN12wxWindowBase14MoveConstraintEii
__ZN12wxWindowBase14UpdateWindowUIEl
__ZN12wxWindowBase16DoMoveInTabOrderEP8wxWindowNS_8MoveKindE
__ZN12wxWindowBase16DoSetVirtualSizeEii
__ZN12wxWindowBase17InheritAttributesEv
__ZN12wxWindowBase17SetSizeConstraintEiiii
__ZN12wxWindowBase18SetConstraintSizesEb
__ZN12wxWindowBase19SetVirtualSizeHintsEiiii
__ZN12wxWindowBase20TransferDataToWindowEv
__ZN12wxWindowBase22TransferDataFromWindowEv
__ZN12wxWindowBase25GetClassDefaultAttributesE15wxWindowVariant
__ZN12wxWindowBase3FitEv
__ZN12wxWindowBase6LayoutEv
__ZN12wxWindowBase7DoPhaseEi
__ZN12wxWindowBase8AddChildEPS_
__ZN12wxWindowBase8NavigateEi
__ZN12wxWindowBase8ReparentEPS_
__ZN12wxWindowBase8ValidateEv
__ZN12wxWindowBase9FindFocusEv
__ZN12wxWindowBase9FitInsideEv
__ZN12wxWindowBase9MakeModalEb
__ZN12wxWindowBase9TryParentER7wxEvent
__ZN13wxXmlResource10LoadDialogEP8wxDialogP8wxWindowRK8wxString
__ZN13wxXmlResource3GetEv
__ZN13wxXmlResource8GetXRCIDEPKc
__ZN16wxEventHashTableC1ERK12wxEventTable
__ZN16wxEventHashTableD1Ev
__ZN18wxControlContainerC1EP8wxWindow
__ZN19wxTopLevelWindowMac11MacActivateElb
__ZN19wxTopLevelWindowMac12DoMoveWindowEiiii
__ZN19wxTopLevelWindowMac14ShowFullScreenEbl
__ZN19wxTopLevelWindowMac15ClearBackgroundEv
__ZN19wxTopLevelWindowMac17MacPerformUpdatesEv
__ZN19wxTopLevelWindowMac19MacCreateRealWindowERK8wxStringRK7wxPointRK6wxSizelS2_
__ZN19wxTopLevelWindowMac20RequestUserAttentionEi
__ZN19wxTopLevelWindowMac21MacSetBackgroundBrushERK7wxBrush
__ZN19wxTopLevelWindowMac22MacGetContentAreaInsetERiS0_S0_S0_
__ZN19wxTopLevelWindowMac36MacInstallTopLevelWindowEventHandlerEv
__ZN19wxTopLevelWindowMac4InitEv
__ZN19wxTopLevelWindowMac5LowerEv
__ZN19wxTopLevelWindowMac5RaiseEv
__ZN19wxTopLevelWindowMac7IconizeEb
__ZN19wxTopLevelWindowMac7RestoreEv
__ZN19wxTopLevelWindowMac7SetIconERK6wxIcon
__ZN19wxTopLevelWindowMac8MaximizeEb
__ZN19wxTopLevelWindowMac8SetShapeERK8wxRegion
__ZN19wxTopLevelWindowMac8SetTitleERK8wxString
__ZN19wxTopLevelWindowMacD2Ev
__ZN20wxTopLevelWindowBase16DoUpdateWindowUIER15wxUpdateUIEvent
[...]
« Last Edit: August 31, 2005, 09:09:21 pm by TheWizzard »

grv575

  • Guest
Re: Compiling on Mac OS X
« Reply #33 on: August 31, 2005, 09:03:55 pm »
Well if that's the only part that doesn't work (it's a plugin for C/C++ source code autoformatting - i.e. it reformat all your source according to ANSI guidelines, or K&R or whatever) then maybe skip that plugin.  Good to know most of the stuff should't be too difficult to get working on macs without major changes.

TheWizzard

  • Guest
Re: Compiling on Mac OS X
« Reply #34 on: August 31, 2005, 09:13:01 pm »
Well ok,

this is what I get with CompilerGCC:

Quote
Linking shared library devel/share/CodeBlocks/plugins/libcompilergcc.dynlib...
ld: common symbols not allowed with MH_DYLIB output format with the -multi_module option
.objs/2.6/plugins/compilergcc/depslib/src/depslib.o definition of common _g_stats (size 12)
/usr/bin/libtool: internal link edit command failed
make: *** [devel/share/CodeBlocks/plugins/libcompilergcc.dynlib] Error 1

I don't understand that message. Whats MH_DYLIB and -multi_module?

*EDIT*
DebuggerGDB - same as Astyle
CodeCompletion - same as Astyle
ClassWizard - same as Astyle
DefMimeHandler - same as Astyle
PluginWizard - same as Astyle
ToDo - compiles
« Last Edit: August 31, 2005, 09:18:55 pm by TheWizzard »

takeshimiya

  • Guest
Re: Compiling on Mac OS X
« Reply #35 on: August 31, 2005, 09:13:55 pm »
Yeah, makefiles tend to get outdated, especially Makefile.unix. That's what you get when the usual way to build Code::Blocks is to use the C::B project file ;).

Yes, the makefiles for compiling C::B are always outdated in CVS (not a good thing for an IDE, which you can't compile if you don't have the IDE itself :cry:)

That's why I propose auto-generate makefiles when saving:
http://forums.codeblocks.org/index.php/topic,831.0.html

xjluo

  • Guest
Re: Compiling on Mac OS X
« Reply #36 on: September 01, 2005, 02:29:10 am »
To TheWizzard:

Check your Makefile, if you find:
plugin_???_LDFLAGS = $(plugin_???_GLOBAL_LDFLAGS)

replace with following:
plugin_???_LDFLAGS = $(plugin_???_GLOBAL_LDFLAGS) $(plugin_???_PROJECT_LDFLAGS)

Then plugins will be linked. They forgot to link wxWidgets libraries to these plugins.


xjluo

  • Guest
Re: Compiling on Mac OS X
« Reply #37 on: September 01, 2005, 02:43:58 am »
The CompilerGCC error solution:

1. Change directory to plugins/compilergcc/depslib/src
    rename cache.c to cache.inc
    rename headers.c to header.inc
    rename depslib.c to depslib.inc
2. Create new empty file cache.c, headers.c
3. Create new file depslib.c with following lines:
========BEGIN==========
#include "depslib.inc"
#include "headers.inc"
#include "cache.inc"
========END==========
4. Edit headers.inc and cache.inc, delete all repeated header files (compared with depslib.inc) including:
jam.h hash.h lists.h newstr.h depslib.h (in cache.inc)
jam.h hash.h lists.h newstr.h headers.h depslib.h (in headers.inc)
and following line:
extern struct depsStats g_stats; (in both files)
5. Edit depslib.inc:
Find this line: struct depsStat g_stats;
Replace with: static struct depsStat g_stats;

CompilerGCC plugin should be linked.

grv575

  • Guest
Re: Compiling on Mac OS X
« Reply #38 on: September 01, 2005, 02:46:44 am »
thewizard: that -multi-module error was covered earlier in the thread (reply#24).
Need to pass -single I think.

xjluo

  • Guest
Re: Compiling on Mac OS X
« Reply #39 on: September 01, 2005, 03:04:37 am »
I have done all previous steps. Code::Blocks and all plugins were generated. Finally, I got a segfault on running Code::Blocks.

The Mac compiler and linker settings are quite different with Linux versions. I rewrite the Makefile based on a Makefile template which I used on several projects (on Mac/Linux/Windows). The modules under sdk were statically linked into codeblocks. But, I got a segfault again after the splash window. :(

Anybody can explain following:
Are plugins neccessary?
Can sdk files be statically linked?
Which version of gcc should be used?

Thanks a lot.

BTW, in the following sdk files,
editormanager.cpp messagemanager.cpp newfromtemplatedlg.cpp projectmanager.cpp
They all use the wx class wxImageList. You have to add:
#include <wx/wx.h>
before all other header files. Otherwise, you will get a link error about wxGenericImageList. The file wx.h implicitly includes platform.h where a macro named __WXMAC_CARBON__ is defined. The macro __WXMAC_CARBON__ decides wether a Mac version of wxImageList will be used.
« Last Edit: September 01, 2005, 03:09:09 am by xjluo »

xjluo

  • Guest
Re: Compiling on Mac OS X
« Reply #40 on: September 01, 2005, 03:20:09 am »
Two suggestions to project developers,

1. If you want to use wx classes in your file, please insert following line
#include <wx/wx.h>
before all other header files. wx.h implicitly includes platform.h and many other header files where a lot of important macros and other things are defined.

2. In your custom header files, please put your codes inside
#ifndef __XXX_H__
#define __XXX_H__
// put your own codes here
#endif __XXX_H__
or, you can also use pragma or other mechanism to avoid header files being iteratively/repeatedly included.


Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: Compiling on Mac OS X
« Reply #41 on: September 01, 2005, 03:43:49 am »
O.O there are files with those missing?  :shock:

Yikes. Which files?

xjluo

  • Guest
Re: Compiling on Mac OS X
« Reply #42 on: September 01, 2005, 03:48:27 am »
grv575 is right.

Append a "-single_module" option to plugin_CompilerGCC_PROJECT_LDFLAGS variable will get rid of the link error on plugin CompilerGCC.
My previous solution is too ugly. :)

xjluo

  • Guest
Re: Compiling on Mac OS X
« Reply #43 on: September 01, 2005, 03:54:41 am »
editormanager.cpp messagemanager.cpp newfromtemplatedlg.cpp projectmanager.cpp inside sdk need wx.h to be included.

Header files inside plugins/compilergcc/depslib/src have no iteratively include avoiding mechanism.

grv575

  • Guest
Re: Compiling on Mac OS X
« Reply #44 on: September 01, 2005, 04:02:54 am »
xjluo: gccplugin needs to compile/link (but cb should still load ok without it?)  the rest are optional.
You said you seta crash.  Could you post the codeblocks.rpt stack trace file?