Description of problem: There is no libcxx RPM in epel8, but in epel7 exists Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: It would be nice to have it as well in EPEL8 Additional info: Need to build it some other tools like v8, plv8 (Java Script V8 PL language for PostgreSQL)
I'd like to add support for requesting a libcxx package in EPEL8. Citrix requires libc++ for their Microsoft Teams optimization engine in Workspace App - without libc++, Teams in Workspace App operates at a degraded level.
(In reply to bericson from comment #1) > I'd like to add support for requesting a libcxx package in EPEL8. Citrix > requires libc++ for their Microsoft Teams optimization engine in Workspace > App - without libc++, Teams in Workspace App operates at a degraded level. Do you have more details about why you need libc++ and can't use libstdc++?
Citrix has implemented their Teams optimization engine using libc++. Unfortunately this is binary-only; source code is not available and libc++ is what they chose to use.
I'd like to add another vote for libc++ libc++abi in rhel8/9 A (x-platform) software that is expected to be be compiled on Apple most likely will be compiled by clang/libc++ toolchain (this is the standard toolchain on Apple). libc++ has a number of differences with libstdc++ and we would like to be able to test/debug on CentOS/RHEL in a similar configuration.
+1 here. The major problem is that when using llvm we end up with clang 12 and libstdc++ from GCC8. So basically almost everything modern (C++20) is unsupported or broken.
(In reply to Vinícius Ferrão from comment #7) > +1 here. The major problem is that when using llvm we end up with clang 12 > and libstdc++ from GCC8. So basically almost everything modern (C++20) is > unsupported or broken. For a newer C++ standard library, it is recommended that you install gcc-toolset and use that instead.
+1 for adding libc++ and libc++abi. I am surprised to see that this is not bundled with llvm-toolset on any version of RHEL. Basically all of the Debian/Ubuntu packages from https://apt.llvm.org/ should be bundled with llvm-toolset for consistency.
(In reply to bericson from comment #5) > Citrix has implemented their Teams optimization engine using libc++. > Unfortunately this is binary-only; source code is not available and libc++ > is what they chose to use. Does Citrix provide a copy of libc++ or do they expect users will have it installed on their system? Do you know what version of libc++ they use?
Citrix does not provide a copy of libc++. It would be nice if they did, but alas... According to https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/multimedia/opt-ms-teams.html libc++-9.0 or later is required.
(In reply to Dmitri A. Sergatskov from comment #6) > I'd like to add another vote for libc++ libc++abi in rhel8/9 > > A (x-platform) software that is expected to be be compiled on > Apple most likely will be compiled by clang/libc++ toolchain > (this is the standard toolchain on Apple). > libc++ has a number of differences with libstdc++ and we > would like to be able to test/debug on CentOS/RHEL in > a similar configuration. @dasergatskov Do you want to be able to use the RHEL clang toolchain or do you have your own custom clang toolchain that you are using?
I do not use Centos/RHEL anymore, but I would had preferred to have a system's clang chain w/ libc++ similarly to how it is done in Fedora. Dmitri. --
Tom, if I may add something to this issue. The whole point here is that when we install LLVM/clang on RHEL it's expected to get libc++, at least as an option. We understand that libc++ would be something provided only in EPEL without Red Hat support, but it's really what should be done. For my case, I also develop on a Mac with libc++ so it would be nice to have it on RHEL. Thank you for considering this option.
One of the challenges of adding libc++ to EPEL is that llvm-toolset in RHEL updates to a new version every six months, but EPEL does not typically do major version updates of packages, so we would either need to create compat packages, use modules, or get some kind of exception.
(In reply to Tom Stellard from comment #15) > One of the challenges of adding libc++ to EPEL is that llvm-toolset in RHEL > updates to a new version every six months, but EPEL does not typically do > major version updates of packages, so we would either need to create compat > packages, use modules, or get some kind of exception. Any reason why EPEL does not do major version updates of packages? Considering that Fedora is upstream of RHEL, it seems a bit backwards that RHEL is getting more frequent updates of packages than EPEL. Shouldn't new versions of libc++ and other compiler toolchains be tried out in EPEL before pushing to RHEL? For my use case, having libc++ in llvm-toolset is more important than having it in EPEL, so if there are problems with adding it to EPEL then I would vote for adding it to llvm-toolset first and figuring out what to do with EPEL later.