Nemiver fails to start up with an error about undefined symbols. The exact error message is: |X|virtual GModule* nemiver::common::DynamicModule::Loader::load_library_from_path(const nemiver::common::UString&):nmv-dynamic-module.cc:286:raised exception: failed to load shared library /usr/lib64/nemiver/modules/libworkbenchmod.so: /usr/lib64/nemiver/modules/libworkbenchmod.so: undefined symbol: _ZThn16_N13gtksourceview10SourceViewD1Ev |E|int main(int, char**):main.cc:489:failed to load shared library /usr/lib64/nemiver/modules/libworkbenchmod.so: /usr/lib64/nemiver/modules/libworkbenchmod.so: undefined symbol: _ZThn16_N13gtksourceview10SourceViewD1Ev I tried rebuilding nemiver, which didn'T help. Now the interesting part is: the named symbol is in libworkbenchmod.so, but marked undef. Since we are taling about a DSO, the symbol needs to be either some other place, or for obvious reason resolving the symbol fails. The question now is, in what DSO/lib the named symbol should actually be defined. Even more interesting: If we assume nemiver generates the name mangling information during compile time, then something with the build is wrong, if it is fixed, then the question is, which dependency is not met, or not met with the proper version of the corresponding DSO/lib. Can you advise steps for further analysis of the bug? OR even a fix? Reproducible: Always Steps to Reproduce: 1. emerge nemiver 2. try to run it 3. Actual Results: nemiver fails to start due to problems with symbol resolving. Expected Results: nemiver should at least start up.
Please run revdep-rebuild from the app-portage/gentoolkit package and reopen this bug if that doesn't fix the issue. If you reopen this bug, then please post your `emerge --info' too.
I forgot to mention that my system got revdep-rebuilt of course, redid a revdep: Nothing to rebuild, reemerged nemiver again - Still same results. Emerge info will follow as attachment
Created attachment 170250 [details] emerge --info
you probably need to rebuild gtksourceviewmm and/or gtksourceview. This kind of problem is recurring but I can't point to where I learned that unfortunately and I don't know how it would be possible to make revdep-rebuild or portage fix that.
Thnaks, it worked. Since gtksourceview got updated recently I first tried rebuilding gtksourceviewmm, which did the trick. The question is now really, how to handle this properly.
I'm betting on an API/ABI break in gtksourceviewmm... and given it's sooo much easier to break ABI with C++ :) I doubt there's much we can do about it. Thanks
sigh, I need to learn how to click... sorry for the noise
Okay, I just checked the following: echo "_ZThn16_N13gtksourceview10SourceViewD1Ev"|c++filt which yields: non-virtual thunk to gtksourceview::SourceView::~SourceView() Now, what puzzles me is: Why does nemiver ld a DSO, which references one of gtksourceviewmm's thunks and why was the symbol not there before recompiling gtksourceviewmm, when it did not get upgraded? In other words: How can a upgrade to gtksourceview break gtksourceviewmm in such a way, that the exported symbols are different or disappear? gtksourceviewmm's interface should not have changed, imho.
Did you change c++ compilers recently? (a gcc upgrade maybe?) Thanks
Yes, a gcc upgrade might be the best explanation. If gtksourceviewmm was compiled with a different mangling, then obviously the symbols generated in gtksourceviewmm did differ from the ones generated during linking of nemiver (Though in this case I'd assume the linking fails, but if g++ just created different names from the .h for libworkbench.so than the earlier version did for gtksourceviewmm.so this could explain this behavior). And yes, I upgraded from gcc 4.3.1 to 4.3.2 inbetween I think (not sure though). I checked the gcc changelog but they did not mention anything about changing the name mangling scheme. This seems really arkward, if things like that just change without notice and gcc/ld not checking something like that. During major upgrades 3->4 or something with announced abi changes one would expect problems though. If I got some spare time later on, I will try to verify this (compile gtksourceviemm again with different gcc versions at hand and check on the Symbol names).
improper libtool versioning of almost all gnome-mm bindings is although most likely to be part of the problem. Some day (dream), I'll have enough time to look at this myself and see if we can do something about it. Feel free to report your findings on the matter as well.
I am not sure if this is still valid today :-/
(In reply to comment #12) > I am not sure if this is still valid today :-/ I would vote for closing this as looks to be no longer valid with updated packages (or, at least, I haven't suffered this problem for a really long time)
Closing as I haven't seen this for a really long time on any of the machines I maintain
