Thanks for your two replies, Tim and Morten. I'm going to restart from the beginning today, taking care of the key points you indicate, Morten... I'll tell you the result of course...
--
EDIT : At this time, I've built and installed wx 2.8. So, an intermediary point (may help OSX-newbies like me - lol) :
- I've cleaned-up the system removing all wx dylib and headers under /usr/local (and bin/wxrc-28 too)
- To push a little, I've searched for all the file with *wx* in the partition (so, I see some in Xcode tree, OSX SDK 10.5 and 10.6, and also wxPerl and wxPython)... I didn't deleted anything.
- From wxWidgets 2.8.12 source base, I ran this (done manually in terminal, but could be a shell script like this) :
#!/bin/sh
mkdir ./shared_release
cd ./shared_release
../configure CFLAGS="-arch i386" CXXFLAGS="-arch i386" CPPFLAGS="-arch i386" LDFLAGS="-arch i386" OBJCFLAGS="-arch i386" OBJCXXFLAGS="-arch i386" --enable-macosx_arch=i386 --enable-unicode --enable-shared --enable-monolithic --disable-debug --prefix=/usr/local
Also, here, note that I've provided "--prefix=/usr/local", but, from what I've read around, it seems to be the default location where OSX will install anyway. Indicating-it, we're sure !
The final configure report was (copy/paste) :
-----------------------------------------------------------------
Configured wxWidgets 2.8.12 for `i686-apple-darwin10.8.0'
Which GUI toolkit should wxWidgets use? mac
Should wxWidgets be compiled into single library? yes
Should wxWidgets be compiled in debug mode? no
Should wxWidgets be linked as a shared library? yes
Should wxWidgets be compiled in Unicode mode? yes
What level of wxWidgets compatibility should be enabled?
wxWidgets 2.4 no
wxWidgets 2.6 yes
Which libraries should wxWidgets use?
jpeg builtin
png builtin
regex builtin
tiff builtin
zlib sys
odbc no
expat sys
libmspack no
sdl no
-----------------------------------------------------------------
Then, I ran "make" and it produced this content in the "<wx>/shared/release" directory :
libwx_macu-2.8.0.8.0.dylib
libwx_macu-2.8.0.dylib
libwx_macu-2.8.dylib
libwx_macu-2.8
libwxpng-2.8.a
libwxregexu-2.8.a
libwxtiff-2.8.a
Finally, I've done a "sudo make install" and things well appeared under /usr/local/lib, include and bin, but the dylib I see here (under /usr/local/lib) are :
libwx_macu-2.8.0.8.0.dylib
libwx_macu-2.8.0.dylib
libwx_macu-2.8.dylib
So, why these version numbers in libwx_macu-2.8.0.8.0.dylib and libwx_macu-2.8.0.dylib ? Why not 2.8.12 ? You've seen-it in a first pass, Morten, but, now, I wonder if it's not a problem of versionning in the produced lib (maybe forgotten to update number in 2.8.12 release)... Or, still a conflict (confusion) with something in my system (since it remains wx dylib in the Xcode tree, with SDK's, even if removed at system and local-wide) ? Under windows, produced DLL are numbered 28 : this way, we don't know if it's 2.8.12 or 2.8.n, but we don't care...
Well, I'll run the building sequence for Code::Blocks (ie. bootstrap, configure, make), but I would like to have your opinion on these dylib numbers ? The underlying question being : is that "normal" (the wanted behavior) ?
PS : sorry for eventual typo, I'm writing very quickly since I have to go...
--
EDIT #2 : Back in front of my desk. Well; I've thought in the car
A "wx-config --version" returns "2.8.12". So, it should mean it's the only one wx lib installed in the system. Right ? Now, I'll check-out a fresh C::B copy and will try to compile again...
--
EDIT #3b : oops, did a long add (EDIT #3), posted and don't see-it... Lost ! Well, in short : I don't remember the exact error, but after a long process (compiling) it stops on error talking about something wrong around DirectoryMonitor. So, compiling failed a new time
--
EDIT #4 : OK, i've ran 'make' again and object files being here it has been quick to reach the error I talk above (#3b). Here it is :
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../../../src/include -I/usr/local/lib/wx/include/mac-unicode-release-2.8 -I/usr/local/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXMAC__ -I../../../../src/include -I../../../../src/sdk/wxscintilla/include -I../../../../src/include/mozilla_chardet -Ulinux -Uunix -O2 -ffast-math -DCB_AUTOCONF -DCB_PRECOMP -Winvalid-pch -fPIC -DPIC -fexceptions -D__FAM__ -MT directorymonitor.lo -MD -MP -MF .deps/directorymonitor.Tpo -c directorymonitor.cpp -fno-common -DPIC -o .libs/directorymonitor.o
directorymonitor.cpp: In member function 'bool wxDirectoryMonitor::Start()':
directorymonitor.cpp:620: error: invalid use of incomplete type 'struct DirMonitorThread'
directorymonitor.h:21: error: forward declaration of 'struct DirMonitorThread'
directorymonitor.cpp:621: error: invalid use of incomplete type 'struct DirMonitorThread'
directorymonitor.h:21: error: forward declaration of 'struct DirMonitorThread'
directorymonitor.cpp:622: error: invalid use of incomplete type 'struct DirMonitorThread'
directorymonitor.h:21: error: forward declaration of 'struct DirMonitorThread'
directorymonitor.cpp: In member function 'void wxDirectoryMonitor::ChangePaths(const wxArrayString&)':
directorymonitor.cpp:629: error: invalid use of incomplete type 'struct DirMonitorThread'
directorymonitor.h:21: error: forward declaration of 'struct DirMonitorThread'
directorymonitor.cpp: In destructor 'virtual wxDirectoryMonitor::~wxDirectoryMonitor()':
directorymonitor.cpp:634: warning: possible problem detected in invocation of delete operator:
directorymonitor.cpp:634: warning: invalid use of incomplete type 'struct DirMonitorThread'
directorymonitor.h:21: warning: forward declaration of 'struct DirMonitorThread'
directorymonitor.cpp:634: note: neither the destructor nor the class-specific operator delete will be called, even if they are declared when the class is defined.
make[4]: *** [directorymonitor.lo] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
ELNDESK-OSX:Source eln$
--
EDIT #5 : Using "make -k", compiling is continuing in spite of the error above (EDIT #4)... Will I have a working up-to-date C::B or not ? That is the question
--
EDIT #6 : at the end of the process, of course it doesn't compile all... What's the next direction ? If a Mac person involved in Code::Blocks could drive me ? Or, if an OSX binary could be released, say, monthly...
--
EDIT #7 : Some news about the adventure
Seeing all compiling errors come from contrib plugins, I'm trying to disable the concerned ones, one by one, using configure options like "--with-contrib-plugins=all,-FileManager,-NassiShneiderman,-SpellChecker".
--
EDIT #8 : succeeded to compile ! Now, I'm going to make install, then, maybe, figure-out how to bundle (if necessary)...