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.
