Date: Mon, 11 Dec 2023 16:05:06 +0100
I see. And I believe the answer is yes. Just because of how bootstrapping
works in HPC environments, it's possible that there are multiple libraries
in contention at any given time, and you might need to select the correct
one.
NVHPC also uses libstdc++. And because the HPC software is fast moving, you
often get a new library fix before compiler is released and you need to
use new versions of libc++ with slightly older compilers.
It's easier in my opinion to support these cases just like other cases
instead of creating small little exceptions that complicate the problem
space.
On Mon, 11 Dec 2023, 15:49 Gabriel Dos Reis, <gdr_at_[hidden]> wrote:
> I am specifically concerned about the Standard Library implementations,
> which are part of the C++ compiler.
>
> -- Gaby
>
>
> ------------------------------
> *From:* SG15 <sg15-bounces_at_[hidden]> on behalf of Jayesh Badwaik
> via SG15 <sg15_at_[hidden]>
> *Sent:* Monday, December 11, 2023 6:45:56 AM
> *To:* sg15_at_[hidden] <sg15_at_[hidden]>
> *Cc:* Jayesh Badwaik <jayesh_at_[hidden]>
> *Subject:* Re: [SG15] Scheduling a virtual meeting to discuss where the
> std module source file should live
>
> I don't think so. Spack works on all major OS systems. And may be I'm
> wrong, but from what I remember, visual studio can also install multiple
> compilers on the same system. So, the practice seems pretty common.
>
> On Mon, 11 Dec 2023, 15:38 Gabriel Dos Reis, <gdr_at_[hidden]> wrote:
>
> Is the experience dependent on the platforms?
>
> -- Gaby
>
>
> ------------------------------
> *From:* SG15 <sg15-bounces_at_[hidden]> on behalf of Jayesh Badwaik
> via SG15 <sg15_at_[hidden]>
> *Sent:* Monday, December 11, 2023 6:04:04 AM
> *To:* sg15_at_[hidden] <sg15_at_[hidden]>
> *Cc:* Jayesh Badwaik <jayesh_at_[hidden]>
> *Subject:* Re: [SG15] Scheduling a virtual meeting to discuss where the
> std module source file should live
>
> In my experience, it is not rare to get compiler from library package
> manager and would be an important use case. This is how a large community
> of HPC developers for example get their compilers (spack and easy build for
> example).
>
> On Mon, 11 Dec 2023, 12:26 Mathias Stearn, <redbeard0531+isocpp_at_[hidden]>
> wrote:
>
> Can we please be explicit about which kind of "package manager" is being
> referred to whenever we use that term? Are we talking about a system
> package manager (yum, apt, pacman, brew, winget etc) or a C++/library
> package manager (conan, vcpkg, cpm, etc)? This whole thread seems very
> ambiguous. I _think_ most people are talking about library package
> managers, but references to the FHS imply otherwise.
>
> Right now it is very common to get a compiler and stdlib from the system
> package manager on linux. I think it is fairly rare right now to get the
> stdlib from a library package manager, although it would be nice if it were
> simple and easy to do so. To support std modules with the status quo
> environment, we need to work with system package managers. We will probably
> need to support other modules through them eventually, but it seems a both
> harder and a bit less urgent. The opposite seems to be the case for library
> package managers, where supporting non-std modules is probably a higher
> priority than the std module.
>
> On Mon, Dec 11, 2023 at 7:27 AM Jayesh Badwaik via SG15 <
> sg15_at_[hidden]> wrote:
>
> I am not sure I get where this is coming from. The question is about being
> able to distribute and find a c++ compiler through a package manager.
>
> In order to make things uniform, the posts also want system compiler to
> provide the same CPS interface.
>
> Dependency would have been when it would have been necessary to install
> system compiler with a package manager.
>
> On Mon, 11 Dec 2023, 00:57 Gabriel Dos Reis via SG15, <
> sg15_at_[hidden]> wrote:
>
> Are we establishing a package manager as a dependency for a C++ compiler
> (which typically is also the system compiler)?
>
> -- Gaby
>
>
> ------------------------------
> *From:* SG15 <sg15-bounces_at_[hidden]> on behalf of Steve Downey
> via SG15 <sg15_at_[hidden]>
> *Sent:* Sunday, December 10, 2023 12:01:12 PM
> *To:* Mark de Wever <koraq_at_[hidden]>
> *Cc:* Steve Downey <sdowney_at_[hidden]>; ISO C++ Tooling Study Group <
> sg15_at_[hidden]>
> *Subject:* Re: [SG15] Scheduling a virtual meeting to discuss where the
> std module source file should live
>
> All the flags that make the BMI unusable make binaries unusable, in the
> general case. That standard libraries manage to avoid that is exceptional.
>
> Package managers ought to be able to do this, and an install $prefix is
> the purview of a package manager. This is, of course, slightly to the side
> of where the interface is source lives.
>
> But if a hello world project has to build the standard library, modules as
> a normal feature are DOA as a practical matter.
>
> On Sun, Dec 10, 2023, 14:44 Mark de Wever <koraq_at_[hidden]> wrote:
>
> On Sun, Dec 10, 2023 at 11:40:59AM -0500, Steve Downey wrote:
> > Does the std module use the same .a/.so as as headers?
>
> Yes this is the library shipped by the vendor.
>
> > How does that work with headers and -fno-exception, or does that have
> > to be taken care of today by the user?
>
> I'm not sure, I've no experience with systems where exceptions are
> disabled. Most of libc++'s configuration options do not modify the
> compilation flags.
>
> > The other question is if the interface goes in include/ or share/libc++
> for
> > FHS like layout, and then is it possible to deploy a commonly used BMI
> into
> > lib or libexec.
>
> We don't want to deploy BMI files. In Clang BMI's have the same
> limitations as precomiled headers; almost all compilation flags makes
> BMIs incompatible. The build system needs to build the BMIs from the
> module source files. For example, std.cppm.
>
> > FHS implicitly assumes a coherent installation within a $prefix, which
> also
> > means that ABI affecting flags are fixed, so system compilers ought to be
> > able to at least pre build the system std modules.
>
> At least for now that's not possible with Clang. I'm not sure whether it
> ever be possible. For example, changing -std=c++xx flag changes the
> exported named declarations of the module.
>
> Cheers,
> Mark
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
>
works in HPC environments, it's possible that there are multiple libraries
in contention at any given time, and you might need to select the correct
one.
NVHPC also uses libstdc++. And because the HPC software is fast moving, you
often get a new library fix before compiler is released and you need to
use new versions of libc++ with slightly older compilers.
It's easier in my opinion to support these cases just like other cases
instead of creating small little exceptions that complicate the problem
space.
On Mon, 11 Dec 2023, 15:49 Gabriel Dos Reis, <gdr_at_[hidden]> wrote:
> I am specifically concerned about the Standard Library implementations,
> which are part of the C++ compiler.
>
> -- Gaby
>
>
> ------------------------------
> *From:* SG15 <sg15-bounces_at_[hidden]> on behalf of Jayesh Badwaik
> via SG15 <sg15_at_[hidden]>
> *Sent:* Monday, December 11, 2023 6:45:56 AM
> *To:* sg15_at_[hidden] <sg15_at_[hidden]>
> *Cc:* Jayesh Badwaik <jayesh_at_[hidden]>
> *Subject:* Re: [SG15] Scheduling a virtual meeting to discuss where the
> std module source file should live
>
> I don't think so. Spack works on all major OS systems. And may be I'm
> wrong, but from what I remember, visual studio can also install multiple
> compilers on the same system. So, the practice seems pretty common.
>
> On Mon, 11 Dec 2023, 15:38 Gabriel Dos Reis, <gdr_at_[hidden]> wrote:
>
> Is the experience dependent on the platforms?
>
> -- Gaby
>
>
> ------------------------------
> *From:* SG15 <sg15-bounces_at_[hidden]> on behalf of Jayesh Badwaik
> via SG15 <sg15_at_[hidden]>
> *Sent:* Monday, December 11, 2023 6:04:04 AM
> *To:* sg15_at_[hidden] <sg15_at_[hidden]>
> *Cc:* Jayesh Badwaik <jayesh_at_[hidden]>
> *Subject:* Re: [SG15] Scheduling a virtual meeting to discuss where the
> std module source file should live
>
> In my experience, it is not rare to get compiler from library package
> manager and would be an important use case. This is how a large community
> of HPC developers for example get their compilers (spack and easy build for
> example).
>
> On Mon, 11 Dec 2023, 12:26 Mathias Stearn, <redbeard0531+isocpp_at_[hidden]>
> wrote:
>
> Can we please be explicit about which kind of "package manager" is being
> referred to whenever we use that term? Are we talking about a system
> package manager (yum, apt, pacman, brew, winget etc) or a C++/library
> package manager (conan, vcpkg, cpm, etc)? This whole thread seems very
> ambiguous. I _think_ most people are talking about library package
> managers, but references to the FHS imply otherwise.
>
> Right now it is very common to get a compiler and stdlib from the system
> package manager on linux. I think it is fairly rare right now to get the
> stdlib from a library package manager, although it would be nice if it were
> simple and easy to do so. To support std modules with the status quo
> environment, we need to work with system package managers. We will probably
> need to support other modules through them eventually, but it seems a both
> harder and a bit less urgent. The opposite seems to be the case for library
> package managers, where supporting non-std modules is probably a higher
> priority than the std module.
>
> On Mon, Dec 11, 2023 at 7:27 AM Jayesh Badwaik via SG15 <
> sg15_at_[hidden]> wrote:
>
> I am not sure I get where this is coming from. The question is about being
> able to distribute and find a c++ compiler through a package manager.
>
> In order to make things uniform, the posts also want system compiler to
> provide the same CPS interface.
>
> Dependency would have been when it would have been necessary to install
> system compiler with a package manager.
>
> On Mon, 11 Dec 2023, 00:57 Gabriel Dos Reis via SG15, <
> sg15_at_[hidden]> wrote:
>
> Are we establishing a package manager as a dependency for a C++ compiler
> (which typically is also the system compiler)?
>
> -- Gaby
>
>
> ------------------------------
> *From:* SG15 <sg15-bounces_at_[hidden]> on behalf of Steve Downey
> via SG15 <sg15_at_[hidden]>
> *Sent:* Sunday, December 10, 2023 12:01:12 PM
> *To:* Mark de Wever <koraq_at_[hidden]>
> *Cc:* Steve Downey <sdowney_at_[hidden]>; ISO C++ Tooling Study Group <
> sg15_at_[hidden]>
> *Subject:* Re: [SG15] Scheduling a virtual meeting to discuss where the
> std module source file should live
>
> All the flags that make the BMI unusable make binaries unusable, in the
> general case. That standard libraries manage to avoid that is exceptional.
>
> Package managers ought to be able to do this, and an install $prefix is
> the purview of a package manager. This is, of course, slightly to the side
> of where the interface is source lives.
>
> But if a hello world project has to build the standard library, modules as
> a normal feature are DOA as a practical matter.
>
> On Sun, Dec 10, 2023, 14:44 Mark de Wever <koraq_at_[hidden]> wrote:
>
> On Sun, Dec 10, 2023 at 11:40:59AM -0500, Steve Downey wrote:
> > Does the std module use the same .a/.so as as headers?
>
> Yes this is the library shipped by the vendor.
>
> > How does that work with headers and -fno-exception, or does that have
> > to be taken care of today by the user?
>
> I'm not sure, I've no experience with systems where exceptions are
> disabled. Most of libc++'s configuration options do not modify the
> compilation flags.
>
> > The other question is if the interface goes in include/ or share/libc++
> for
> > FHS like layout, and then is it possible to deploy a commonly used BMI
> into
> > lib or libexec.
>
> We don't want to deploy BMI files. In Clang BMI's have the same
> limitations as precomiled headers; almost all compilation flags makes
> BMIs incompatible. The build system needs to build the BMIs from the
> module source files. For example, std.cppm.
>
> > FHS implicitly assumes a coherent installation within a $prefix, which
> also
> > means that ABI affecting flags are fixed, so system compilers ought to be
> > able to at least pre build the system std modules.
>
> At least for now that's not possible with Clang. I'm not sure whether it
> ever be possible. For example, changing -std=c++xx flag changes the
> exported named declarations of the module.
>
> Cheers,
> Mark
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
>
Received on 2023-12-11 15:05:20