Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 28 Apr 2015 00:11:43 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-ports-bugs@FreeBSD.org
Subject:   [Bug 199746] [patch] mail/evolution builds but does not run on FreeBSD 8.4 (and probably 9.3)
Message-ID:  <bug-199746-13@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199746

            Bug ID: 199746
           Summary: [patch] mail/evolution builds but does not run on
                    FreeBSD 8.4 (and probably 9.3)
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Keywords: patch
          Severity: Affects Some People
          Priority: ---
         Component: Individual Port(s)
          Assignee: gnome@FreeBSD.org
          Reporter: truckman@FreeBSD.org
             Flags: maintainer-feedback?(gnome@FreeBSD.org)
          Keywords: patch
          Assignee: gnome@FreeBSD.org

Created attachment 156058
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=156058&action=edit
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-199746-13>