Mailinglist Archive: opensuse (1839 mails)

< Previous Next >
Re: [opensuse] quasselcore doesn't run
  • From: David Haller <dnh@xxxxxxxxxxxx>
  • Date: Sun, 26 Sep 2010 21:36:51 +0200
  • Message-id: <20100926193651.GA8799@xxxxxxxxxxxxxxxxxx>

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 ...


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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx

< Previous Next >