Split building

[Thiago Macieira]

Thiago Macieira wrote:
>We have the following situation:
>        libA contains symbol X
>        libB links to libA
>        libC is what we are building
>                libC links to libB
>                libC has an undefined reference to X
>
>I had assumed so far that the above situation would work because libA
> (and X) would be found indirectly. That is failing for our scenario.

I have confirmed that case... It's caused by --no-undefined, which makes 
ld(1) try to resolve ALL symbols. It *only* searches the libraries you 
tell it to, not the indirect libraries.

This problem isn't new:

http://lists.kde.org/?l=kde-buildsystem&m=116644629533573&w=2
"Any application should list in CMake all its direct dependencies and only 
them."

http://lists.kde.org/?l=kde-buildsystem&m=113280651311875&w=2
I did not test with --no-undefined, apparently, which led me to believe 
that ld did search the indirect dependencies. In fact, it did not search 
the indirect libs, but it also did not complain that a symbol was left 
undefined.

http://lists.kde.org/?l=kde-buildsystem&m=116644629533575&w=2
dfaure had asked for a way of turning this behaviour on on Linux/ELF. I 
had said I did not know of a way -- I was wrong. We have that behaviour 
and we have had it for years. The only problem is that CMake (and 
libtool!) adds all dependencies' dependencies to the link command-line, 
thereby bypassing the behaviour we want.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20080107/70a39063/attachment.pgp