CodeBlocks and contrib projects for MacOSX 10.4

[afb]

takeshi,

Sorry, I had to reverse your patch for pluginmanager, since no plugins loaded when applied.

Right, it shouldn't use "dylib" for the plugins - those are "bundle" or "so" ( as used now)

Missed that on the cursory glance

[takeshimiya]

Hi,

can you enlighten me?
on mac the shared libraries doesn't have a .dylib or .bundle extension?
plugins are share libraries right? what about wxscintilla, isn't a shared library too? why it needs the .dylib extension where the plugins not?

I'll update the patch accordingly

[afb]

can you enlighten me?
on mac the shared libraries doesn't have a .dylib or .bundle extension?

"Yes". As in: the shared libraries come in two different variants on Mac OS X.

See http://developer.apple.com/documentation/DeveloperTools/Conceptual/MachOTopics/Articles/loading_code.html

plugins are share libraries right?

"loadable bundle" (.so or .bundle)

/usr/bin/file command says: Mach-O bundle

what about wxscintilla, isn't a shared library too?

"dynamic library" (.dylib or .framework)

/usr/bin/file command says: Mach-O dynamically linked shared library

why it needs the .dylib extension where the plugins not?

I'll update the patch accordingly

libwxscintilla, libcodeblocks, libwx_mac-2.6 etc. => dylibs
C::B plugins, perl modules, python modules, etc. => bundles

Hope that helps.

[Pecan]

Hi,

can you enlighten me?
on mac the shared libraries doesn't have a .dylib or .bundle extension?
plugins are share libraries right? what about wxscintilla, isn't a shared library too? why it needs the .dylib extension where the plugins not?

I'll update the patch accordingly

I try to remember it this way:

A program links against (uses) a dll: dll = dylib
A dll links against (uses) a program: dll = bundle