[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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@xxxxxxxxxx>
> >>>>>> Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> >>>>>> ---
> >>>>>> Cc: Ian Jackson <iwj@xxxxxxxxxxxxxx>
> >>>>>> 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@xxxxxxxxxx>

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.