Bug 191611 - databases/evolution-data-server fails to link when rebuilding because requisite library (sqlite, Berkeley DB) changed and its /usr/local has become unusable
databases/evolution-data-server fails to link when rebuilding because requisi...
Status: Closed FIXED
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s)
Latest
Any Any
: --- Affects Many People
Assigned To: gnome
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-07-04 18:25 UTC by mikhail.rokhin
Modified: 2014-07-23 17:07 UTC (History)
3 users (show)

See Also:


Attachments
enable verbose build (475 bytes, patch)
2014-07-05 12:48 UTC, Tijl Coosemans
no flags Details | Diff
evolution-data-server build failure after databases/db6 upgrade (6.53 KB, text/plain)
2014-07-16 06:57 UTC, Matthias Andree
no flags Details
proposed patch (812 bytes, patch)
2014-07-16 11:33 UTC, Tijl Coosemans
no flags Details | Diff
newer, less dangerous and more specific proposed patch, v2 (662 bytes, patch)
2014-07-16 19:04 UTC, Matthias Andree
no flags Details | Diff
full failure log of evolution-data-server build failure after db6 upgrade, compressed with xz (38.96 KB, application/octet-stream)
2014-07-16 19:05 UTC, Matthias Andree
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description mikhail.rokhin 2014-07-04 18:25:34 UTC
gmake[6]: Entering directory `/usr/ports/databases/evolution-data-server/work/evolution-data-server-2.32.1/addressbook/libedata-book'
  CCLD   e-addressbook-factory
/usr/bin/ld: warning: libsqlite3.so.8, needed by /usr/local/lib/libebook-1.2.so.10, not found (try using -rpath or -rpath-link)
/usr/local/lib/libcamel-1.2.so.19: undefined reference to `sqlite3_value_text'
/usr/local/lib/libcamel-1.2.so.19: undefined reference to `sqlite3_exec'
/usr/local/lib/libcamel-1.2.so.19: undefined reference to `sqlite3_busy_timeout'
/usr/local/lib/libcamel-1.2.so.19: undefined reference to `sqlite3_step'
/usr/local/lib/libcamel-1.2.so.19: undefined reference to `sqlite3_open'
/usr/local/lib/libcamel-1.2.so.19: undefined reference to `sqlite3_result_int'
/usr/local/lib/libcamel-1.2.so.19: undefined reference to `sqlite3_vfs_find'
/usr/local/lib/libcamel-1.2.so.19: undefined reference to `sqlite3_libversion_number'
/usr/local/lib/libcamel-1.2.so.19: undefined reference to `sqlite3_vfs_register'
/usr/local/lib/libcamel-1.2.so.19: undefined reference to `sqlite3_column_int'
/usr/local/lib/libcamel-1.2.so.19: undefined reference to `sqlite3_prepare_v2'
/usr/local/lib/libcamel-1.2.so.19: undefined reference to `sqlite3_finalize'
/usr/local/lib/libcamel-1.2.so.19: undefined reference to `sqlite3_create_function'
/usr/local/lib/libcamel-1.2.so.19: undefined reference to `sqlite3_release_memory'
/usr/local/lib/libcamel-1.2.so.19: undefined reference to `sqlite3_enable_shared_cache'
/usr/local/lib/libcamel-1.2.so.19: undefined reference to `sqlite3_create_collation'
/usr/local/lib/libcamel-1.2.so.19: undefined reference to `sqlite3_close'
/usr/local/lib/libcamel-1.2.so.19: undefined reference to `sqlite3_mprintf'
/usr/local/lib/libcamel-1.2.so.19: undefined reference to `sqlite3_errmsg'
/usr/local/lib/libcamel-1.2.so.19: undefined reference to `sqlite3_free'
cc: error: linker command failed with exit code 1 (use -v to see invocation)
gmake[6]: *** [e-addressbook-factory] Error 1
gmake[6]: Leaving directory `/usr/ports/databases/evolution-data-server/work/evolution-data-server-2.32.1/addressbook/libedata-book'
gmake[5]: *** [all] Error 2
gmake[5]: Leaving directory `/usr/ports/databases/evolution-data-server/work/evolution-data-server-2.32.1/addressbook/libedata-book'
gmake[4]: *** [all-recursive] Error 1
gmake[4]: Leaving directory `/usr/ports/databases/evolution-data-server/work/evolution-data-server-2.32.1/addressbook'
gmake[3]: *** [all-recursive] Error 1
gmake[3]: Leaving directory `/usr/ports/databases/evolution-data-server/work/evolution-data-server-2.32.1'
gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory `/usr/ports/databases/evolution-data-server/work/evolution-data-server-2.32.1'
Comment 1 Tijl Coosemans freebsd_committer 2014-07-05 12:48:41 UTC
Created attachment 144423 [details]
enable verbose build

