2009-06-22 20:09:30 Branko Cibej napisał(a):
> Arfrever Frehtes Taifersar Arahesis wrote:
> > 2009-06-22 12:43:04 Branko Čibej napisał(a):
> >
> >> Arfrever Frehtes Taifersar Arahesis wrote:
> >>
> >>> 2009-06-21 23:25:15 Greg Stein napisał(a):
> >>>
> >>>
> >>>> On Sun, Jun 21, 2009 at 03:40, Arfrever Frehtes Taifersar
> >>>> Arahesis<Arfrever.FTA_at_gmail.com> wrote:
> >>>>
> >>>>
> >>>>> ...
> >>>>>
> >>>>>
> >>>>>> If expat was being found just fine before r38120
> >>>>>>
> >>>>>>
> >>>>> It was being found only because APR-Util was accidentally linked against Expat
> >>>>> and apu-1-config was providing path to Expat directory which was used during
> >>>>> building of APR-Util.
> >>>>>
> >>>>>
> >>>> That is NOT an "accident". That is entirely by design.
> >>>>
> >>>>
> >>> So the design is broken.
> >>> Even libaprutil-1.so isn't linked against libraries printed by
> >>> `apu-1-config --libs`, so linking against these libraries would slow down
> >>> Subversion at run-time (ld.so would have to load attitional libraries).
> >>>
> >>> $ apu-1-config --libs
> >>> -lldap -llber -llber -ldb-4.7 -lgdbm -lexpat
> >>> $ scanelf -qF '%F: %n' /usr/lib64/libaprutil-1.so
> >>> /usr/lib64/libaprutil-1.so: libexpat.so.1,libapr-1.so.0,libcrypt.so.1,libpthread.so.0,libc.so.6
> >>>
> >>>
> >> Everyting that apu-1-config prints comes from the APR-util link command
> >> line ... so, maybe there's a -Wl,--as-needed in there somewhere.
> >>
> >
> > libaprutil-1.so dynamically loads modules (when they are needed) placed
> > in $(libdir)/apr-util-1 which are linked against appropriate libraries.
> >
> > $ scanelf -qF '%F: %n' /usr/lib64/apr-util-1/*-1.so
> > /usr/lib64/apr-util-1/apr_crypto_nss-1.so: libnspr4.so.7,libnss3.so.12,libpthread.so.0,libc.so.6
> > /usr/lib64/apr-util-1/apr_crypto_openssl-1.so: libcrypto.so.0.9.8,libpthread.so.0,libc.so.6
> > /usr/lib64/apr-util-1/apr_dbd_odbc-1.so: libodbc.so.1,libpthread.so.0,libc.so.6
> > /usr/lib64/apr-util-1/apr_dbd_sqlite3-1.so: libsqlite3.so.0,libpthread.so.0,libc.so.6
> > /usr/lib64/apr-util-1/apr_dbm_db-1.so: libdb-4.7.so,libpthread.so.0,libc.so.6
> > /usr/lib64/apr-util-1/apr_dbm_gdbm-1.so: libgdbm.so.3,libpthread.so.0,libc.so.6
> > /usr/lib64/apr-util-1/apr_ldap-1.so: libldap-2.4.so.2,libpthread.so.0,libc.so.6
> >
> > Subversion doesn't use any APR-Util function which would cause loading of these modules.
> >
>
> But even if it did, that wouldn't require Subversion to link those
> modules directly, right?
Yes.
> How does that affect the way we look for expat?
Subversion was relying on `apu-1-config --libs` printing '-lexpat' and
sometimes appropriate -L option pointing to directory containing libexpat.so.
Unfortunately `apu-1-config --libs` often prints names of libraries other than
'-lexpat'. Theoretically r38132+r38133 should cause falling back to this older
behavior when libexpat.so wasn't found in standard location (/usr/lib). The new
--with-expat option also allows to directly specify location of libexpat.so.
--
Arfrever Frehtes Taifersar Arahesis
Received on 2009-06-22 21:44:59 CEST