Linking error on build 6206

[gygabyte017]

Hi, I've updated svn version to 6206 from 6201, but now I'm unable to compile (on windows).
I get a linker error:

Code Select Expand

.objs\plugins\codecompletion\ccoptionsdlg.o:ccoptionsdlg.cpp:(.text$_ZN20cbConfigurationPanelC2Ev[cbConfigurationPanel::cbConfigurationPanel()]+0x12)||undefined reference to `_imp___ZTV20cbConfigurationPanel'|
.objs\plugins\codecompletion\ccoptionsdlg.o:ccoptionsdlg.cpp:(.text$_ZN20cbConfigurationPanelD2Ev[cbConfigurationPanel::~cbConfigurationPanel()]+0x7)||undefined reference to `_imp___ZTV20cbConfigurationPanel'|
.objs\plugins\codecompletion\ccoptionsdlg.o:ccoptionsdlg.cpp:(.text$_ZN20cbConfigurationPanelD1Ev[cbConfigurationPanel::~cbConfigurationPanel()]+0x7)||undefined reference to `_imp___ZTV20cbConfigurationPanel'|
.objs\plugins\codecompletion\ccoptionsdlg.o:ccoptionsdlg.cpp:(.text$_ZN20cbConfigurationPanelD0Ev[cbConfigurationPanel::~cbConfigurationPanel()]+0x7)||undefined reference to `_imp___ZTV20cbConfigurationPanel'|
.objs\plugins\codecompletion\codecompletion.o:codecompletion.cpp:(.text$_ZN11EditorHooks15HookFunctorBaseD2Ev[EditorHooks::HookFunctorBase::~HookFunctorBase()]+0x7)||undefined reference to `_imp___ZTVN11EditorHooks15HookFunctorBaseE'|
.objs\plugins\codecompletion\codecompletion.o:codecompletion.cpp:(.text$_ZN11EditorHooks15HookFunctorBaseD1Ev[EditorHooks::HookFunctorBase::~HookFunctorBase()]+0x7)||undefined reference to `_imp___ZTVN11EditorHooks15HookFunctorBaseE'|
.objs\plugins\codecompletion\codecompletion.o:codecompletion.cpp:(.text$_ZN11EditorHooks15HookFunctorBaseD0Ev[EditorHooks::HookFunctorBase::~HookFunctorBase()]+0x7)||undefined reference to `_imp___ZTVN11EditorHooks15HookFunctorBaseE'|
.objs\plugins\codecompletion\codecompletion.o:codecompletion.cpp:(.text$_ZN11EditorHooks15HookFunctorBaseC2Ev[EditorHooks::HookFunctorBase::HookFunctorBase()]+0x4)||undefined reference to `_imp___ZTVN11EditorHooks15HookFunctorBaseE'|
.objs\plugins\codecompletion\nativeparser.o:nativeparser.cpp:(.text$_ZN18ProjectLoaderHooks15HookFunctorBaseD2Ev[ProjectLoaderHooks::HookFunctorBase::~HookFunctorBase()]+0x7)||undefined reference to `_imp___ZTVN18ProjectLoaderHooks15HookFunctorBaseE'|
.objs\plugins\codecompletion\nativeparser.o:nativeparser.cpp:(.text$_ZN18ProjectLoaderHooks15HookFunctorBaseD1Ev[ProjectLoaderHooks::HookFunctorBase::~HookFunctorBase()]+0x7)||undefined reference to `_imp___ZTVN18ProjectLoaderHooks15HookFunctorBaseE'|
.objs\plugins\codecompletion\nativeparser.o:nativeparser.cpp:(.text$_ZN18ProjectLoaderHooks15HookFunctorBaseD0Ev[ProjectLoaderHooks::HookFunctorBase::~HookFunctorBase()]+0x7)||undefined reference to `_imp___ZTVN18ProjectLoaderHooks15HookFunctorBaseE'|
.objs\plugins\codecompletion\nativeparser.o:nativeparser.cpp:(.text$_ZN18ProjectLoaderHooks15HookFunctorBaseC2Ev[ProjectLoaderHooks::HookFunctorBase::HookFunctorBase()]+0x4)||undefined reference to `_imp___ZTVN18ProjectLoaderHooks15HookFunctorBaseE'|
||=== Build finished: 12 errors, 0 warnings ===|