Can you apply the attached patch and rebuild the port?  The patch enables more verbose output that'll hopefully make it easier to diagnose the problem.
Comment 2 mikhail.rokhin 2014-07-05 14:06:53 UTC
It succeeded after removing of previous version. I suppose, it's useless to repeat it with the patch as the reason of failure was removed either. May it be, that suggest of old version removal before updating is better? 

(In reply to Tijl Coosemans from comment #1)
> Created attachment 144423 [details]
> enable verbose build
> 
> Can you apply the attached patch and rebuild the port?  The patch enables
> more verbose output that'll hopefully make it easier to diagnose the problem.
Comment 3 Tijl Coosemans freebsd_committer 2014-07-05 14:42:55 UTC
(In reply to mikhail.rokhin from comment #2)
> It succeeded after removing of previous version. I suppose, it's useless to
> repeat it with the patch as the reason of failure was removed either. May it
> be, that suggest of old version removal before updating is better? 

It should still work even if you have an older version installed.  I'll try to reproduce it.
Comment 4 Mark Linimon freebsd_committer 2014-07-05 23:42:06 UTC
Over to maintainers.
Comment 5 mikhail.rokhin 2014-07-06 14:45:48 UTC
still fails. It needs lib

/usr/bin/ld: warning: libsqlite3.so.8, needed by /usr/local/lib/libebook-1.2.so.10, not found (try using -rpath or -rpath-link)

but I have those only

libsqlite3.so.0.8.6* libsqlite3.so.0@     libsqlite3.so@     

so I copied soft-link and it compiled. Obviously, there is hardcoded lib name)

(In reply to mikhail.rokhin from comment #2)
> It succeeded after removing of previous version. I suppose, it's useless to
> repeat it with the patch as the reason of failure was removed either. May it
> be, that suggest of old version removal before updating is better? 
> 
> (In reply to Tijl Coosemans from comment #1)
> > Created attachment 144423 [details]
> > enable verbose build
> > 
> > Can you apply the attached patch and rebuild the port?  The patch enables
> > more verbose output that'll hopefully make it easier to diagnose the problem.
Comment 6 Tijl Coosemans freebsd_committer 2014-07-14 12:51:02 UTC
I've tried to reproduce this now, but I cannot find anything wrong.  Can you check if you have the latest revision of /usr/ports/Mk/Uses/libtool.mk.  Right at the top of that file it should say:

$FreeBSD: head/Mk/Uses/libtool.mk 358784 2014-06-22 10:44:29Z tijl $
Comment 7 mikhail.rokhin 2014-07-14 13:35:16 UTC
I keep ports tree up-to-date. Thank you.

(In reply to Tijl Coosemans from comment #6)
> I've tried to reproduce this now, but I cannot find anything wrong.  Can you
> check if you have the latest revision of /usr/ports/Mk/Uses/libtool.mk. 
> Right at the top of that file it should say:
> 
> $FreeBSD: head/Mk/Uses/libtool.mk 358784 2014-06-22 10:44:29Z tijl $
Comment 8 Max 2014-07-14 18:35:02 UTC
Hi, 

I have the same issue. I have the latest libtool. My port tree is up to date and I recompiled the libtool.

What informations do you want ?
Comment 9 Tijl Coosemans freebsd_committer 2014-07-15 08:24:32 UTC
(In reply to Max from comment #8)
> I have the same issue. I have the latest libtool. My port tree is up to date
> and I recompiled the libtool.
> 
> What informations do you want ?

Download the patch attached to this bug and then do the following:

cd /usr/ports
patch < /path/to/downloaded/patch
cd databases/evolution-data-server
make clean
script build.log make

Then send me the file /usr/ports/databases/evolution-data-server/build.log
Comment 10 Max 2014-07-15 20:12:26 UTC
Hi,

Thanks for your response.

I received an email from Eric C. (in copy gnome@) to give a solutio:
make deinstall build reinstall clean

I tested and it worked. All is ok.

Sorry, I can't create a log of the build.

Thanks again for your time and your work.

Max
Comment 11 Matthias Andree freebsd_committer 2014-07-16 06:57:11 UTC
Created attachment 144717 [details]
evolution-data-server build failure after databases/db6 upgrade
Comment 12 Matthias Andree freebsd_committer 2014-07-16 07:01:33 UTC
I also saw this while upgrading the databases/db6 port, hence my note in ports/UPDATING.

The issue is that the build process sets the linker variables (such as LIBS, LDFLAGS) in a way that it prefers /usr/local/* libraries over the ones from WRKSRC; and if then the /usr/local/* library has become unusable through changes in one of the underlying libsqlite*so or libdb*.so files, the link fails. See my log.

The fix would be to make sure that the linker looks for the .la/.so files in WRKSRC before looking in /usr/local, whilst also making sure that WRKSRC does NOT get added through -rpath* linker options.
Comment 13 Matthias Andree freebsd_committer 2014-07-16 07:03:51 UTC
(In reply to Matthias Andree from comment #12)

> The fix would be to make sure that the linker looks for the .la/.so files in
> WRKSRC before looking in /usr/local, whilst also making sure that WRKSRC
> does NOT get added through -rpath* linker options.

Sorry for following up on myself, -rpath-link would be safe.
Comment 14 Tijl Coosemans freebsd_committer 2014-07-16 07:05:24 UTC
Can you apply the patch attached to this bug to generate a more verbose build log?
Comment 15 Tijl Coosemans freebsd_committer 2014-07-16 11:33:43 UTC
Created attachment 144725 [details]
proposed patch

The problem is that when you link an executable with libA, while libA depends on libB, ld(1) will also check libB for unresolved symbols, but it searches for libB in paths provided by -rpath-link, -rpath and -L flags first before asking libA where it thinks it can find libB.  I consider this a bug in ld(1).  It should check the libA runpath first, but frankly it should not check indirect dependencies at all.  The attached patch adds -Wl,--allow-shlib-undefined to LDFLAGS so ld(1) stops complaining.
Comment 16 Matthias Andree freebsd_committer 2014-07-16 19:04:03 UTC
tl;dr: 1. --allow-shlib-undefined is dangerous and can result in non-working executables.  2. Your patch drops the .a files, requiring a pkg-plist change.  3. I propose to work around this problem by patching LDCONFIG; I am attaching my proposed minimal patch.


These are the relevant parts of my debugging session.


Let's start at the failure. I ran the build, and re-ran it without cleaning with MAKE_JOBS_UNSAFE to single out the first failure, which is:

> gmake[4]: Entering directory `/var/tmp/usr/ports.svn/databases/evolution-data-server/work/evolution-data-server-2.32.1/calendar/libedata-cal'
> /bin/sh ../../libtool  --tag=CC   --mode=link cc  -O2 -pipe -march=athlon64 -fstack-protector -DLDAP_DEPRECATED -fno-strict-aliasing  -L/usr/local/lib -pthread -fstack-protector  -o test-e-sexp test_e_sexp-e-cal-backend-sexp.o -lical libedata-cal-1.2.la ../../calendar/libecal/libecal-1.2.la ../../libedataserver/libedataserver-1.2.la -lxml2 -lsoup-2.4 -lgio-2.0 -lgobject-2.0 -lgconf-2 -lglib-2.0 -lintl -L/usr/local/lib -lplds4 -lplc4 -lnspr4 -pthread     
> libtool: link: cc -O2 -pipe -march=athlon64 -fstack-protector -DLDAP_DEPRECATED -fno-strict-aliasing -pthread -fstack-protector -o .libs/test-e-sexp test_e_sexp-e-cal-backend-sexp.o -pthread  -L/usr/local/lib -lical ./.libs/libedata-cal-1.2.so ../../calendar/libecal/.libs/libecal-1.2.so ../../libedataserver/.libs/libedataserver-1.2.so /usr/local/lib/libxml2.so /usr/local/lib/libsoup-2.4.so /usr/local/lib/libgio-2.0.so /usr/local/lib/libgobject-2.0.so /usr/local/lib/libgconf-2.so /usr/local/lib/libglib-2.0.so /usr/local/lib/libintl.so -lplds4 -lplc4 -lnspr4 -pthread -Wl,-rpath -Wl,/usr/local/lib
> /usr/bin/ld: warning: libdb-6.0.so, needed by /usr/local/lib/libebackend-1.2.so.0, not found (try using -rpath or -rpath-link)
> /usr/local/lib/libebackend-1.2.so.0: undefined reference to `db_create'


OK, so let's see who is pulling in libebackend-1.2.so.0 from $PREFIX/$LOCALBASE:

> $ "/usr/bin/ld" --verbose "--eh-frame-hdr" "-dynamic-linker" "/libexec/ld-elf.so.1" "--hash-style=both" "--enable-new-dtags" "-o" ".libs/test-e-sexp" "/usr/lib/crt1.o" "/usr/lib/crti.o" "/usr/lib/crtbegin.o" "-L/usr/local/lib" "-L/usr/lib" "-L/usr/lib" "test_e_sexp-e-cal-backend-sexp.o" "-lical" "./.libs/libedata-cal-1.2.so" "../../calendar/libecal/.libs/libecal-1.2.so" "../../libedataserver/.libs/libedataserver-1.2.so" "/usr/local/lib/libxml2.so" "/usr/local/lib/libsoup-2.4.so" "/usr/local/lib/libgio-2.0.so" "/usr/local/lib/libgobject-2.0.so" "/usr/local/lib/libgconf-2.so" "/usr/local/lib/libglib-2.0.so" "/usr/local/lib/libintl.so" "-lplds4" "-lplc4" "-lnspr4" "-rpath" "/usr/local/lib" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "-lpthread" "-lc" "-lssp_nonshared" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "/usr/lib/crtend.o" "/usr/lib/crtn.o" 
> ...
> libpcre.so.3 needed by ./.libs/libedata-cal-1.2.so
> found libpcre.so.3 at /usr/local/lib/libpcre.so.3
> libebackend-1.2.so.0 needed by ./.libs/libedata-cal-1.2.so
> found libebackend-1.2.so.0 at /usr/local/lib/libebackend-1.2.so.0

WHOOPS!  We need libebackend from $WRKSRC/libebackend/.libs/ instead!

We see that the libedata-cal-1.2.so is where the trouble starts.  Let's investigate it:

> $ readelf -d .libs/libedata-cal-1.2.so
> 0x0000000000000001 (NEEDED)             Shared library: [libc.so.7]
> 0x000000000000000e (SONAME)             Library soname: [libedata-cal-1.2.so.10]
> 0x000000000000000f (RPATH)              Library rpath: [/var/tmp/usr/ports.svn/databases/evolution-data-server/work/evolution-data-server-2.32.1/calendar/libecal/.libs:/usr/local/lib:/var/tmp/usr/ports.svn/databases/evolution-data-server/work/evolution-data-server-2.32.1/libedataserver/.libs:/var/tmp/usr/ports.svn/databases/evolution-data-server/work/evolution-data-server-2.32.1/libebackend/.libs]
> 0x000000000000001d (RUNPATH)            Library runpath: [/var/tmp/usr/ports.svn/databases/evolution-data-server/work/evolution-data-server-2.32.1/calendar/libecal/.libs:/usr/local/lib:/var/tmp/usr/ports.svn/databases/evolution-data-server/work/evolution-data-server-2.32.1/libedataserver/.libs:/var/tmp/usr/ports.svn/databases/evolution-data-server/work/evolution-data-server-2.32.1/libebackend/.libs]


And there you have it: /usr/local/lib is before the ../libebackend/.libs, and this is what screws the build.  Now let's see how this broken libedata-cal-1.2.so.10 got linked; further up in the full log I see:

> libtool: link: cc -shared  .libs/libedata_cal_1_2_la-e-data-cal-enumtypes.o .libs/libedata_cal_1_2_la-e-cal-backend.o .libs/libedata_cal_1_2_la-e-cal-backend-cache.o .libs/libedata_cal_1_2_la-e-cal-backend-factory.o .libs/libedata_cal_1_2_la-e-cal-backend-intervaltree.o .libs/libedata_cal_1_2_la-e-cal-backend-sexp.o .libs/libedata_cal_1_2_la-e-cal-backend-sync.o .libs/libedata_cal_1_2_la-e-cal-backend-util.o .libs/libedata_cal_1_2_la-e-cal-backend-store.o .libs/libedata_cal_1_2_la-e-cal-backend-file-store.o .libs/libedata_cal_1_2_la-e-data-cal.o .libs/libedata_cal_1_2_la-e-data-cal-view.o  -Wl,--whole-archive ../../calendar/libegdbus/.libs/libegdbus-cal.a -Wl,--no-whole-archive  -Wl,-rpath -Wl,/var/tmp/usr/ports.svn/databases/evolution-data-server/work/evolution-data-server-2.32.1/calendar/libecal/.libs -Wl,-rpath -Wl,/usr/local/lib -Wl,-rpath -Wl,/var/tmp/usr/ports.svn/databases/evolution-data-server/work/evolution-data-server-2.32.1/libedataserver/.libs -Wl,-rpath -Wl,/var/tmp/usr/ports.svn/databases/evolution-data-server/work/evolution-data-server-2.32.1/libebackend/.libs -Wl,-rpath -Wl,/usr/local/lib -L/usr/local/lib ../../calendar/libecal/.libs/libecal-1.2.so /usr/local/lib/libgtk-x11-2.0.so /usr/local/lib/libgdk-x11-2.0.so /usr/local/lib/libpangocairo-1.0.so /usr/local/lib/libXext.so /usr/local/lib/libXrender.so /usr/local/lib/libXinerama.so /usr/local/lib/libXi.so /usr/local/lib/libXrandr.so /usr/local/lib/libXcursor.so /usr/local/lib/libXcomposite.so /usr/local/lib/libXdamage.so /usr/local/lib/libXfixes.so /usr/local/lib/libX11.so /usr/local/lib/libatk-1.0.so /usr/local/lib/libcairo.so /usr/local/lib/libgdk_pixbuf-2.0.so /usr/local/lib/libpangoft2-1.0.so /usr/local/lib/libpango-1.0.so /usr/local/lib/libfontconfig.so /usr/local/lib/libfreetype.so /usr/local/lib/libORBit-2.so /usr/local/lib/libgthread-2.0.so /usr/local/lib/libgdata.so /usr/local/lib/libsoup-2.4.so /usr/local/lib/libgmodule-2.0.so -lz /usr/local/lib/libffi.so /usr/local/lib/libiconv.so /usr/local/lib/libpcre.so ../../libedataserver/.libs/libedataserver-1.2.so ../../libebackend/.libs/libebackend-1.2.so /usr/local/lib/libgio-2.0.so /usr/local/lib/libgobject-2.0.so -lical -licalss -licalvcal /usr/local/lib/libxml2.so /usr/local/lib/libgconf-2.so /usr/local/lib/libglib-2.0.so /usr/local/lib/libintl.so  -march=athlon64 -pthread -pthread   -pthread -Wl,-soname -Wl,libedata-cal-1.2.so.10 -o .libs/libedata-cal-1.2.so.10.0.0

So what we see here is that libebackend/.libs/libebackend-1.2.so gets linked by relative path, AND there is a corresponding "-Wl,-rpath -Wl,/var/tmp/usr/ports.svn/databases/evolution-data-server/work/evolution-data-server-2.32.1/libebackend/.libs" option pair, but it is before the /usr/local/lib.  That's what breaks the build with the unusable older package installed.

I propose to prefix the libebackend/.libs through -rpath-link grafted early in LDFLAGS, that works for me.  See the proposed newer patch.
Comment 17 Matthias Andree freebsd_committer 2014-07-16 19:04:45 UTC
Created attachment 144732 [details]
newer, less dangerous and more specific proposed patch, v2
Comment 18 Matthias Andree freebsd_committer 2014-07-16 19:05:32 UTC
Created attachment 144733 [details]
full failure log of evolution-data-server build failure after db6 upgrade, compressed with xz
Comment 19 Matthias Andree freebsd_committer 2014-07-16 19:08:37 UTC
(In reply to Matthias Andree from comment #16)

> So what we see here is that libebackend/.libs/libebackend-1.2.so gets linked
> by relative path, AND there is a corresponding "-Wl,-rpath
> -Wl,/var/tmp/usr/ports.svn/databases/evolution-data-server/work/evolution-
> data-server-2.32.1/libebackend/.libs" option pair, but it is before the

This should have been "but it is *AFTER* the /usr/local/lib"

> /usr/local/lib.  That's what breaks the build with the unusable older
> package installed.
Comment 20 Matthias Andree freebsd_committer 2014-07-16 19:18:12 UTC
If https://bugs.freebsd.org/bugzilla/attachment.cgi?id=144732 gets committed, we can drop the evolution-data-server from ports/UPDATING, too.
Comment 21 Tijl Coosemans freebsd_committer 2014-07-16 19:25:49 UTC
(In reply to Matthias Andree from comment #19)
> (In reply to Matthias Andree from comment #16)
> > So what we see here is that libebackend/.libs/libebackend-1.2.so gets linked
> > by relative path, AND there is a corresponding "-Wl,-rpath
> > -Wl,/var/tmp/usr/ports.svn/databases/evolution-data-server/work/evolution-
> > data-server-2.32.1/libebackend/.libs" option pair, but it is before the
> 
> This should have been "but it is *AFTER* the /usr/local/lib"
> 
> > /usr/local/lib.  That's what breaks the build with the unusable older
> > package installed.

Yes, but that's not the full story.  The problem is that when linking/running an executable the rpath of the executable is searched before any rpaths of libraries.  The executables here already have /usr/local/lib as rpath so the rpaths of the libraries being slightly wrong has no effect here.  I'm going to revert the first half of http://svnweb.freebsd.org/changeset/ports/358784
Comment 22 Matthias Andree freebsd_committer 2014-07-16 19:30:50 UTC
The problem is *only* linking further .la files, not running executables.  I actually built e-d-s with db-6.0, broke db6 by upgrading it to db-6.1 so as to reproduce the problem, and then build with the patch, which fixed the problem.

If you are aiming for a more general fix that is fine, but you still need to fix the bogus library path specification in evolution-data-server's LDFLAGS.

Tijl, in Comment #21 you wrote:
> I'm going to revert the first half of http://svnweb.freebsd.org/changeset/ports/358784

I see that that touches many many files, so "first half" looks unclear to me.
Comment 23 Tijl Coosemans freebsd_committer 2014-07-16 19:39:29 UTC
(In reply to Matthias Andree from comment #22)
> Tijl, in Comment #21 you wrote:
> > I'm going to revert the first half of http://svnweb.freebsd.org/changeset/ports/358784
> 
> I see that that touches many many files, so "first half" looks unclear to me.

The first paragraph of the commit log.
Comment 24 Tijl Coosemans freebsd_committer 2014-07-16 19:53:20 UTC
(In reply to Tijl Coosemans from comment #23)
> (In reply to Matthias Andree from comment #22)
> > Tijl, in Comment #21 you wrote:
> > > I'm going to revert the first half of http://svnweb.freebsd.org/changeset/ports/358784
> > 
> > I see that that touches many many files, so "first half" looks unclear to me.
> 
> The first paragraph of the commit log.

To elaborate on this, it will cause libebackend to be linked into executables via libtool overlinking and the executable will have the correct rpath then.  That will also fix the test executables like calendar/libedata-cal/test-intervaltree which still print an error when you run them: "libdb-6.0.so" not found, required by "libebackend-1.2.so.0"

Relying on overlinking like that isn't ideal, but I can think of other scenarios in which the Debian changes in r358784 would fail so I need to revert them anyway.
Comment 25 commit-hook freebsd_committer 2014-07-23 10:28:55 UTC
A commit references this bug:

Author: tijl
Date: Wed Jul 23 10:28:10 UTC 2014
New revision: 362656
URL: http://svnweb.freebsd.org/changeset/ports/362656

Log:
  Remove two libtool fixes from Mk/Uses/libtool.mk.  They don't always work
  when an older version of a package is installed.  This is the case when an
  executable links with installed libraries and with uninstalled libraries
  that link with other uninstalled libraries.  For each of the directly
  linked libraries the executable will have an rpath (/usr/local/lib for the
  installed libraries and a path under WRKDIR for each of the uninstalled
  libraries), but not for the indirect libraries.  Both ld(1) and rtld(1)
  search the rpath of the executable first before any rpath of libraries, so
  the indirectly linked libraries will be found in /usr/local/lib if they are
  installed instead of in WRKDIR.

  With this commit executables will overlink with uninstalled indirect
  libraries again so their location is added to the rpath of the executable.

  This partially reverts r358784.

  PR:		191611
  Approved by:	portmgr (bapt)

Changes:
  head/Mk/Uses/libtool.mk
  head/archivers/rpm4/Makefile
  head/databases/evolution-data-server/Makefile
  head/databases/gdbm/Makefile
  head/devel/anjuta/Makefile
  head/devel/gettext/files/patch-gettext-tools_src_Makefile.in
  head/devel/gitg0/Makefile
  head/devel/gnome-vfs/Makefile
  head/devel/libbonobo/files/patch-samples-echo-Makefile.in
  head/devel/libgii/Makefile
  head/devel/ois/Makefile
  head/graphics/devil/Makefile
  head/graphics/geomview/Makefile
  head/graphics/libggi/Makefile
  head/graphics/libgnomecanvas/files/patch-demos-Makefile.in
  head/graphics/swfdec/Makefile
  head/irc/xchat/Makefile
  head/mail/evolution/Makefile
  head/multimedia/mjpegtools/files/patch-mplex__Makefile.in
  head/net/gtk-vnc/Makefile
  head/net/libgweather/Makefile
  head/security/sssd/Makefile
  head/sysutils/tracker-client/Makefile
  head/www/gtkhtml3/Makefile
  head/x11/gnome-panel/Makefile
  head/x11-toolkits/gdl/Makefile
  head/x11-toolkits/libgdiplus/Makefile
  head/x11-toolkits/open-motif/Makefile
  head/x11-wm/mutter/Makefile
Comment 26 Tijl Coosemans freebsd_committer 2014-07-23 10:32:58 UTC
Fixed in r362656.
Comment 27 commit-hook freebsd_committer 2014-07-23 17:07:17 UTC
A commit references this bug:

Author: mandree
Date: Wed Jul 23 17:06:28 UTC 2014
New revision: 362711
URL: http://svnweb.freebsd.org/changeset/ports/362711

Log:
  Drop UPDATING section on evolution-data-server deinstall before db6 upgrade,
  no longer necessary as of r362656.

  PR:		191611

Changes:
  head/UPDATING