Q: (g++) Striping the function names I have problem with g++ it doesn't strip names of my functions, i can open my program in (for example) ida and see names of all functions, global variables etc. I'd like to strp all of them (so it's like sub_xxxxxxx) 
This is my compiling file.
g++ -O3 -s -Wall -fPIC -Wl,-E -masm=intel -I/usr/local/include -L/usr/local/lib -shared -o preload_new.so hook_tools.cpp SCHAR.cpp ITEM.cpp ITEM_MANAGER.cpp SCHAR_MANAGER.cpp SECTREE_MANAGER.cpp main.cpp ip_secure_main.cpp commands.cpp character_hooks.cpp costumes.cpp


A: The command line shows you are compiling a shared library. It exports all functions and variables, not declared "static", by design, and that's what required from shared object making. You can't hide all these names without breaking the shared object functionality because another object which loads it can't find these symbols.
OTOH you can control visibility of most names using, literally, gcc visibility options (-fvisibility=) and the same name function attributes. They are generally enough to control what is seen in the library exports. You can read this book for detailed explanation. (BTW why do you use -masm=intel unless it's Windows?)
UPDATE[2013-12-27]: example:

$ cat t1.c
int t11(void)
{ return 11; }
int t12(void) __attribute__((visibility("hidden")));
int t12(void)
{ return 12; }
$ cat t2.c
int t21(void)
{ return t11()+10; }
int t22(void)
{ return t12()+10; }
$ cat t.c
int main() {
        printf("%d %d %d\n", t11(), t21(), t22());
        return 0;
}
$ cat Makefile
all: t

t: libtt.so
        gcc -o t t.c libtt.so -Wl,-rpath=`pwd`

libtt.so: t1.c t2.c
        gcc -o libtt.so -shared t1.c t2.c -fPIC
$ nm -D libtt.so | fgrep -w T
0000000000000598 T _fini
0000000000000438 T _init
0000000000000500 T t11
0000000000000520 T t21
0000000000000540 T t22
$ ./t
12 22 23

You can see library is built without unresolved systems warnings, and binary runs, but t12 isn't exported. If to comment out the body of t12(), the shared library building will succeed, but the executable linking will fail. If to add printing t12() result to the executable, linking will also fail.
