Author Topic: Problems making CB for OSX from wiki instructions  (Read 19236 times)

Offline bnilsson

  • Almost regular
  • **
  • Posts: 184
Problems making CB for OSX from wiki instructions
« on: September 24, 2006, 10:45:31 am »
I have problems following the wiki instructions on building CB for OSX.

I do
./configure --enable-contrib

and get (in make src/plugins/contrib)

ar cru .libs/libwxPdfDocument.a .libs/pdfannotation.o .libs/pdfbarcode.o .libs/pdfcolor.o .libs/pdfdoc.o .libs/pdfencrypt.o .libs/pdffont.o .libs/pdfform.o .libs/pdfgraphics.o .libs/pdfimage.o .libs/pdfkernel.o .libs/pdfxml.o~ranlib .libs/libwxPdfDocument.a
ar: .libs/pdfxml.o~ranlib: No such file or directory

What is ".libs/pdfxml.o~ranlib"?

-- Ingnorance should not be taken for stupidity --

HW: PowerMac Dual PowerPC G5 2.3Ghz, 1GB RAM OS: MacOSX 10.4.10 Compiler: powerpc-apple-darwin8-gcc-4.0.1

Offline bnilsson

  • Almost regular
  • **
  • Posts: 184
Re: Problems making CB for OSX from wiki instructions
« Reply #1 on: September 24, 2006, 12:52:59 pm »
Platform:
PowerMac dual G5 2.3GHz
OSX 10.4.7
wxwidgets 2.6.3
codeblocks from http://www.codeblocks.org/source_code.shtml

I applied the patches as indicated by the wiki page, there were many FAILED chunks but anyway, now it built after editing menuutils.cpp and dragscroll.cpp. Some functions TODO had been implemented (by the patches?) without removing the empty TODO declarations.

(I had the naive assumption that patches of some age would go into the fresh distribution, but this was obviously wrong.)

This version of CB does not load the plugins. It is looking for the wrong plugins, or the wrong plugins (names?) are installed.
CB says it wants .zip plugins, but there are only .la and .so files in the plugins folder.
But this would go into another thread.

-- Ingnorance should not be taken for stupidity --

HW: PowerMac Dual PowerPC G5 2.3Ghz, 1GB RAM OS: MacOSX 10.4.10 Compiler: powerpc-apple-darwin8-gcc-4.0.1

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2178
Re: Problems making CB for OSX from wiki instructions
« Reply #2 on: September 24, 2006, 01:57:31 pm »
Platform:
PowerMac dual G5 2.3GHz
OSX 10.4.7
wxwidgets 2.6.3
codeblocks from http://www.codeblocks.org/source_code.shtml

I applied the patches as indicated by the wiki page, there were many FAILED chunks but anyway, now it built after editing menuutils.cpp and dragscroll.cpp. Some functions TODO had been implemented (by the patches?) without removing the empty TODO declarations.

(I had the naive assumption that patches of some age would go into the fresh distribution, but this was obviously wrong.)

This version of CB does not load the plugins. It is looking for the wrong plugins, or the wrong plugins (names?) are installed.
CB says it wants .zip plugins, but there are only .la and .so files in the plugins folder.
But this would go into another thread.



PluginManager.cpp is looking for name.zip for it manifest.xml file, while MAC plugin names are libname.so etc. So the ziped manifest file name should be libname.zip, not name.zip in .../share/codeblocks.

So if the plugin is named DragScroll.so, the manifest.xml should be ziped into .../share/codeblocks/libDragScroll.zip

Also,
DragScroll and Keybinder have been fixed in SVN and tested on the MAC as of 2006/09/23 SVN 2993
« Last Edit: September 24, 2006, 02:02:31 pm by Pecan »

Offline afb

  • Developer
  • Lives here!
  • *****
  • Posts: 884
Re: Problems making CB for OSX from wiki instructions
« Reply #3 on: September 24, 2006, 08:20:03 pm »
Also,
DragScroll and Keybinder have been fixed in SVN and tested on the MAC as of 2006/09/23 SVN 2993

