Testing internal classes

[Thiago Macieira]

Friedrich W. H. Kossebau wrote:
>Yes, but the .o files do have their symbol table, too, don't they?

Yes. So, if you link the .o into your test program, it'll work.

>> Static libraries (.a), however, aren't created by the linker. They are
>> created by ar (archive). They could just as well be a .zip, .jar or
>> .tar (trivia: tar = Tape ARchive and the command line is very similar
>> to ar).
>
>Yes :) But isn't  there an additional file/section listing the symbols
> of all included .o files? Which can be called symbol table, too?

Yes, but it's optional. It's created by ranlib.

>> No, you can't do that. In ELF binaries, the symbols are matched to by
>> their names, not by their addresses. That's why they are dynamically
>> linked: it's the dynamic linker (not the static linker, ld) that binds
>> those symbols.
>
>Yes, but doesn't it still bind to addresses, by the symbols?
>And I rather meant, that the linker keeps in a separate section the full
>symbol table. But I doubt this will be supported by a lot of
>compiler/linker...

This isn't supported by any linker or dynamic linker. Unless you start 
hacking GNU ld and GNU libc (which contains ld-linux.so.2), you won't get 
this functionality. Then you'll have to do it again for other platforms.

Your only other option is to keep an entire new library with those 
symbols. Maybe our debug build could do like that: no symbol hiding.

>Could the same library then be used to create the dynamic one?

Yes, the same .o can be used to create both the shared library and the 
static library.

Building the .so from the .a is not portable: it requires the GNU ld 
program (the --whole-archive option).

-- 
Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
  thiago.macieira (AT) trolltech.com     Trolltech AS
    GPG: 0x6EF45358                   |  Sandakerveien 116,
    E067 918B B660 DBD1 105C          |  NO-0402
    966C 33F5 F005 6EF4 5358          |  Oslo, Norway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060510/52b7cdc3/attachment.sig>