User forums > Help

Linking error on build 6206

<< < (3/4) > >>

Folco:
Wow, great Jens, many thanks !!!

In fact, all these libs were in /usr/local/lib/codeblocks/plugins !
I just 'cp -R' all and now, it works fine.

Thanks again. =)

ps -> Does that mean that there is a problem in the build process of C::B ? Or perhaps in my configuration ?

Jenna:
If the plugin-libs are in /usr/local/lib/codeblocks/plugins, C::B should find them in any case ... unless wxWidgets changed the return-value for wxStandardPathsBase::Get().GetPluginsDir().

--- Quote from:  stdpaths.h from wxwidgets 2.8.10 ---    // return the directory where the loadable modules (plugins) live
    //
    // prefix/lib/appname under Unix, program directory under Windows and
    // Contents/Plugins app bundle subdirectory under Mac
    virtual wxString GetPluginsDir() const = 0;

--- End quote ---

and it now returns lib64 instead of lib on 64-bit-systems.

No way to test it here (no Fedora installation available atm).

Folco:
If GetPluginDir() returns lib64, it works fine. So it should be make install which has put the libs at the wrong place ?

(perhaps I understood wrongly what you said...)


If you want, I can test that if you give me a process to do that. :)

Folco:
Two more question please, the patch made by SharkCZ will be integrated to C::B or no ? Perhaps no because only very recent systems should be affected ?

Must I fill a bug report about GetPluginsDir() ?

SharkCZ:
The linking patch isnow submitted at Berlios (http://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=2990&group_id=5358).

The wxGTK library in Fedora is patched to use "lib64" as the plugin dir on 64-bit platforms. There was also a discussion with wxWidgets developers how to solve it, but it will remain patched until a definitive solution is found.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version