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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem