Bug 199746 - [patch] mail/evolution builds but does not run on FreeBSD 8.4 (and probably 9.3)
Summary: [patch] mail/evolution builds but does not run on FreeBSD 8.4 (and probably 9.3)
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-gnome (Nobody)
URL:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2015-04-28 00:11 UTC by Don Lewis
Modified: 2015-04-29 21:44 UTC (History)
0 users

See Also:
bugzilla: maintainer-feedback? (gnome)


Attachments
patch to fix evolution startup error on FreeBSD 8.4 (1.56 KB, patch)
2015-04-28 00:11 UTC, Don Lewis
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Don Lewis freebsd_committer freebsd_triage 2015-04-28 00:11:43 UTC
Created attachment 156058 [details]
patch to fix evolution startup error on FreeBSD 8.4

The addition of USES=compiler:c++11-lib to evolution/Makefile in r377107 unbroke the build on FreeBSD 8.4, but it fails to run and throws this error:

%evolution
/libexec/ld-elf.so.1: /usr/lib/libstdc++.so.6: version GLIBCXX_3.4.14 required by /usr/local/lib/libwebkitgtk-3.0.so.0 not found

The build was fixed because USES=compiler:c++11-lib adds -L/usr/local/lib/gcc48 to LDFLAGS, so ld finds the version of libstdc++ that is bundled with the gcc port.  It also adds /usr/local/lib/gcc48 to evolution executable rpath.  This does not fix the runtime problem because evolution seems to only contain C code and does not get linked to libstdc++.  This seems to cause rtld to ignore the /usr/local/lib/gcc48 rpath of the executable.  When rtld is loading the shared libraries that are directly referenced by evolution, the first of those that references libstdc++ governs which version of libstdc++ is loaded.  If that shared library was linked to libstdc++ in base, then the base version gets loaded, and when libwebkitgtk-3.0 is loaded, it does not get the newer version of libstdc++ that it expects.

In this case, the first shared library loaded by rtld for evolution that wants libstdc++ is /usr/local/lib/libebook-1.2, which is part of databases/evolution-data-server, and it is linked to the base version of libstdc++.

If evolution-data-server is built with USES=compiler:c++11-lib, then it has /usr/local/lib/gcc48 added to its rpath, which causes libstdc++ from the gcc port to get loaded.  That satisfies the requirements for webkit-gtk3 and allows evolution run.

It is not necessary to make this conditional on OSVERSION and doing so will not fix the problem in some corner cases.  When building on FreeBSD 10 and higher where the base compiler is clang, USES=compiler:c++11-lib is basically a no-op and is therefore harmless.  I believe that building FreeBSD 10 with the base gcc compiler (and without clang) is supposed to be supported on amd64 and i386, and is mandatory on some of the tier 2 platforms that clang does not support.   In this case, USES=compiler:c++11-lib is needed to avoid the same breakage as on FreeBSD 8 and 9.
Comment 1 commit-hook freebsd_committer freebsd_triage 2015-04-29 17:05:38 UTC
A commit references this bug:

Author: truckman
Date: Wed Apr 29 17:05:20 UTC 2015
New revision: 384997
URL: https://svnweb.freebsd.org/changeset/ports/384997

Log:
  Remove USES=compiler:c++11-lib from mail/evolution.  While it fixes
  the build failure on FreeBSD 8 (and probably 9), the application
  fails to start because the base version of libstdc++ is loaded at
  runtime, which does not satify the requirements of webkit-gtk3.  The
  reason is that evolution does not directly link to libstdc++, so
  the rpath added to it by USES=compiler:c++11-lib has no effect.  The
  first shared library that links to libstdc++ belongs to
  evolution-data-server, which does not have USES=compiler:c++11-lib,
  which causes the base version of libstdc++ to be loaded.

  Unconditionally add USES=compiler:c++11-lib to
  databases/evolution-data-server.  Adding the rpath to its shared
  libraries will cause the newer version of libstdc++ to be loaded
  when evolution starts and fix the runtime error on FreeBSD 8 and
  9.  For standard versions of FreeBSD 10 and higher on amd64 and
  i386, it is a no-op, so there is no harm in doing this. If FreeBSD
  10 or higher is configured to build with base gcc and clang is not
  present, which is an option on amd64 and i386 and is mandatory on
  some tier 2 platforms that don't have clang support, then
  USES=compiler:c++11-lib is needed.

  PR:		199746
  Differential Revision:	https://reviews.freebsd.org/D2388
  Reviewed by:	kwm
  Approved by:	mat (mentor)
  MFH:		2015Q2

Changes:
  head/databases/evolution-data-server/Makefile
  head/mail/evolution/Makefile
Comment 2 commit-hook freebsd_committer freebsd_triage 2015-04-29 21:44:05 UTC
A commit references this bug:

Author: truckman
Date: Wed Apr 29 21:44:01 UTC 2015
New revision: 385015
URL: https://svnweb.freebsd.org/changeset/ports/385015

Log:
  MFH:	r384997

  Convert databases/evolution-data-server to USES=compiler:c++11-lib
  so that on FreeBSD 8 and 9 it will be linked to the newer libstdc++
  bundled with lang/gcc.  This unbreaks the startup of mail/evolution
  on FreeBSD 8 and 9 because evolution is also linked to webkit-gtk3,
  which requires the newer libstdc++ and causes rtld to fail if the
  base version of libstdc++ has already been loaded.

  PR:		199746
  Approved by:	portmgr (delphij)

Changes:
_U  branches/2015Q2/
  branches/2015Q2/databases/evolution-data-server/Makefile
  branches/2015Q2/mail/evolution/Makefile