I've updated the Wiki and removed the workaround patch.
Will update the Portfile when I have built rev 2994 locally.

Offline bnilsson

  • Almost regular
  • **
  • Posts: 184
Re: Problems making CB for OSX from wiki instructions
« Reply #4 on: September 24, 2006, 08:41:56 pm »
Two things:

1) There is no libdebuggergdb plugin, and CB complains that it cannot load it.
2) There are some failures when applying the plugin patch:

patch -p0 -i codeblocks-rev2890_pluginslib.patch
patching file src/plugins/contrib/codesnippets/Makefile.am
Hunk #1 FAILED at 10.
1 out of 1 hunk FAILED -- saving rejects to file src/plugins/contrib/codesnippets/Makefile.am.rej
patching file src/plugins/contrib/profiler/Makefile.am
patching file src/plugins/contrib/wxSmith/defwidgets/Makefile.am
patching file src/plugins/contrib/wxSmith/properties/Makefile.am
patching file src/plugins/contrib/wxSmith/Makefile.am
patching file src/plugins/contrib/wxSmith/resources/Makefile.am
patching file src/plugins/contrib/envvars/Makefile.am
Hunk #1 FAILED at 9.
1 out of 1 hunk FAILED -- saving rejects to file src/plugins/contrib/envvars/Makefile.am.rej
patching file src/plugins/contrib/codestat/Makefile.am
patching file src/plugins/contrib/help_plugin/Makefile.am
patching file src/plugins/contrib/byogames/Makefile.am
Hunk #1 FAILED at 8.
1 out of 1 hunk FAILED -- saving rejects to file src/plugins/contrib/byogames/Makefile.am.rej
patching file src/plugins/contrib/source_exporter/Makefile.am
patching file src/plugins/contrib/cb_koders/Makefile.am
patching file src/plugins/contrib/keybinder/Makefile.am
patching file src/plugins/contrib/dragscroll/Makefile.am
Hunk #1 FAILED at 8.
1 out of 1 hunk FAILED -- saving rejects to file src/plugins/contrib/dragscroll/Makefile.am.rej
patching file src/plugins/astyle/Makefile.am
patching file src/plugins/debuggergdb/Makefile.am
Hunk #1 FAILED at 13.
1 out of 1 hunk FAILED -- saving rejects to file src/plugins/debuggergdb/Makefile.am.rej
patching file src/plugins/codecompletion/Makefile.am
patching file src/plugins/todo/Makefile.am
patching file src/plugins/classwizard/Makefile.am
patching file src/plugins/compilergcc/Makefile.am
patching file src/plugins/autosave/Makefile.am
Hunk #1 FAILED at 8.
1 out of 1 hunk FAILED -- saving rejects to file src/plugins/autosave/Makefile.am.rej
patching file src/plugins/defaultmimehandler/Makefile.am
patching file src/plugins/xpmanifest/Makefile.am
patching file src/plugins/scriptedwizard/Makefile.am
Hunk #1 FAILED at 12.
1 out of 1 hunk FAILED -- saving rejects to file src/plugins/scriptedwizard/Makefile.am.rej


Is this something to worry about?


-- Ingnorance should not be taken for stupidity --

HW: PowerMac Dual PowerPC G5 2.3Ghz, 1GB RAM OS: MacOSX 10.4.10 Compiler: powerpc-apple-darwin8-gcc-4.0.1

Offline bnilsson

  • Almost regular
  • **
  • Posts: 184
Re: Problems making CB for OSX from wiki instructions
« Reply #5 on: September 24, 2006, 09:12:58 pm »
And a third:

contrib does not build byogames:

/usr/bin/ld: Undefined symbols:
byoGameBase::BackToWorkTimer()
byoGameBase::ReloadFromConfig()
byoGameSelect::byoGameSelect(wxWindow*, int)
byoGameSelect::~byoGameSelect()
byoGameLauncher::GetGames()
byoConf::byoConf(wxWindow*, int)
collect2: ld returned 1 exit status
make[4]: *** [libbyogames.la] 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


