Bug 260139 - devel/llvm13: include libc++ in the package
Summary: devel/llvm13: include libc++ in the package
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Brooks Davis
Keywords: needs-patch
Depends on:
Reported: 2021-11-30 14:46 UTC by Jan Beich
Modified: 2021-12-01 20:39 UTC (History)
1 user (show)

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


Note You need to log in before you can comment on or make changes to this bug.
Description Jan Beich freebsd_committer 2021-11-30 14:46:18 UTC
Some of my ports (e.g., rpcs3, yuzu) require very recent libc++ but ports/ have to support up to 2 years old version shipped with a FreeBSD -RELEASE. Upstream projects also want to test recent libc++ on CI without waiting for FreeBSD to make a -RELEASE with such a version. So, can you enable libc++?

Current ports/ workaround:

GH_TUPLE+=	llvm:llvm-project:llvmorg-13.0.1-rc1:libcxx
CXXFLAGS+=	-nostdinc++ -isystem${WRKDIR}/libcxx_prefix/include/c++/v1
LDFLAGS+=	-nostdlib++ -L${WRKDIR}/libcxx_prefix/lib -l:libc++.a -lcxxrt

pre-configure:	bundled-libcxx
		-B ${WRKDIR}/libcxx_build -S ${WRKSRC_libcxx}/libcxx
	@${DO_MAKE_BUILD:NDESTDIR*} install -C ${WRKDIR}/libcxx_build
Comment 1 Brooks Davis freebsd_committer 2021-11-30 17:40:17 UTC
I'm not a fan of adding libc++ to devel/llvm*. GCC's baked in libstdc++ has historically been an unending nightmare of cross-threaded dependencies. I am fairly certain this will break in at least some cases where the base C++ and libc++ with default build options have different ABIs.

I'm open to finding a better solution than building a per-port libc++, but I'm not sold on maintaining libc++ as part of the compiler. I need to understand how this won't become a mess of debugging other people's C++ linkage issues.
Comment 2 Mark Millard 2021-12-01 01:22:22 UTC
(In reply to Brooks Davis from comment #1)

Stronger?: Is not a goal to be able to use
llvm13 materials to buildworld  and buildkernel
without changing the FreeBSD ABI? (libc++ need
not keep compatibility from version to version.)
It is one way of avoiding a chunk of the
time buildworld takes takes, given a llvm13
package is available and installed.

So, at least enough control to allow use of the
system libc++ and llvm13 materials would seem to
be needed. (The point is not really llvm13
specific long term: just an example.)

Do not get me wrong, I'd like to be able to
experiment with the modern libc++ as well.
(In fact, I do not normally do the llvm13
style buildworld's and buildkernel's. But
I have on occasion resorted to such.)

May be a lang/llvm13 and devel/llvm13 with
differing command names and such? (This may
be absurd overall. I'm not familiar with
what all would be involved in having both.)
Comment 3 Jan Beich freebsd_committer 2021-12-01 20:39:43 UTC
(In reply to Brooks Davis from comment #1)
> different ABIs

Can be solved in 2 ways:
- Build libc++ from llvm13 but don't use by default
- Disable shared libc++ library in llvm13

Alternatively, devel/libc++ can be resurrected or bug 215193 unstalled.