Relinking objects with libstdc++ and local symbols

[John Smith]

I wrote some code in C++ which I compiled into an object file foo.o
This object has some dependencies to libstdc++ which I want to avoid.

From another earlier request in this group I got the following advice:

> ld -r foo.o /usr/lib/libstdc++.a -o foo1.o
> objcopy -G foo1 -G foo2 ... -G fooN foo1.o -o foo.o

This step relinks my object with libstdc++ so any C++ dependencies gets
merged into my object. Filesize grows but the dependency for libstdc++
should be removed and the only undefined symbols are to libc.

Now the problem is that the libstdc++ symbols gets redefined from undefined
to defined. nm utility will still show the symbols though.

The objcopy step will mark my own functions as global, which is good, and
make all the libstdc++ functions into locals.

One example from nm:
00000000 t _ZNSt8ios_base4Init14_S_ios_destroyEv

00000000 d _ZNSt8ios_base4Init16_S_ios_base_initE

00000000 d _ZNSt8ios_base4Init20_S_synced_with_stdioE

00000000 t _ZNSt8ios_base4InitC1Ev

But what exactly does it mean when the symbols are local?

What I wanted is to enable the user of my object to use gcc instead of g++
as frontend linker. This works now. However I tried to strip the symbolnames
and when doing so the linked program will crash.

I assume that since the symbols are local now instead of global (before the
objcopy step) I will not have any incompatibilities if users use another
version libstdc++ and/or gcc (except ABI problems which I don't think of
here). In other words if I used libstdc++ 3.4.1 and user uses 3.4.2 it will
still work since the c++ code is wrapped inside my object now.

Any comments are welcome here. I think it's a hard subject and theres very
little material on the net about it. Maybe I assumed something wrong. Please
tell me if you know better.

Thanks in advance.

-- John

[Paul Pluzhnikov]

"John Smith" <john....@x-formation.com> writes:

> But what exactly does it mean when the symbols are local?

It means they are not considered by the linker at all when your
object is linked with anything else. Their only remaining reason
for existance is to assist you in debugging.

> However I tried to strip the symbolnames
> and when doing so the linked program will crash.

Well, either 'strip' is broken, or there is another reason for
these symbols. You aren't throw()ing exceptions in your code,
are you?

> Any comments are welcome here.

Posting the crash stack trace, or (even better) making a simple
test case demonstrating the problem with stripped object, may add
substance to this discussion.

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

[John Smith]

> > However I tried to strip the symbolnames
> > and when doing so the linked program will crash.
>
> Well, either 'strip' is broken, or there is another reason for
> these symbols. You aren't throw()ing exceptions in your code,
> are you?
>

No, no exceptions are thrown. I don't think strip is broken though.

Unfortunatly I don't have any sample code right here (because I got my
problem fixed) but I experienced something similar on both linux and mac os
in different scenarios. For some reason it seems the loader needs the names,
or atleast some of them, (global or local) to be able to work right.

Instead of using strip I used objcopy with -G switch to make global symbols
into local on linux and on mac os I used nmedit. This works perfectly.

-- John