Building C::B from SVN on OS X

[matioupi]

Hello,

I'd like to make a recent build of C::B on OS X
I got the SVN tree
./boostrap
make
everything seem to go fine... but then I'm stucked... how to build the .app package (or even just run from commande line)

I also got wxWidget 2.8.8 from their website... what's the appropriate option to configure it for C::B ?

Can somebody help ?

regards,

Mathieu

[stahta01]

I am not an Mac person, but have you read this

http://wiki.codeblocks.org/index.php?title=Installing_Code::Blocks_from_source_on_Mac_OS_X

NOTE: The directions are old, replace wx-2.6 with wx-2.8

Tim S

[matioupi]

Thank, I searched but did not find this link...
I did managed to build both wx 2.8.8 and the latest svn (5148) with the last Xcode tools (3.1) and gcc 4.2.1...
And the software do start !
I'll test all that a little now !

[matioupi]

Build is available (for 30 days) at the following location :

http://dl.free.fr/rA5IM2j1I

Regards,

Mathieu
--
http://www.incub.net/

[matioupi]

I spent a little while trying the SVN build... and must say it is not of any use...

It locks and then crash all the time... impossible to load a former project or workspace...

(I tried resetting the configuration file but it did not changed anything)...

I guess some work for OS X compatibility has to be done... how may I help ?

Regards,

Mathieu

[matioupi]

New build (with all plugins and solved a small issue with location of dylib files and install_name_tool)

http://dl.free.fr/plVextNbd/CodeBlocksSVN-OSX-5153.zip

It seems to have issues with parsers (I guess for autocompletion)... Most of my former projects do crash at load :
An exemple of the report is below :

Regards,

Mathieu

Thread 5 Crashed:
0   libSystem.B.dylib                0x950ffdbe __semwait_signal_nocancel + 10
1   libSystem.B.dylib                0x950f1c87 usleep$NOCANCEL$UNIX2003 + 61
2   libSystem.B.dylib                0x9511348b abort + 85
3   libwx_macu-2.8.0.dylib           0x00add716 wxFatalSignalHandler + 38
4   libSystem.B.dylib                0x9508b09b _sigtramp + 43
5                                 0xffffffff 0 + 4294967295
6   libwx_macu-2.8.0.dylib           0x00a6ab3c wxStat(wchar_t const*, stat*) + 44
7   libwx_macu-2.8.0.dylib           0x00a6ab9a wxFileExists(wxString const&) + 26
8   libcodecompletion.so             0x1697e242 Parser::FindFileInIncludeDirs(wxString const&, bool) + 226 (parser.cpp:792)
9   libcodecompletion.so             0x1697e5ee Parser::FindFirstFileInIncludeDirs(wxString const&) + 126 (parser.cpp:773)
10  libcodecompletion.so             0x1697e7ce Parser::GetFullFileName(wxString const&, wxString const&, bool) + 126 (parser.cpp:821)
11  libcodecompletion.so             0x16981721 ParserThread::HandleIncludes() + 241 (parserthread.cpp:948)
12  libcodecompletion.so             0x16989078 ParserThread::DoParse() + 9032 (parserthread.cpp:486)
13  libcodecompletion.so             0x1698b7eb ParserThread::Parse() + 155 (parserthread.cpp:351)
14  libcodecompletion.so             0x1698b841 ParserThread::Execute() + 17 (parserthread.h:75)
15  libcodeblocks.0.dylib            0x0054f7d8 cbThreadPool::cbWorkerThread::Entry() + 216 (thread.h:176)
16  libwx_macu-2.8.0.dylib           0x00acbb56 wxThreadInternal::MacThreadStart(void*) + 102
17  ...ple.CoreServices.CarbonCore   0x9454755b PrivateMPEntryPoint + 56
18  libSystem.B.dylib                0x9504f6f5 _pthread_start + 321
19  libSystem.B.dylib                0x9504f5b2 thread_start + 34

[matioupi]

More testing with this last build...
If I deactivate the follow GLOBAL includes on the C++ parser options, it do not crash anymore ! (yeah !)
(hope it gives some clues to the developpers... I'm trying to look into the code but that's a hard dive having to face C::B and wxMac a the same time !)