If I temporarly disable it by editing the contrib/Makefile and revmove it from SUBDIRS, I can build ok.
make and make install are ok.
After bundling CodeBlocks.app and starting it I notice that there is no complaints about libdebuggergdb.zip anymore.
I have not yet created the contrib .zip files from the manifest.xml files, I hope it will complete the installation.

Is there any chance that all this will be automated in a future ./configure and make process?


-- Ingnorance should not be taken for stupidity --

HW: PowerMac Dual PowerPC G5 2.3Ghz, 1GB RAM OS: MacOSX 10.4.10 Compiler: powerpc-apple-darwin8-gcc-4.0.1

Offline bnilsson

  • Almost regular
  • **
  • Posts: 184
Re: Problems making CB for OSX from wiki instructions
« Reply #6 on: September 24, 2006, 10:12:47 pm »
Platform:
PowerMac dual G5 2.3GHz
OSX 10.4.7
wxwidgets 2.6.3
CodeBlocks from svn checkout svn://svn.berlios.de/codeblocks/trunk

All manually created plugins.zip now loads except libwxsmith.zip, which crasches CB at startup.
Is this known?
-- Ingnorance should not be taken for stupidity --

HW: PowerMac Dual PowerPC G5 2.3Ghz, 1GB RAM OS: MacOSX 10.4.10 Compiler: powerpc-apple-darwin8-gcc-4.0.1

Offline afb

  • Developer
  • Lives here!
  • *****
  • Posts: 884
Re: Problems making CB for OSX from wiki instructions
« Reply #7 on: September 24, 2006, 10:45:16 pm »
2) There are some failures when applying the plugin patch:

patch -p0 -i codeblocks-rev2890_pluginslib.patch

Is this something to worry about?

I made an updated patch, codeblocks-rev2994_pluginslib.patch

Some plugins had moved/arrived, since the previous patch was made...
Basically all it is supposed to do is to add $(WX_LIBS) before libcodeblocks

Offline afb

  • Developer
  • Lives here!
  • *****
  • Posts: 884
Re: Problems making CB for OSX from wiki instructions
« Reply #8 on: September 24, 2006, 10:50:10 pm »
Is there any chance that all this will be automated in a future ./configure and make process?

That is definitely the goal, yes...

The GNU libtool bugs on Mac OS X 10.4 might be hard to "fix" in the autoconf files,
but everything else should be doable like making it compile and link out of the box ?

You will find that the "steps" needed to process are in the DarwinPorts "Portfile", even
though it is a machine-readable format it should describe the various commands it does.

Offline afb

  • Developer
  • Lives here!
  • *****
  • Posts: 884
Re: Problems making CB for OSX from wiki instructions
« Reply #9 on: September 24, 2006, 11:08:26 pm »
This version of CB does not load the plugins. It is looking for the wrong plugins, or the wrong plugins (names?) are installed.
CB says it wants .zip plugins, but there are only .la and .so files in the plugins folder.
But this would go into another thread.

PluginManager.cpp is looking for name.zip for it manifest.xml file, while MAC plugin names are libname.so etc. So the ziped manifest file name should be libname.zip, not name.zip in .../share/codeblocks.

So if the plugin is named DragScroll.so, the manifest.xml should be ziped into .../share/codeblocks/libDragScroll.zip

Hmm, wonder when this change happened ?

