| Message ID | 20210301095806.68518-1-roger.pau@citrix.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [for-4.15] automation/alpine: add g++ to the list of build depends | expand |
Roger Pau Monne writes ("[PATCH for-4.15] automation/alpine: add g++ to the list of build depends"):
> clang++ relies on the C++ headers installed by g++, or else a clang
> build will hit the following error:
>
> <built-in>:3:10: fatal error: 'cstring' file not found
> #include "cstring"
> ^~~~~~~~~
> 1 error generated.
> make[10]: *** [Makefile:120: headers++.chk] Error 1
>
> Reported-by: Stefano Stabellini <sstabellini@kernel.org>
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> ---
> Cc: Ian Jackson <iwj@xenproject.org>
> No real risk here from a release PoV, it's just pulling a package
> required for the Alpine clang build. Worse that cold happen is that
> the Alpine clang build broke, but it's already broken.
Release-Acked-by: Ian Jackson <iwj@xenproject.org>
On 01/03/2021 09:58, Roger Pau Monne wrote: > clang++ relies on the C++ headers installed by g++, or else a clang > build will hit the following error: > > <built-in>:3:10: fatal error: 'cstring' file not found > #include "cstring" > ^~~~~~~~~ > 1 error generated. > make[10]: *** [Makefile:120: headers++.chk] Error 1 > > Reported-by: Stefano Stabellini <sstabellini@kernel.org> > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> > --- > Cc: Ian Jackson <iwj@xenproject.org> > No real risk here from a release PoV, it's just pulling a package > required for the Alpine clang build. Worse that cold happen is that > the Alpine clang build broke, but it's already broken. Shouldn't this be fixed upstream in Alpine? Its clearly a packaging bug. ~Andrew
On 01/03/2021 17:59, Andrew Cooper wrote: > On 01/03/2021 09:58, Roger Pau Monne wrote: >> clang++ relies on the C++ headers installed by g++, or else a clang >> build will hit the following error: >> >> <built-in>:3:10: fatal error: 'cstring' file not found >> #include "cstring" >> ^~~~~~~~~ >> 1 error generated. >> make[10]: *** [Makefile:120: headers++.chk] Error 1 >> >> Reported-by: Stefano Stabellini <sstabellini@kernel.org> >> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> >> --- >> Cc: Ian Jackson <iwj@xenproject.org> >> No real risk here from a release PoV, it's just pulling a package >> required for the Alpine clang build. Worse that cold happen is that >> the Alpine clang build broke, but it's already broken. > Shouldn't this be fixed upstream in Alpine? Its clearly a packaging bug. Or (thinking about it), we've got a build system bug using g++ when it should be using clang++. How does this check work (without g++) on a non-clang build? ~Andrew
On Mon, Mar 01, 2021 at 06:01:36PM +0000, Andrew Cooper wrote: > On 01/03/2021 17:59, Andrew Cooper wrote: > > On 01/03/2021 09:58, Roger Pau Monne wrote: > >> clang++ relies on the C++ headers installed by g++, or else a clang > >> build will hit the following error: > >> > >> <built-in>:3:10: fatal error: 'cstring' file not found > >> #include "cstring" > >> ^~~~~~~~~ > >> 1 error generated. > >> make[10]: *** [Makefile:120: headers++.chk] Error 1 > >> > >> Reported-by: Stefano Stabellini <sstabellini@kernel.org> > >> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> > >> --- > >> Cc: Ian Jackson <iwj@xenproject.org> > >> No real risk here from a release PoV, it's just pulling a package > >> required for the Alpine clang build. Worse that cold happen is that > >> the Alpine clang build broke, but it's already broken. > > Shouldn't this be fixed upstream in Alpine? Its clearly a packaging bug. > > Or (thinking about it), we've got a build system bug using g++ when it > should be using clang++. No, the check is using clang++, the issue is that clang++ doesn't install the standard c++ headers, and thus trying to use them (cstring in this case) fails. Installing the g++ package solves the issue because it installs the headers. > How does this check work (without g++) on a non-clang build? It works because on a non-clang Alpine build g++ wasn't installed, so the check wasd just skipped. The headers++.chk target in xen/include/Makefile has a explicit check for a functional CXX. I do think this is some kind of error in the Alpine clang package, as I assume installing clang++ without the standard c++ headers is an error. Regardless of that, I also think installing g++ on the Alpine container is fine, as we would then also perform the C++ header checks with g++ on the normal build. Thanks, Roger.
On 02.03.2021 09:14, Roger Pau Monné wrote: > On Mon, Mar 01, 2021 at 06:01:36PM +0000, Andrew Cooper wrote: >> On 01/03/2021 17:59, Andrew Cooper wrote: >>> On 01/03/2021 09:58, Roger Pau Monne wrote: >>>> clang++ relies on the C++ headers installed by g++, or else a clang >>>> build will hit the following error: >>>> >>>> <built-in>:3:10: fatal error: 'cstring' file not found >>>> #include "cstring" >>>> ^~~~~~~~~ >>>> 1 error generated. >>>> make[10]: *** [Makefile:120: headers++.chk] Error 1 >>>> >>>> Reported-by: Stefano Stabellini <sstabellini@kernel.org> >>>> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> >>>> --- >>>> Cc: Ian Jackson <iwj@xenproject.org> >>>> No real risk here from a release PoV, it's just pulling a package >>>> required for the Alpine clang build. Worse that cold happen is that >>>> the Alpine clang build broke, but it's already broken. >>> Shouldn't this be fixed upstream in Alpine? Its clearly a packaging bug. >> >> Or (thinking about it), we've got a build system bug using g++ when it >> should be using clang++. > > No, the check is using clang++, the issue is that clang++ doesn't > install the standard c++ headers, and thus trying to use them (cstring > in this case) fails. Installing the g++ package solves the issue > because it installs the headers. I have to admit that I consider this odd. The g++ package should neither provide nor depend on the headers. It may recommend their installation. On my distro (SLES) the headers come from the libstdc++-devel package, as I would have expected. There additionally is a dependency of libclang5 (no -devel suffix!) on libstdc++-devel (I suppose this is an indication that things aren't quite right here either; I haven't checked an up-to-date version of the distro yet, though). Jan
On Tue, Mar 02, 2021 at 09:53:41AM +0100, Jan Beulich wrote: > On 02.03.2021 09:14, Roger Pau Monné wrote: > > On Mon, Mar 01, 2021 at 06:01:36PM +0000, Andrew Cooper wrote: > >> On 01/03/2021 17:59, Andrew Cooper wrote: > >>> On 01/03/2021 09:58, Roger Pau Monne wrote: > >>>> clang++ relies on the C++ headers installed by g++, or else a clang > >>>> build will hit the following error: > >>>> > >>>> <built-in>:3:10: fatal error: 'cstring' file not found > >>>> #include "cstring" > >>>> ^~~~~~~~~ > >>>> 1 error generated. > >>>> make[10]: *** [Makefile:120: headers++.chk] Error 1 > >>>> > >>>> Reported-by: Stefano Stabellini <sstabellini@kernel.org> > >>>> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> > >>>> --- > >>>> Cc: Ian Jackson <iwj@xenproject.org> > >>>> No real risk here from a release PoV, it's just pulling a package > >>>> required for the Alpine clang build. Worse that cold happen is that > >>>> the Alpine clang build broke, but it's already broken. > >>> Shouldn't this be fixed upstream in Alpine? Its clearly a packaging bug. > >> > >> Or (thinking about it), we've got a build system bug using g++ when it > >> should be using clang++. > > > > No, the check is using clang++, the issue is that clang++ doesn't > > install the standard c++ headers, and thus trying to use them (cstring > > in this case) fails. Installing the g++ package solves the issue > > because it installs the headers. > > I have to admit that I consider this odd. The g++ package should > neither provide nor depend on the headers. It may recommend their > installation. On my distro (SLES) the headers come from the > libstdc++-devel package, as I would have expected. There > additionally is a dependency of libclang5 (no -devel suffix!) on > libstdc++-devel (I suppose this is an indication that things > aren't quite right here either; I haven't checked an up-to-date > version of the distro yet, though). Yes, that was indeed my first attempt as I've tried to install libstdc++, but there's no -devel counterpart for the package, and it only installs the libraries but not the headers. Then if I list the contents of the g++ package, I do see: ... usr/include/c++/10.2.1/cstring ... And clang++'s include path is: #include <...> search starts here: /usr/bin/../lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../include/c++/10.2.1 /usr/bin/../lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../include/c++/10.2.1/x86_64-alpine-linux-musl /usr/bin/../lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../include/c++/10.2.1/backward /usr/include /usr/lib/clang/10.0.1/include So it does seem clang depends on the gcc c++ headers, I assume this is done in order to avoid having a duplicate set of c++ headers for clang and gcc? I really have no idea, but I do think clang package should depend on g++. Thanks, Roger.
On 02.03.2021 10:36, Roger Pau Monné wrote: > On Tue, Mar 02, 2021 at 09:53:41AM +0100, Jan Beulich wrote: >> On 02.03.2021 09:14, Roger Pau Monné wrote: >>> On Mon, Mar 01, 2021 at 06:01:36PM +0000, Andrew Cooper wrote: >>>> On 01/03/2021 17:59, Andrew Cooper wrote: >>>>> On 01/03/2021 09:58, Roger Pau Monne wrote: >>>>>> clang++ relies on the C++ headers installed by g++, or else a clang >>>>>> build will hit the following error: >>>>>> >>>>>> <built-in>:3:10: fatal error: 'cstring' file not found >>>>>> #include "cstring" >>>>>> ^~~~~~~~~ >>>>>> 1 error generated. >>>>>> make[10]: *** [Makefile:120: headers++.chk] Error 1 >>>>>> >>>>>> Reported-by: Stefano Stabellini <sstabellini@kernel.org> >>>>>> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> >>>>>> --- >>>>>> Cc: Ian Jackson <iwj@xenproject.org> >>>>>> No real risk here from a release PoV, it's just pulling a package >>>>>> required for the Alpine clang build. Worse that cold happen is that >>>>>> the Alpine clang build broke, but it's already broken. >>>>> Shouldn't this be fixed upstream in Alpine? Its clearly a packaging bug. >>>> >>>> Or (thinking about it), we've got a build system bug using g++ when it >>>> should be using clang++. >>> >>> No, the check is using clang++, the issue is that clang++ doesn't >>> install the standard c++ headers, and thus trying to use them (cstring >>> in this case) fails. Installing the g++ package solves the issue >>> because it installs the headers. >> >> I have to admit that I consider this odd. The g++ package should >> neither provide nor depend on the headers. It may recommend their >> installation. On my distro (SLES) the headers come from the >> libstdc++-devel package, as I would have expected. There >> additionally is a dependency of libclang5 (no -devel suffix!) on >> libstdc++-devel (I suppose this is an indication that things >> aren't quite right here either; I haven't checked an up-to-date >> version of the distro yet, though). > > Yes, that was indeed my first attempt as I've tried to install > libstdc++, but there's no -devel counterpart for the package, and it > only installs the libraries but not the headers. > > Then if I list the contents of the g++ package, I do see: > > ... > usr/include/c++/10.2.1/cstring > ... > > And clang++'s include path is: > > #include <...> search starts here: > /usr/bin/../lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../include/c++/10.2.1 > /usr/bin/../lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../include/c++/10.2.1/x86_64-alpine-linux-musl > /usr/bin/../lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../include/c++/10.2.1/backward > /usr/include > /usr/lib/clang/10.0.1/include > > So it does seem clang depends on the gcc c++ headers, I assume this is > done in order to avoid having a duplicate set of c++ headers for clang > and gcc? I really have no idea, but I do think clang package should > depend on g++. As long as the g++ package is what provides the headers (i.e. if that's their concept), I agree. Jan
On Tue, 2 Mar 2021, Jan Beulich wrote: > On 02.03.2021 10:36, Roger Pau Monné wrote: > > On Tue, Mar 02, 2021 at 09:53:41AM +0100, Jan Beulich wrote: > >> On 02.03.2021 09:14, Roger Pau Monné wrote: > >>> On Mon, Mar 01, 2021 at 06:01:36PM +0000, Andrew Cooper wrote: > >>>> On 01/03/2021 17:59, Andrew Cooper wrote: > >>>>> On 01/03/2021 09:58, Roger Pau Monne wrote: > >>>>>> clang++ relies on the C++ headers installed by g++, or else a clang > >>>>>> build will hit the following error: > >>>>>> > >>>>>> <built-in>:3:10: fatal error: 'cstring' file not found > >>>>>> #include "cstring" > >>>>>> ^~~~~~~~~ > >>>>>> 1 error generated. > >>>>>> make[10]: *** [Makefile:120: headers++.chk] Error 1 > >>>>>> > >>>>>> Reported-by: Stefano Stabellini <sstabellini@kernel.org> > >>>>>> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> > >>>>>> --- > >>>>>> Cc: Ian Jackson <iwj@xenproject.org> > >>>>>> No real risk here from a release PoV, it's just pulling a package > >>>>>> required for the Alpine clang build. Worse that cold happen is that > >>>>>> the Alpine clang build broke, but it's already broken. > >>>>> Shouldn't this be fixed upstream in Alpine? Its clearly a packaging bug. > >>>> > >>>> Or (thinking about it), we've got a build system bug using g++ when it > >>>> should be using clang++. > >>> > >>> No, the check is using clang++, the issue is that clang++ doesn't > >>> install the standard c++ headers, and thus trying to use them (cstring > >>> in this case) fails. Installing the g++ package solves the issue > >>> because it installs the headers. > >> > >> I have to admit that I consider this odd. The g++ package should > >> neither provide nor depend on the headers. It may recommend their > >> installation. On my distro (SLES) the headers come from the > >> libstdc++-devel package, as I would have expected. There > >> additionally is a dependency of libclang5 (no -devel suffix!) on > >> libstdc++-devel (I suppose this is an indication that things > >> aren't quite right here either; I haven't checked an up-to-date > >> version of the distro yet, though). > > > > Yes, that was indeed my first attempt as I've tried to install > > libstdc++, but there's no -devel counterpart for the package, and it > > only installs the libraries but not the headers. > > > > Then if I list the contents of the g++ package, I do see: > > > > ... > > usr/include/c++/10.2.1/cstring > > ... > > > > And clang++'s include path is: > > > > #include <...> search starts here: > > /usr/bin/../lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../include/c++/10.2.1 > > /usr/bin/../lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../include/c++/10.2.1/x86_64-alpine-linux-musl > > /usr/bin/../lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../include/c++/10.2.1/backward > > /usr/include > > /usr/lib/clang/10.0.1/include > > > > So it does seem clang depends on the gcc c++ headers, I assume this is > > done in order to avoid having a duplicate set of c++ headers for clang > > and gcc? I really have no idea, but I do think clang package should > > depend on g++. > > As long as the g++ package is what provides the headers (i.e. if that's > their concept), I agree. That makes sense to me too. Acked-by: Stefano Stabellini <sstabellini@kernel.org>
On Tue, 2 Mar 2021, Stefano Stabellini wrote: > On Tue, 2 Mar 2021, Jan Beulich wrote: > > On 02.03.2021 10:36, Roger Pau Monné wrote: > > > On Tue, Mar 02, 2021 at 09:53:41AM +0100, Jan Beulich wrote: > > >> On 02.03.2021 09:14, Roger Pau Monné wrote: > > >>> On Mon, Mar 01, 2021 at 06:01:36PM +0000, Andrew Cooper wrote: > > >>>> On 01/03/2021 17:59, Andrew Cooper wrote: > > >>>>> On 01/03/2021 09:58, Roger Pau Monne wrote: > > >>>>>> clang++ relies on the C++ headers installed by g++, or else a clang > > >>>>>> build will hit the following error: > > >>>>>> > > >>>>>> <built-in>:3:10: fatal error: 'cstring' file not found > > >>>>>> #include "cstring" > > >>>>>> ^~~~~~~~~ > > >>>>>> 1 error generated. > > >>>>>> make[10]: *** [Makefile:120: headers++.chk] Error 1 > > >>>>>> > > >>>>>> Reported-by: Stefano Stabellini <sstabellini@kernel.org> > > >>>>>> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> > > >>>>>> --- > > >>>>>> Cc: Ian Jackson <iwj@xenproject.org> > > >>>>>> No real risk here from a release PoV, it's just pulling a package > > >>>>>> required for the Alpine clang build. Worse that cold happen is that > > >>>>>> the Alpine clang build broke, but it's already broken. > > >>>>> Shouldn't this be fixed upstream in Alpine? Its clearly a packaging bug. > > >>>> > > >>>> Or (thinking about it), we've got a build system bug using g++ when it > > >>>> should be using clang++. > > >>> > > >>> No, the check is using clang++, the issue is that clang++ doesn't > > >>> install the standard c++ headers, and thus trying to use them (cstring > > >>> in this case) fails. Installing the g++ package solves the issue > > >>> because it installs the headers. > > >> > > >> I have to admit that I consider this odd. The g++ package should > > >> neither provide nor depend on the headers. It may recommend their > > >> installation. On my distro (SLES) the headers come from the > > >> libstdc++-devel package, as I would have expected. There > > >> additionally is a dependency of libclang5 (no -devel suffix!) on > > >> libstdc++-devel (I suppose this is an indication that things > > >> aren't quite right here either; I haven't checked an up-to-date > > >> version of the distro yet, though). > > > > > > Yes, that was indeed my first attempt as I've tried to install > > > libstdc++, but there's no -devel counterpart for the package, and it > > > only installs the libraries but not the headers. > > > > > > Then if I list the contents of the g++ package, I do see: > > > > > > ... > > > usr/include/c++/10.2.1/cstring > > > ... > > > > > > And clang++'s include path is: > > > > > > #include <...> search starts here: > > > /usr/bin/../lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../include/c++/10.2.1 > > > /usr/bin/../lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../include/c++/10.2.1/x86_64-alpine-linux-musl > > > /usr/bin/../lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../include/c++/10.2.1/backward > > > /usr/include > > > /usr/lib/clang/10.0.1/include > > > > > > So it does seem clang depends on the gcc c++ headers, I assume this is > > > done in order to avoid having a duplicate set of c++ headers for clang > > > and gcc? I really have no idea, but I do think clang package should > > > depend on g++. > > > > As long as the g++ package is what provides the headers (i.e. if that's > > their concept), I agree. > > That makes sense to me too. > > Acked-by: Stefano Stabellini <sstabellini@kernel.org> If nobody speaks up, I'll commit this patch and this patch: https://marc.info/?l=xen-devel&m=161433737432684 (both of them already acked by Ian and only affecting automation/) within the next day or two.
On Fri, Mar 05, 2021 at 05:40:51PM -0800, Stefano Stabellini wrote: > On Tue, 2 Mar 2021, Stefano Stabellini wrote: > > On Tue, 2 Mar 2021, Jan Beulich wrote: > > > On 02.03.2021 10:36, Roger Pau Monné wrote: > > > > On Tue, Mar 02, 2021 at 09:53:41AM +0100, Jan Beulich wrote: > > > >> On 02.03.2021 09:14, Roger Pau Monné wrote: > > > >>> On Mon, Mar 01, 2021 at 06:01:36PM +0000, Andrew Cooper wrote: > > > >>>> On 01/03/2021 17:59, Andrew Cooper wrote: > > > >>>>> On 01/03/2021 09:58, Roger Pau Monne wrote: > > > >>>>>> clang++ relies on the C++ headers installed by g++, or else a clang > > > >>>>>> build will hit the following error: > > > >>>>>> > > > >>>>>> <built-in>:3:10: fatal error: 'cstring' file not found > > > >>>>>> #include "cstring" > > > >>>>>> ^~~~~~~~~ > > > >>>>>> 1 error generated. > > > >>>>>> make[10]: *** [Makefile:120: headers++.chk] Error 1 > > > >>>>>> > > > >>>>>> Reported-by: Stefano Stabellini <sstabellini@kernel.org> > > > >>>>>> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> > > > >>>>>> --- > > > >>>>>> Cc: Ian Jackson <iwj@xenproject.org> > > > >>>>>> No real risk here from a release PoV, it's just pulling a package > > > >>>>>> required for the Alpine clang build. Worse that cold happen is that > > > >>>>>> the Alpine clang build broke, but it's already broken. > > > >>>>> Shouldn't this be fixed upstream in Alpine? Its clearly a packaging bug. > > > >>>> > > > >>>> Or (thinking about it), we've got a build system bug using g++ when it > > > >>>> should be using clang++. > > > >>> > > > >>> No, the check is using clang++, the issue is that clang++ doesn't > > > >>> install the standard c++ headers, and thus trying to use them (cstring > > > >>> in this case) fails. Installing the g++ package solves the issue > > > >>> because it installs the headers. > > > >> > > > >> I have to admit that I consider this odd. The g++ package should > > > >> neither provide nor depend on the headers. It may recommend their > > > >> installation. On my distro (SLES) the headers come from the > > > >> libstdc++-devel package, as I would have expected. There > > > >> additionally is a dependency of libclang5 (no -devel suffix!) on > > > >> libstdc++-devel (I suppose this is an indication that things > > > >> aren't quite right here either; I haven't checked an up-to-date > > > >> version of the distro yet, though). > > > > > > > > Yes, that was indeed my first attempt as I've tried to install > > > > libstdc++, but there's no -devel counterpart for the package, and it > > > > only installs the libraries but not the headers. > > > > > > > > Then if I list the contents of the g++ package, I do see: > > > > > > > > ... > > > > usr/include/c++/10.2.1/cstring > > > > ... > > > > > > > > And clang++'s include path is: > > > > > > > > #include <...> search starts here: > > > > /usr/bin/../lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../include/c++/10.2.1 > > > > /usr/bin/../lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../include/c++/10.2.1/x86_64-alpine-linux-musl > > > > /usr/bin/../lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../include/c++/10.2.1/backward > > > > /usr/include > > > > /usr/lib/clang/10.0.1/include > > > > > > > > So it does seem clang depends on the gcc c++ headers, I assume this is > > > > done in order to avoid having a duplicate set of c++ headers for clang > > > > and gcc? I really have no idea, but I do think clang package should > > > > depend on g++. > > > > > > As long as the g++ package is what provides the headers (i.e. if that's > > > their concept), I agree. > > > > That makes sense to me too. > > > > Acked-by: Stefano Stabellini <sstabellini@kernel.org> > > If nobody speaks up, I'll commit this patch and this patch: > > https://marc.info/?l=xen-devel&m=161433737432684 > > (both of them already acked by Ian and only affecting automation/) > within the next day or two. I've reported the missing c++ headers with clang++ upstream, would you mind adding this link: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12492 To the commit message here? Thanks, Roger.
diff --git a/automation/build/alpine/3.12.dockerfile b/automation/build/alpine/3.12.dockerfile index 2c02417ee6..94557e239b 100644 --- a/automation/build/alpine/3.12.dockerfile +++ b/automation/build/alpine/3.12.dockerfile @@ -21,6 +21,7 @@ RUN \ apk add curl-dev && \ apk add dev86 && \ apk add gcc && \ + apk add g++ && \ apk add clang && \ apk add gettext && \ apk add git && \
clang++ relies on the C++ headers installed by g++, or else a clang build will hit the following error: <built-in>:3:10: fatal error: 'cstring' file not found #include "cstring" ^~~~~~~~~ 1 error generated. make[10]: *** [Makefile:120: headers++.chk] Error 1 Reported-by: Stefano Stabellini <sstabellini@kernel.org> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> --- Cc: Ian Jackson <iwj@xenproject.org> No real risk here from a release PoV, it's just pulling a package required for the Alpine clang build. Worse that cold happen is that the Alpine clang build broke, but it's already broken. --- automation/build/alpine/3.12.dockerfile | 1 + 1 file changed, 1 insertion(+)