[matioupi]

It's me again... tonight, I tried rebuilding the 8.02 source (from the sourceforge tarball) against 2.8.8 wxWidgets (from wxWidget website) with Xcode 3.1 and gcc 4.2.1... The result is the same than with the trunk... really unstable... So I was wondering wich patches (if any) had been applied to wxWidget to generate the officiel OS X binaries ?
Can the packager or the C::B OS X guru make an apparition on the forum ;-) ?

Regards,

Mathieu

[Auria]

Can the packager or the C::B OS X guru make an apparition on the forum ;-) ?

I think he doesn't come often, his username is 'afb', if he doesnt come in a while maybe you can PM him
In any case, those crashes are weird, it doesn't crash so much on my mac (from my own SVN build, nothing special done to wx)

[matioupi]

In any case, those crashes are weird, it doesn't crash so much on my mac (from my own SVN build, nothing special done to wx)

Everything works fine (or seems to) with my builds (either the SVN or the 8.02, both linked against unmodified version of wx2.8. as soon as I disable the follow Global includes on the C++ parser option page...

If it is not disabled, then it crashes on loading almost any of my projects...

The strange thing is that it work even with this set on the officiel OSX8.02-p2 build... I'm wondering if it has not been "hardcoded disabled" but not reported on the source code...

Do your builds work with the follow GLOBAL INCLUDES ticked ?

Here are the configure options I used for wxWidgets-2.8.8 :

Code

mkdir osx-build
cd osx-build
../configure --enable-shared --enable-monolithic --enable-unicode --enable-optimise --enable-threads --with-mac --with-opengl --with-png=builtin --with-jpeg=builtin --with-tiff=builtin --with-expat=builtin
make
sudo make install

And here for CodeBlocks :

Code

./bootstrap
./configure --with-wxdir=/usr/local --with-wx-config=/usr/local/bin/wx-config --with-platform=macosx --with-contrib-plugins=all
make

have lunch tea&coffe&rest :-)

Code

sudo make install

And then the following script to repackage (and change the dynamic libraries install name) into CodeBlocks8.02-mybuild.app (with the appropriate plist and icons... CodeBlocks8.02-mybuild.app is a copy of the official CodeBlocks.app8.02 in wich I kept only icons and directory structure)

Code

#!/bin/sh

APPNAME=CodeBlocks8.02-mybuild.app

cp /usr/local/bin/codeblocks ./$APPNAME/Contents/MacOS/CodeBlocks
cp /usr/local/bin/cb_share_config ./$APPNAME/Contents/MacOS
cp /usr/local/bin/cb_console_runner ./$APPNAME/Contents/MacOS
cp /usr/local/bin/codesnippets ./$APPNAME/Contents/MacOS
cp /usr/local/lib/libwxsmithlib.0.dylib ./$APPNAME/Contents/MacOS
cp /usr/local/lib/libwx_macu-2.8.0.dylib ./$APPNAME/Contents/MacOS
cp /usr/local/lib/libcodeblocks.0.dylib ./$APPNAME/Contents/MacOS

install_name_tool -id @executable_path/libcodeblocks.0.dylib ./$APPNAME/Contents/MacOS/libcodeblocks.0.dylib
install_name_tool -id @executable_path/libwx_macu-2.8.0.dylib ./$APPNAME/Contents/MacOS/libwx_macu-2.8.0.dylib
install_name_tool -id @executable_path/libwxsmithlib.0.dylib ./$APPNAME/Contents/MacOS/libwxsmithlib.0.dylib

install_name_tool -change /usr/local/lib/libcodeblocks.0.dylib @executable_path/libcodeblocks.0.dylib ./$APPNAME/Contents/MacOS/CodeBlocks
install_name_tool -change /usr/local/lib/libwx_macu-2.8.0.dylib @executable_path/libwx_macu-2.8.0.dylib ./$APPNAME/Contents/MacOS/CodeBlocks
install_name_tool -change /usr/local/lib/libwxsmithlib.0.dylib @executable_path/libwxsmithlib.0.dylib ./$APPNAME/Contents/MacOS/CodeBlocks

