C::B SVN built and bundled under OSX : no dylibs, no plugins loaded

[eranon]

Hello,

Installing a new OSX environment, I built wxWidgets 2.8 (dylib), then SVN HEAD of CodeBlocks with :

Code

ACLOCAL_FLAGS="-I /usr/local/share/aclocal" ./bootstrap
./configure --with-contrib-plugins=all,-FileManager,-NassiShneiderman,-spellchecker --enable-unicode CFLAGS="-arch i386" CXXFLAGS="-arch i386" CPPFLAGS="-arch i386" LDFLAGS="-arch i386" OBJCFLAGS="-arch i386" OBJCXXFLAGS="-arch i386"
make
sudo make install

Notice I had to remove all the "-Wl,--no-undefined" in "acinclude.m4" to pass a "C++ compiler cannot create executables" error.

Then, I made an app bundle, but launching it not any plugin is loaded. So, the fact is that I don't find the plugins's dylib. I have an old bundle in which I succeeded (in 2012), but I don't see any obvious difference about the script building it (have to study the stuff again).

Well, where are the dylibs ? That is the question

--
EDIT : I finally tried to go with the .so about plugins (even if in the C::B 13.12's bundle I well see a .dylib files) and I placed them in the path CodeBlocks is waiting for them as per the CodeBlocks log... But it remains the same : "0 loaded plugins". Does someone could explain me the good bundle tree to succeed ?

[eranon]

I see I opened a related thread in 2013 http://forums.codeblocks.org/index.php/topic,18490.0.html and that it was w/o reply too.

Does a Mac man could do the point about bundle from SVN ? I also tried the script coming from the wiki and same result : no plugin loaded.

--
EDIT : Does the update script supposed to be ran at some point during the build process (I meaning talink about building from SVN under OS X) ?

[MortenMacFly]

Does a Mac man could do the point about bundle from SVN ?

The only working way I (and only I) know is compiling C::B under Mac using C::B. This will create dynlibs accordingly. I don't know about other ways.

EDIT : Does the update script supposed to be ran at some point during the build process

Taking the above into account: No. In that case you'll need to adjust (one time) and then run the mac_pack script.

[eranon]

Thanks for you reply Morten.

So, does the process changed in 2013 ? I made a working bundle in 2012 (opening it I see it contains a .so files too) and it was after a building from command line as explained in the wiki.

Should I use "CodeBlocks-unix.workspace" ?

[MortenMacFly]

So, does the process changed

Yes,I think so. It wipes nicely on Linux. But I never use autotools so I don't know about any side effects on the Mac.

Should I use "CodeBlocks-unix.workspace" ?

Yes, that's the one I used on the Mac, too.

[eranon]

Well, I taken a quick try (time is too short, we should redefine it a day) and it doesn't compile out of the box for me. I had to add some path for include in the build options and I passed some errors, but it still doesn't go to compile in full. At step I am it tell me I have to use wx-config to figure-out the build flags... Hummm, no time to go deeper just now, but I wonder if I don't forget something obvious. Just two quick questions as it comes :

Do I have to define an environment variable (don't even know if it's the good OS X term) like WXWIN ?
Does someone reported any issue with wx-config call using backtick (it would be a good reason of absence of build flags) ?

So, I have two ways : try to succeed with the cb-workspace or try to succeed with the command line.

Awaiting to solve this, I'll use the official binaries. In fact, mainly, I just need to compile because of a tiny trick I applied in code to allow several toolbars with a frame ; and this wxsmith change couldn't be a submitted patch because afterward the dev would have to adjust his code by hand, to do it works. So, maybe a thrid way would be to just rebuild the wxSmith dylib, then replace it in the official bundle (but, of course, it would be just a tmp fix).

[eranon]

Solved the command line way. I simply renamed the .so files as .dylib in the bundle and only one plugin I needed crashes when C::B is launched. It's ThreadSearch. So, I removed it and C::B runs ; wxSmith too. Not tried in depth, but basic operations seems to be OK.