Libtool and Support for Shared Libraries (3)

[Greg Banks]

On Fri, Jun 29, 2012, at 02:20 AM, Florian Pflug wrote:
> On Jun28, 2012, at 01:53 , Greg Banks wrote:
> > On Wed, Jun 27, 2012, at 04:36 PM, Dilyan Palauzov wrote:
> >> Moreover, does it make any difference, if imapd links with 
> >> libcyrus_sieve and libcyrus_sieve links with libcom_err, or if imapd 
> >> links explicitly with both libcyrus_sieve and libcom_err ?
> > 
> > Very little.  It really only matters for shared libraries which are
> > going to be dlopen()ed, of which we currently have none
> 
> Hm, I think this matters on OSX. On that OS, you only "see" the symbols
> exported by libraries you link to directly, not the ones pulled in
> indirectly.

Interesting.  The OSX ld(1) manage says

   Indirect dynamic libraries
     If the command line specifies to link against dylib A, and when
     dylib A
     was built it linked against dylib B, then B is considered an
     indirect
     dylib.  When linking for two-level namespace, ld does not look at
     indi-
     rect dylibs, except when re-exported by a direct dylibs.  On the
     other
     hand when linking for flat namespace, ld does load all indirect
     dylibs
     and uses them to resolve references.  Even though indirect dylibs
     are
     specified via a full path, ld first uses the specified search paths
     to
     locate each indirect dylib.  If one cannot be found using the
     search
     paths, the full path is used.

So it seems to make a difference to symbol visibility - symbols in
directly linked libs have more visibility.  In that case, we actually
*want* to change to linking -lcom_err directly so that the main
executables can call error_message().


-- 
Greg.