What is wrong?
Thank you

[Jenna]

There might be a problem with precompiled headers (just a wild guess).
You can try to remove the devel and output subfolders (below src) and the *.gch-files in the include subfolder.

[gygabyte017]

It works I've removed those files and rebuild the whole target, now it compiles successfully.

Thank you!

[Folco]

I use this thread because I also get a linking error when compiling the build 6206 (Fedora 13 beta 64bits) :

Code Select Expand

/usr/bin/ld: codesnippetstreectrl.o: undefined reference to symbol 'XWarpPointer'
/usr/bin/ld: note: 'XWarpPointer' is defined in DSO /usr/lib64/libX11.so.6 so try adding it to the linker command line
/usr/lib64/libX11.so.6: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
I am not strong enough to know what I could try to compile successfully, could you help me please ?

BTW, I don't use this plugin, so I could compile without it. But I didn't find the list of plugins that, in this case, I should put in the parameters list of './configure'.

Thanks in advance.

[SharkCZ]

The reason of the linking failure is http://fedoraproject.org/wiki/UnderstandingDSOLinkChange and a patch is attached here and also present in my package of C::B nightly build http://fedora.danny.cz/danny/development/SRPMS/codeblocks-10.00-4.20100227svn6181.fc13.src.rpm

[attachment deleted by admin]

[Folco]

Thank you. =)

And finally, I found the switches list in the 'configure' file. Sorry, I'm not used to do that.

[Folco]

Thank you again for your patch, now it works fine with all contrib plugins.

But I still have a problem : no plugin seems to be loaded...

I build like this :
./configure --with-contrib-plugins=all
make
make install (as root)

But when launching C::B and opening an existing project, I get this message :

Deactivating the compiler plugin is most unwise.

If you intend to open a project, you have to re-activate the compiler plugin first.

And I haven't any toolbar for the compilers, the debugger. Apparently, no plugin is loaded. Where am I wrong ?

edit -> I have used this page to perform the installation : http://wiki.codeblocks.org/index.php?title=Installing_Code::Blocks_from_source_on_Linux

[Jenna]

If you have opened C::B, please have a look into the "Code::Blocks" tab in "Logs & others", to see where C::B searches for plugins.
There should be at least two lines starting with: "Scanning for plugins in".

[Folco]

Ah, indeed, I get that :

Scanning for plugins in /home/folco/.codeblocks/share/codeblocks/plugins
Loaded 0 plugins
Scanning for plugins in /usr/local/lib64/codeblocks/plugins

But both folders are empty.

But I have that in /usr/local/share/codeblocks :

astyle.zip          classwizard.zip     debugger.zip            HexEditor.zip          lib_finder.zip         resources.zip       tips.txt
autosave.zip        codecompletion.zip  defaultmimehandler.zip  icons                  manager_resources.zip  scriptedwizard.zip  todo.zip
AutoVersioning.zip  codesnippets.zip    dragscroll.zip          images                 MouseSap.zip           scripts             Valgrind.zip
BrowseTracker.zip   codestat.zip        envvars.zip             IncrementalSearch.zip  openfileslist.zip      start_here.zip      wxSmithAui.zip
byogames.zip        compiler.zip        exporter.zip            keybinder.zip          Profiler.zip           SymTab.zip          wxsmithcontribitems.zip
cb_koders.zip       copystrings.zip     headerfixup.zip         lexers                 projectsimporter.zip   templates           wxsmith.zip
Cccc.zip            CppCheck.zip        help_plugin.zip         lib_finder             RegExTestbed.zip       ThreadSearch.zip

I have put these files in ~/.codeblocks/[...], but it doesn't seems to be what I have to do ^^

[Jenna]

You sould have a bunch of libs in /usr/local/lib64/codeblocks/plugins.

The zip-files contain some resources like manifest.xml and sometimes images ... and they all should have a corresponding library (or better two a .so and a .la ).

[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().

    // 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;

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.