Testing internal classes

[Friedrich W. H. Kossebau]

Am Mittwoch, 10. Mai 2006 19:43, schrieb Thiago Macieira:
> Friedrich W. H. Kossebau wrote:
> >Such thing as? How would convenience lib then be linked in if at this
> > point symbols were already restricted to the explicit visible ones?
>
> Because you had a .a file (which is basically just a collection of .o),
> not a shared library. When the *linker* creates an .so, it drops the
> HIDDEN symbols from the dynamic symbol table. That's why applications
> can't link to them.

Yes, but the .o files do have their symbol table, too, don't they?

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

> >So if additionally the full symbol table (and inline function data) is
> > still separatly available (in some section, before stripping) the lib
> > could be also linked using the intern symbols (whose points they refer
> > to are nevertheless still there, aren't they?).
>
> 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...

> >Was in the old build system the visibility flag only used for non-debug
> >versions? And now it's not? This would give a reason why the same setup
> >worked with the old build system (auto*), that is for sure :)
>
> There was no difference to the flag. You're seeing it more often now
> because Qt4 supports it, while Qt3 didn't.
>
> If your Qt3 wasn't patched to support the flag, KDE wasn't compiled with
> it either.

Ah, that's it. Of course. #) Sorry, I forgot that I previously never had the 
flag in use, duh. 

> >Someone with the clue what to do best?
>
> Solution: create static libraries and link to them in the tests.
>
> Static libraries require keeping the dependency information in an extra
> file, like libtool's .la.

May I ask how this would be done im cmake syntax?
And to complete my (and others) needs:
Could the same library then be used to create the dynamic one?
How to reference the uninstalled static library?
Any examples in kde* where this is already done?

Thanks for your patience
Friedrich
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060510/3054ce86/attachment.sig>