[PATCH for-4.15] automation/alpine: add g++ to the list of build depends

[PATCH for-4.15] automation/alpine: add g++ to the list of build depends

[Roger Pau Monne]

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(+)

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 && \
-- 
2.30.1

Re: [PATCH for-4.15] automation/alpine: add g++ to the list of build depends

[Ian Jackson]

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>

Re: [PATCH for-4.15] automation/alpine: add g++ to the list of build depends

[Andrew Cooper]

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

Re: [PATCH for-4.15] automation/alpine: add g++ to the list of build depends

[Andrew Cooper]

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

Re: [PATCH for-4.15] automation/alpine: add g++ to the list of build depends

[Roger Pau Monné]

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.

Re: [PATCH for-4.15] automation/alpine: add g++ to the list of build depends

[Jan Beulich]

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

Re: [PATCH for-4.15] automation/alpine: add g++ to the list of build depends

[Roger Pau Monné]

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.

Re: [PATCH for-4.15] automation/alpine: add g++ to the list of build depends

[Jan Beulich]

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

Re: [PATCH for-4.15] automation/alpine: add g++ to the list of build depends

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 3298 bytes --]

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>

Re: [PATCH for-4.15] automation/alpine: add g++ to the list of build depends

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 3695 bytes --]

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.

Re: [PATCH for-4.15] automation/alpine: add g++ to the list of build depends

[Roger Pau Monné]

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.

[PATCH for-4.15] automation/alpine: add g++ to the list of build depends

[Roger Pau Monne]

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>
---
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(+)

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 && \
-- 
2.30.1