Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 11 Nov 2015 08:27:20 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-ports-bugs@FreeBSD.org
Subject:   [Bug 204461] [patch] devel/libxs - build with base toolchain whenever possible
Message-ID:  <bug-204461-13@https.bugs.freebsd.org/bugzilla/>

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

            Bug ID: 204461
           Summary: [patch] devel/libxs - build with base toolchain
                    whenever possible
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Keywords: patch
          Severity: Affects Only Me
          Priority: ---
         Component: Individual Port(s)
          Assignee: vg@FreeBSD.org
          Reporter: truckman@FreeBSD.org
            Blocks: 196712
             Flags: maintainer-feedback?(vg@FreeBSD.org)
          Assignee: vg@FreeBSD.org
          Keywords: patch

Created attachment 163001
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=163001&action=edit
patch to remove USE_GCC=yes from devel/libxs

The libxs port contains C++ code and currently uses USE_GCC=yes.  This causes
two problems for the port dns/dnstable, which is pure C code and uses the base
system toolchain, and which also links to the archivers/snappy port (which also
contains C++ code and always uses the base system compiler to build):

  On FreeBSD 9, libsnappy is linked to the libstdc++ in base and libxs is
  linked to the ports version of libstdc++ that is bundled with gcc from
  ports.  When linking dnstable, the linker may bring in the base version
  of libstdc++ before it links in libxs and sees that rpath information
  that would tell it to bring in libstdc++ from ports instead.  This may
  result in a link error.  See PRs 196712 and 204400.

  On FreeBSD >= 10, libsnappy is linked to libc++ from base, so the resulting
  executables get linked to both libstdc++ and libc++, which causes crashes at
  runtime.

The attached patch eliminates the need for libxs to use USE_GCC=yes, except
if it is built in a FreeBSD 9 environment where clang is the primary compiler,
which is not the default.  With this patch, libxs will link to base libstdc++
on FreeBSD 9, and will link to base libc++ on FreeBSD >= 10.

That said, this patch is extremely hackish.  The biggest problem is that libxs
does not build with clang < 3.6.  The problem is not in the code, but rather a
bug in the libc++ header files.  Since libc++ is not bundled with the clang
ports, using clang from ports does not fix the problem.  The best solution that
I could find was to make local copies of the two broken header files, patch
them with the specific upstream commit that fixed the bug, and include their
location in the compiler include path.

It turns out that libxs does build with the old version of gcc that is in base
on FreeBSD 9, so using USE_GCC=yes is not necessary there.   The only case
where it is necessary is on a FreeBSD 9 machine that has been configured with
clang is the primary compiler and with gcc omitted.

-- 
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-204461-13>