[opensuse] quasselcore doesn't run
Hello Mates, i'm using quassel from KDE:Extra Repository. And now i have a little Problem. If i start rcquasselcore start he just say: linux-f34p:/home/sascha # rcquasselcore start Starting quassel core failed Is it possible to debug this, to find out what happens? -- Sincerely yours Sascha Manns open-slx GmbH openSUSE Community & Support Agent openSUSE Marketing Team Blog: http://saigkill.wordpress.com Web: http://www.saschamanns.de Web: http://www.open-slx.de (openSUSE Box Support German) Web: http://www.open-slx.com (openSUSE Box Support English) Open-SLX : Linux convenient, simple, secure and complete
On Sunday 26 September 2010, Sascha 'saigkill' Manns wrote:
Hello Mates,
i'm using quassel from KDE:Extra Repository. And now i have a little Problem. If i start rcquasselcore start he just say: linux-f34p:/home/sascha # rcquasselcore start Starting quassel core failed
Is it possible to debug this, to find out what happens?
Yes, if you run quasselcore directly it will print out error messages which the init script throws away Most likely you are missing /etc/sysconfig/quasselcore. That was my problem. I got it from /var/adm/fillup-templates/sysconfig.quasselcore and copied it manually, set the variable in it to my IP address, and then it worked Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Is it possible to debug this, to find out what happens? Yes, if you run quasselcore directly it will print out error messages which the init script throws away The output is:
Hello Anders, Am Sonntag, 26. September 2010 14:09:48 wrote Anders Johansson: linux-f34p:/etc/sysconfig # quasselcore quasselcore: symbol lookup error: quasselcore: undefined symbol: _ZN9QMetaType15registerTypedefEPKci
Most likely you are missing /etc/sysconfig/quasselcore. That was my problem. I got it from /var/adm/fillup-templates/sysconfig.quasselcore and copied it manually, set the variable in it to my IP address, and then it worked The File under /etc/sysconfig/quasselcore is present and accessable. Maybe it is just the Issue with the undefined symbol...
-- Sincerely yours Sascha Manns open-slx GmbH openSUSE Community & Support Agent openSUSE Marketing Team Blog: http://saigkill.wordpress.com Web: http://www.saschamanns.de Web: http://www.open-slx.de (openSUSE Box Support German) Web: http://www.open-slx.com (openSUSE Box Support English) Open-SLX : Linux convenient, simple, secure and complete
On Sun, 2010-09-26 at 14:28 +0200, Sascha 'saigkill' Manns wrote:
Hello Anders,
Is it possible to debug this, to find out what happens? Yes, if you run quasselcore directly it will print out error messages which the init script throws away The output is:
Am Sonntag, 26. September 2010 14:09:48 wrote Anders Johansson: linux-f34p:/etc/sysconfig # quasselcore quasselcore: symbol lookup error: quasselcore: undefined symbol: _ZN9QMetaType15registerTypedefEPKci
Ah, that looks more like an installation problem with your QT libraries Which opensuse version are you installing on? Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sunday 26 September 2010, Sascha 'saigkill' Manns wrote:
The output is: linux-f34p:/etc/sysconfig # quasselcore quasselcore: symbol lookup error: quasselcore: undefined symbol: _ZN9QMetaType15registerTypedefEPKci
I found the symbol. It looks like you have a quassel package built against Qt 4.7. That symbol is in libQtDBus.so.4.7, not in older versions of that library Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sunday 26 September 2010, Sascha 'saigkill' Manns wrote:
The output is: linux-f34p:/etc/sysconfig # quasselcore quasselcore: symbol lookup error: quasselcore: undefined symbol: _ZN9QMetaType15registerTypedefEPKci
I found the symbol. It looks like you have a quassel package built against Qt 4.7. That symbol is in libQtDBus.so.4.7, not in older versions of that library Thanks for searching. So i think i must upgrade. BTW: How can i search thing like such symbols? Can you explain me that
Am Sonntag, 26. September 2010 18:05:39 wrote Anders Johansson: please? -- Sincerely yours Sascha Manns open-slx GmbH openSUSE Community & Support Agent openSUSE Marketing Team Blog: http://saigkill.wordpress.com Web: http://www.saschamanns.de Web: http://www.open-slx.de (openSUSE Box Support German) Web: http://www.open-slx.com (openSUSE Box Support English) Open-SLX : Linux convenient, simple, secure and complete
On Sunday 26 September 2010, Sascha 'saigkill' Manns wrote:
Am Sonntag, 26. September 2010 18:05:39 wrote Anders Johansson:
On Sunday 26 September 2010, Sascha 'saigkill' Manns wrote:
The output is: linux-f34p:/etc/sysconfig # quasselcore quasselcore: symbol lookup error: quasselcore: undefined symbol: _ZN9QMetaType15registerTypedefEPKci
I found the symbol. It looks like you have a quassel package built against Qt 4.7. That symbol is in libQtDBus.so.4.7, not in older versions of that library
Thanks for searching. So i think i must upgrade. BTW: How can i search thing like such symbols? Can you explain me that please?
Well, in this case I didn't have qt 4.7 installed, so I used google. The class name in the above is QMetaType, and the method name is registerTypedef. It didn't take much searching to find which library delivers it. google is usually enough for finding these things. Otherwise I normally do something like "find / -name \*.so.\* -exec nm -A -D {} \; | grep <symbol I am looking for>" The library that contains the function in question will have it tagged with a "T" and you'll see the address offset of the function within it. Libraries which merely call it have it marked "U" for Undefined Takes a while, but usually works Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Hello, On Sun, 26 Sep 2010, Anders Johansson wrote:
Am Sonntag, 26. September 2010 18:05:39 wrote Anders Johansson:
On Sunday 26 September 2010, Sascha 'saigkill' Manns wrote:
The output is: linux-f34p:/etc/sysconfig # quasselcore quasselcore: symbol lookup error: quasselcore: undefined symbol: _ZN9QMetaType15registerTypedefEPKci [..] google is usually enough for finding these things. Otherwise I normally do something like "find / -name \*.so.\* -exec nm -A -D {} \; | grep <symbol I am looking for>" The library that contains the function in question will have it tagged with a "T" and you'll see
On Sunday 26 September 2010, Sascha 'saigkill' Manns wrote: the address offset of the function within it. Libraries which merely call it have it marked "U" for Undefined
To make that task easier, there are c++filt and 'nm -C'. But yeah, most times just reading the stuff "right" suffices (how the QMetaType::registerTypedef is embedded in the above example is quite typical). And once you know that Q... is Qt stuff ... ;) I usually use something like: for lib in /lib/lib*.a; do nm [-C] "$lib" | grep '<SYMBOL>' && echo "$lib"; done or something like that (as most .so are stripped here, i.e. nm just has "no symbols" and I do have unstripped '.a' static libs for most libs). Else, you'd use '*.so' instead. Using 'strings "$lib"' usually still works on stripped libs BTW: $ nm libdhaller.so.0.0.0 | grep xreadline 000015c0 T xreadline $ strip libdhaller.so.0.0.0 $ nm libdhaller.so.0.0.0 | grep xreadline nm: libdhaller.so.0.0.0: no symbols $ strings libdhaller.so.0.0.0 | grep xreadline xreadline [libdhaller is just some private stuff, not fit for the public ;)] HTH, -dnh -- "And 1.1.81 is officially BugFree(tm), so if you receive any bug-reports on it, you know they are just evil lies." -- Linus Torvalds -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sunday 26 September 2010, David Haller wrote:
I usually use something like:
for lib in /lib/lib*.a; do nm [-C] "$lib" | grep '<SYMBOL>' && echo "$lib"; done
or something like that (as most .so are stripped here, i.e. nm just has "no symbols"
Well, it's hard to strip out the dynamic symbols (-D) from a lib and still be able to link with it :) The dynamic symbols must always be readable Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Hi David, Am Sonntag, 26. September 2010 19:59:39 wrote David Haller:
Hello,
On Sun, 26 Sep 2010, Anders Johansson wrote:
On Sunday 26 September 2010, Sascha 'saigkill' Manns wrote:
Am Sonntag, 26. September 2010 18:05:39 wrote Anders Johansson:
On Sunday 26 September 2010, Sascha 'saigkill' Manns wrote:
The output is: linux-f34p:/etc/sysconfig # quasselcore quasselcore: symbol lookup error: quasselcore: undefined symbol: _ZN9QMetaType15registerTypedefEPKci Do you know what a "Symbol" is? Anything like a pointer? Why they are so cryptic and not Symbol12345?
-- Sincerely yours Sascha Manns open-slx GmbH openSUSE Community & Support Agent openSUSE Marketing Team Blog: http://saigkill.wordpress.com Web: http://www.saschamanns.de Web: http://www.open-slx.de (openSUSE Box Support German) Web: http://www.open-slx.com (openSUSE Box Support English) Open-SLX : Linux convenient, simple, secure and complete -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sunday 26 September 2010, Sascha 'saigkill' Manns wrote:
Do you know what a "Symbol" is? Anything like a pointer?
A symbol is a name in a binary. Symbols in libraries are functions, classes or variables that programs use - this is what is meant by linking to a library, getting those symbols from the library into the application address space so they can be used
Why they are so cryptic and not Symbol12345?
A symbol from C is just so straight-forward. The encoded name you got is particular to object oriented code, because the name is not just the function name the way it is in C, it also includes information about the class it belongs to. Typically you'll see such scrambled names in C++ code, but other object oriented languages that allow linking also use it I hope this answers your question - unless you wanted the answer specifically from David Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Hello, On Sun, 26 Sep 2010, Anders Johansson wrote:
On Sunday 26 September 2010, Sascha 'saigkill' Manns wrote:
Do you know what a "Symbol" is? Anything like a pointer?
A symbol is a name in a binary. Symbols in libraries are functions, classes or variables that programs use - this is what is meant by linking to a library, getting those symbols from the library into the application address space so they can be used
Another explanation for "non-programmers" might be "the spell by which you can access some date or call some function", somewhat like a "magic spell" ;) Incant that symbol (a mangeled C++ symbol or a "clear" C symbol), and "magic" happens ;)
Why they are so cryptic and not Symbol12345?
A symbol from C is just so straight-forward. The encoded name you got is particular to object oriented code, because the name is not just the function name the way it is in C, it also includes information about the class it belongs to. Typically you'll see such scrambled names in C++ code, but other object oriented languages that allow linking also use it
I have little to add ;) And all following is just "AFAIK", I'm just an amateur in C and C++ (well, I've read K&R and Stroustrup). Sascha: they're cryptic, because g++ "mangles" i.e. "encodes" additional information (AFAIR most notably the return type and the type of arguments) in a C-compatible "name" of the symbol. That's why c++filt and the '-C' demangle option of nm (and objdump) exist. Note: the C++ stuff is mangeled so that the symbol is compatible to C, and can be called from a C-program. Only the mangling makes the symbols for the (overloaded) functions 'foo' in C++ void foo::foo(int i); void foo::foo(char c); int foo::foo(char c); void bar::foo(int i); void bar::foo(char c); int bar::foo(char c); "different" from each other, when seen from "C". Without mangling, you could only have one function "foo" in the whole of a C++ program (as with C itself), so all the C++ "qualifications" (class, return type, arguments) "would be lost" and you'd have to use void foo_class_foo_returning_void_int_arg(int i); void foo_class_foo_returning_void_char_arg(char c); int foo_class_foo_returning_int_char_arg(char c); void bar_class_foo_returning_void_int_arg(int i); void bar_class_foo_returning_void_char_arg(char c); int bar_class_foo_returning_int_char_arg(char c); or something like that instead. Nice, eh? It's ugly. You'd probably do it *completely* different in C, instead of "mangling" a C++ interface onto C. (though glib uses something seeming similar, IIRC). And there you are, in order to be able to use C++ libs from C, that's exactly what the compiler does, it mangles the C++ stuff to "cryptic" symbols in the object-code, so that all "foo" functions are different when seen from C, i.e. the compiler does all that nasty, ugly stuff for you. And there's the programs capable of demangling the symbols. Above is probably an incorrect, incomplete, ugly generalization, it's just my take on it, now, just before falling into my bed ... HTH, -dnh PS: when using C++ from C, you'll still need the C++ compiler to build the stuff, AFAIR, even though it's just "C". --
How would one crash packaging? Unexpected end-of-roll on /dev/bubblewrap System halted. -- A. D. Barratt, Tanuki -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (3)
-
Anders Johansson
-
David Haller
-
Sascha 'saigkill' Manns