It used to load happily from the share/codeblocks/dragscroll.zip file just like it does on Linux...
Now it creates the files as "dragscroll.zip", but then tries to load them as "libdragscroll.zip". :-(

Code: [Select]
Plugin resource not found: libdragscroll.zip
Suggested change:
Code: [Select]
--- src/sdk/pluginmanager.cpp (revision 2994)
+++ src/sdk/pluginmanager.cpp (arbetskopia)
@@ -144,7 +144,7 @@
         wxFileName fname(pluginFilename);
         fname.SetExt(_T("zip"));
         wxString actual = fname.GetFullName();
-        #ifdef __WXGTK__
+        #if defined(__WXGTK__) || defined(__WXMAC__)
         // remove 'lib' prefix from plugin name (if any)
         if (actual.StartsWith(_T("lib")))
             actual.Remove(0, 3);
« Last Edit: September 24, 2006, 11:18:21 pm by afb »

Offline bnilsson

  • Almost regular
  • **
  • Posts: 184
Re: Problems making CB for OSX from wiki instructions
« Reply #10 on: September 25, 2006, 07:50:53 am »

Just curious: If CB usually loads the plugins from share/codeblocks, what then is the purpouse of share/codeblocs/plugins?
-- Ingnorance should not be taken for stupidity --

HW: PowerMac Dual PowerPC G5 2.3Ghz, 1GB RAM OS: MacOSX 10.4.10 Compiler: powerpc-apple-darwin8-gcc-4.0.1

Offline afb

  • Developer
  • Lives here!
  • *****
  • Posts: 884
Re: Problems making CB for OSX from wiki instructions
« Reply #11 on: September 25, 2006, 08:24:43 am »
Just curious: If CB usually loads the plugins from share/codeblocks, what then is the purpouse of share/codeblocs/plugins?

It loads the code from codeblocks/plugins/libplugin.so, but
loads the resources from codeblocks/plugin.zip (no idea why)

Offline bnilsson

  • Almost regular
  • **
  • Posts: 184
Re: Problems making CB for OSX from wiki instructions
« Reply #12 on: September 25, 2006, 10:23:00 am »
Just to clarify:
For me, plugins only loads if I manually create the libpluginname.zip resources from the manifest.xml in the src/plugins/... and put them in share/codeblocks/plugins together with the lib*.so and lib*.la.
Pluginnames.zip plus some other .zip files already exists in share/codeblocks. If I remove or move pluginnames.zip I get error messages "resource not found", and if I remove the other .zip files I get a crasch.
I tested this because I wanted to see if the .zip files were just in the wrong place. This of course was not the case.


-- Ingnorance should not be taken for stupidity --

HW: PowerMac Dual PowerPC G5 2.3Ghz, 1GB RAM OS: MacOSX 10.4.10 Compiler: powerpc-apple-darwin8-gcc-4.0.1

Offline afb

  • Developer
  • Lives here!
  • *****
  • Posts: 884
Re: Problems making CB for OSX from wiki instructions
« Reply #13 on: September 25, 2006, 11:08:53 am »
To clarify, I patched my Code::Blocks to look in "pluginname.zip" instead of in "libpluginname.zip". Just like it used to do on Mac, and like it does on Linux...

http://developer.berlios.de/patch/?func=detailpatch&patch_id=1524&group_id=5358

With "no idea why" I meant why the library is in "plugins" and not the resources.
(i.e. not why they are named like they are, but why they are in separate dirs...)
« Last Edit: September 25, 2006, 11:10:45 am by afb »

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2178
Re: Problems making CB for OSX from wiki instructions
« Reply #14 on: September 25, 2006, 02:44:25 pm »
To clarify, I patched my Code::Blocks to look in "pluginname.zip" instead of in "libpluginname.zip". Just like it used to do on Mac, and like it does on Linux...

http://developer.berlios.de/patch/?func=detailpatch&patch_id=1524&group_id=5358

With "no idea why" I meant why the library is in "plugins" and not the resources.
(i.e. not why they are named like they are, but why they are in separate dirs...)

A change was made to the way plugins are loaded.
PluginManager.cpp finds the pluginname.so file in .../share/codeblocks/plugin, but does not load it yet.

It then looks in .../share/codeblocks for a file named pluginname.zip which is supposed to contain a manifest file named manifest.xml . The manifest contains the plugin name, version, UI interface version, author, etc. If all this matches the pluginname.so that was found, the pluginname.so is then loaded.

The devs thought it to be much faster to open a manifest file and validate the plugin, then to load all the pluginname.so files to validate them.