Bug 246479 - devel/llvm10: libcxx is not packaged, new features can't be used
Summary: devel/llvm10: libcxx is not packaged, new features can't be used
Status: Closed Works As Intended
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: Brooks Davis
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-05-15 07:31 UTC by mb
Modified: 2020-05-25 12:04 UTC (History)
0 users

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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 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 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 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.