install_name_tool -change /usr/local/lib/libcodeblocks.0.dylib @executable_path/libcodeblocks.0.dylib ./$APPNAME/Contents/MacOS/codesnippets
install_name_tool -change /usr/local/lib/libwx_macu-2.8.0.dylib @executable_path/libwx_macu-2.8.0.dylib ./$APPNAME/Contents/MacOS/codesnippets
install_name_tool -change /usr/local/lib/libwxsmithlib.0.dylib @executable_path/libwxsmithlib.0.dylib ./$APPNAME/Contents/MacOS/codesnippets

install_name_tool -change /usr/local/lib/libcodeblocks.0.dylib @executable_path/libcodeblocks.0.dylib ./$APPNAME/Contents/MacOS/cb_share_config
install_name_tool -change /usr/local/lib/libwx_macu-2.8.0.dylib @executable_path/libwx_macu-2.8.0.dylib ./$APPNAME/Contents/MacOS/cb_share_config
install_name_tool -change /usr/local/lib/libwxsmithlib.0.dylib @executable_path/libwxsmithlib.0.dylib ./$APPNAME/Contents/MacOS/cb_share_config

install_name_tool -change /usr/local/lib/libcodeblocks.0.dylib @executable_path/libcodeblocks.0.dylib ./$APPNAME/Contents/MacOS/cb_console_runner
install_name_tool -change /usr/local/lib/libwx_macu-2.8.0.dylib @executable_path/libwx_macu-2.8.0.dylib ./$APPNAME/Contents/MacOS/cb_console_runner
install_name_tool -change /usr/local/lib/libwxsmithlib.0.dylib @executable_path/libwxsmithlib.0.dylib ./$APPNAME/Contents/MacOS/cb_console_runner

install_name_tool -change /usr/local/lib/libwx_macu-2.8.0.dylib @executable_path/libwx_macu-2.8.0.dylib ./$APPNAME/Contents/MacOS/libcodeblocks.0.dylib
install_name_tool -change /usr/local/lib/libwxsmithlib.0.dylib @executable_path/libwxsmithlib.0.dylib ./$APPNAME/Contents/MacOS/libcodeblocks.0.dylib

install_name_tool -change /usr/local/lib/libcodeblocks.0.dylib @executable_path/libcodeblocks.0.dylib ./$APPNAME/Contents/MacOS/libwxsmithlib.0.dylib
install_name_tool -change /usr/local/lib/libwx_macu-2.8.0.dylib @executable_path/libwx_macu-2.8.0.dylib ./$APPNAME/Contents/MacOS/libwxsmithlib.0.dylib

cp -R /usr/local/share/codeblocks/ ./$APPNAME/Contents/Resources/share/codeblocks

for dotso in ./$APPNAME/Contents/Resources/share/codeblocks/plugins/*.so
do
#	install_name_tool -id $(basename $dotso) $dotso
	install_name_tool -change /usr/local/lib/libcodeblocks.0.dylib @executable_path/libcodeblocks.0.dylib $dotso
	install_name_tool -change /usr/local/lib/libwx_macu-2.8.0.dylib @executable_path/libwx_macu-2.8.0.dylib $dotso
	install_name_tool -change /usr/local/lib/libwxsmithlib.0.dylib @executable_path/libwxsmithlib.0.dylib $dotso
done

Does something looks strange to you in the method ?

[matioupi]

which compiler and compiler version do you use ?

i'm wondering if there could not be thread concurrent (and unprotected access) to WC2MB  wxWidgets (strconv.cpp) that mess-up things...
This would happen while reading filenames...

[matioupi]

in fact the patch was already in the wxWidgets svn for branch 2.8... but it is not in the 2.8.8 source tarball i used at the beginning !
That's not the first time i discover something that already been discovered... ;-)

[afb]

As noted in this thread, the patch* for wxString is mandatory for later versions of wxWidgets 2.8 and is what caused the (unpatched) release of Code::Blocks 8.04 to crash even if earlier versions of wxWidgets/CodeBlocks had been OK. Sad to hear it didn't make it into the 2.8.8 release...

* http://trac.wxwidgets.org/ticket/9045