[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r38120 - in trunk: . build/ac-macros subversion/bindings/swig/perl/native

From: Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA_at_GMail.Com>
Date: Mon, 22 Jun 2009 21:45:20 +0200

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.