Bug 246479

Summary: devel/llvm10: libcxx is not packaged, new features can't be used
Product: Ports & Packages Reporter: mb
Component: Individual Port(s)Assignee: Brooks Davis <brooks>
Status: Closed Works As Intended    
Severity: Affects Many People Flags: bugzilla: maintainer-feedback? (brooks)
Priority: ---    
Version: Latest   
Hardware: Any   
OS: Any   

Description mb 2020-05-15 07:31:45 UTC 
after installing `llvm10` from the ports i realized that it doesn't include the nowadays fully integrated `libcxx` package. which in turn means i can not use the new `concepts` from c++20 ( as example ). the gcc ports on the other hand do include a fully packaged and upto date libstdc++.

if `llvm10` would ship its corresponding `libcxx` then linking would require passing `-Wl,rpath=...` like as is the case with the gcc port.

what are the reasons against packaging `libcxx` as well?

maybe related:

- https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215193

note:

for now i have to manually install `libcxx` and maybe `libcxxabi` and do all the `-Wl,...` anyways.

i think for a usable current llvm port it should include it's `libcxx` which gets distributed in the official tarball.
Comment 1 Brooks Davis freebsd_committer freebsd_triage 2020-05-15 17:43:03 UTC 
I have no plans to package libcxx with the llvm ports.  I've lived through the nightmare of incompatible libstdc++ installs for to long to consider reintroducing it with far more extensive testing than I have time for.
Comment 2 Brooks Davis freebsd_committer freebsd_triage 2020-05-15 17:43:30 UTC 
(In reply to Brooks Davis from comment #1)
s/with/without/
Comment 3 mb 2020-05-16 11:36:39 UTC 
(In reply to Brooks Davis from comment #1)

only partially understood. you say that maintaining libstdc++ is a nightmare. but i can't see how that relates to libcxx. which is part of the official llvm release tarballs.

maybe you should at least document your decision in the pkg-descr then.

you as package maintainer decided against installing libcxx from the release tarball and instead make the port rely on freebsd base libcxx ( which is totally
fine but undocumented )

i guess you do also not consider making the "provided libcxx" a port flavor then?
Comment 4 Brooks Davis freebsd_committer freebsd_triage 2020-05-18 16:12:04 UTC 
It's pretty much impractical to link programs with multiple C++ standard libraries and that happens once other libraries have been linked against a compiler provided C++ library (and with gcc and libstdc++).  They almost never have compatible ABIs and without significant care that's true for even different versions of libc++ (we maintain compatibility in the base system though careful selection of compilation flags.)

I'm unwilling to put myself in a situation where I'm handling cross-threaded C++ ABI issues because I don't see an end to that tunnel.
Comment 5 mb 2020-05-25 12:04:48 UTC 
i totally understand your concerns. since the llvm from the ports system is probably not used to build anything related to base and or ports i think we
wouldn't buy into much more problems then there are already. the user of the ports needs to take care of passing the correct flags. and if the user decides to build the llvm flavour that would include `libcxx` then the user would be in total responsibility on what to do with that port.

i will have to maintain a custom llvm "package" independent of the ports system then. which kind of sounds sad. but the workarounds for not being able to use some of the c++17/c++20 features would be even worse :/

anyhow, thanks for taking the time responding to the issue.