Re: Bootstrapping pkgsrc with a compiler

[Greg Troxel <gdt%lexort.com@localhost>]

Brook Milligan <brook%nmsu.edu@localhost> writes:

>> That is Jason's approach with auto-pkgsrc-setup.
>
> I think that is right.  However, his approach involves running yet
> another script.  I feel it would be an improvement to include what is
> needed in the bootstrap script in a way that can be configured with a
> file or command options.  Why should we require another layer on top
> of our bootstrap in order to bootstrap?

Sure, I get that.  The real question is what the best approach is.

>>> I am raising the possibility that those steps could be combined into a
>>> bootstrap with compiler step, followed by normal use of pkgsrc, which
>>> would have been already configured in the first step to use the
>>> bootstrapped compiler.  I feel this would make using non-native
>>> compilers with pkgsrc, a definite need in some cases, much more
>>> feasible.
>> 
>> I don't really understand what the bootstrap/compiler stage does, as it
>> has to build some things with the native compiler.  Are those then "make
>> replaced"?
>
> I was not thinking that they would be.  I’m not even sure why they
> would need to be, as they would not be if you set GCC_REQD to
> something and built all of pkgsrc with it.  The primary point here is
> whether that can be set up during the bootstrap phase or must only be
> done later.

You say "during", but separate from what the bootstrap script does and
what happens "later", the question then becomes

  For each installed package, what compiler was used?

  Is there ever a time when a package is used as a dependency, that
  package was built with a different compiler, and this causes problems?

I see the bootstrap script setting variables in mk.conf and someone
doing it pos bootstrap as a convenience rather than the fundamental
thing.   I think it's important - just not the key point.

> I see three use cases.
>
> (i) The native compiler is fine and should be used for all of pkgsrc.
> This seems to be assumed to be the common case, and the bootstrap
> script of course supports this so nothing special is required.

This is the case that ought to be, and doesn't work because upstream
packages depend on new language features :-(

> (ii) The native compiler is fine but one wishes to choose a different
> pkgsrc-supplied compiler for building packages.  The bootstrap script
> does not need special support for this.  Prior to a normal bootstrap,
> the makefile fragment needs to include USE_PKGSRC_GCC=yes and
> GCC_REQD=8 (or whatever version).  After bootstrap, the next package
> requiring compiling will depend on the selected compiler so it will be
> built as a normal dependency.  Everything up through building this
> compiler will be done by the native compiler and not replaced later.

Does that really work?

1) Does the gcc version so selected somehow ignore the GCC_REQD?

2) How do you know that linking libs built by different compilers is ok?
AIUI, a core problem is that the various gcc libs do not have a stable
ABI.

> (iii) The native compiler is _not_ fine in general, but is sufficient
> to build whatever pkgsrc compiler is required.  The bootstrap script

Arguably this is the normal case these days.

> currently does not support this and manual intervention is required.
> That manual intervention involves the following: (a) normal bootstrap,
> (b) build and install some compiler from pkgsrc, (c) modify
> etc/mk.conf to include USE_PKGSRC_GCC=yes and GCC_REQD=, (d) build
> other packages, which will now depend on the previously built pkgsrc
> compiler.

That is an approach, but it only works if the mix-and-match strategy is sound.

> As in all other cases, the compiler in use will have been
> built by the native compiler and not replaced later.  As my naive
> minimal patch indicates, however, it is not a big leap to have the
> bootstrap script support this use case directly and build the compiler
> during the bootstrap phase.

Sure but that is orthogonal to the soundness issue.

>  If it did, then all of these cases can be
> supported by a single bootstrap process with a single run of the
> bootstrap script; each would be selected by command options.  If
> nothing else, this makes this case much less error prone and does not
> require extra steps.  It may also lead to better consistency and
> easier compiler selection logic.  However, those directions depend
> more on the selection of the default bootstrap than on the basic
> capacity to use a single bootstrap script for all of these use cases.

True.  What you propose seems useful; I view it as glue around the main
issue.

>> I increasingly wonder about the less magic and seemingly simpler strategy of:
>> 
>> 1) bootstrap pksrc with the native compiler to /usr/pkg/COMPILER
>>   build some compiler
>
> I think you are suggesting introducing a new directory under /usr/pkg
> that would contain whatever compiler is built during the bootstrap,
> right?

Yes, the compiler that is built to be used by the main prefix, built by
a bootstrap into the subprefix.

> I think you are also thinking that if you later built the same or
> different compiler it would go into its normal location, for example
> /usr/pkg/gcc8.

if you ran make under /usr/pkg, yes.

> Is that correct?
>
>> 2) bootstrap pkgsrc to /usr/pkg, setting the compiler to be used as
>>   /usr/pkg/COMPILER.
>> 
>> Perhaps step 2 is already doable with just something like
>> --compiler=/usr/pkg/COMPILER/gcc7/bin/gcc and it's a small matter to add
>> a script to do two bootstraps.
>
> Why do we need two bootstraps?  You are still relying on the native

To avoid mixing of binaries built by different compilers because -lgcc*
does not have a stable ABI.

> compiler to build whatever compiler is being used to build pkgsrc and
> you are not replacing the compilers with anything later.  (I am
> confused why you were thinking of ever using “make replace”, though.)

The compiler in /usr/pkg/COMPILER is only used to compile; it is not
used to link.   So it does not need replacing as there is no linking of
packages built by different compilers.

I was thinking that if the chosen compiler were built, GCC_REQD set, and
then everything make replace'd then we would be back to a single ABI.

> Is there any substantive difference between /usr/pkg/COMPILER and
> /usr/pkg/gcc8 (or whatever version)?  I’m not seeing one and so it
> feels like needless complexity

yes, the point is that the compiler and the packages it depends on are
isolated and therefore are not in the standard prefix having been built
with what is eventually the standard compiler.

Do you believe that compiling every package with a random compiler,
chosen from the set where the build succeeeds from that package, will
lead to a correct system?

>> Or, to add
>> 
>>  --bootstrap-compiler=gcc7
>> 
>> that will run the sub-bootstrap as a subroutine and then use it.
>
> Please do not confuse the trivial patch I sent with what would be the
> real implementation of the idea.  Of course, the selection logic would

I'm not blurring that.  I'm bringing up an issue which you think doesn't
matter, and which I think does.  I'm meaning to talk about the compiler
used for pkgsrc being isolated, and not leading to packages in the main
prefix compiled with the wrong compiler.

> be backed by command line options like you suggest here in order to do
> the configuration.  I was only trying to illustrate what could be the
> minimal impact of actually using whatever options were selected.  That
> is to say, a real patch would include command option logic that would
> ultimately execute some properly configured version of the small bit
> of code that I actually patched manually.  I felt that we could
> discuss the idea of this independently of the command option logic,
> especially if we can see from the patch what execution path would be
> influenced.

we can discuss it separately, and I think the core logic is what needs
to be agreed on.  I have come to believe that trying to build the
compiler you need within the prefix where it will be used is basically
being on thin ice, unless someone can explain how gcc has ABI stabiltiy
rules (and meets them) that I don't think it has.

>> One thing that's important is to have an easy way for this to be
>> declared as default so that bulk builds use it, if we decide a certain
>> approach is the way to go.  This perhaps includes NetBSD where we are
>> seeing that the base system compiler on 7 is really too old and the one
>> on 8 is already too old.
>
> The obvious way to declare defaults would be the same as for anything
> in the bootstrap, wouldn’t it?  Just have default values for the
> appropriate command options.  Again, that is an entirely separate
> discussion from whether or not the "single bootstrap with selected
> compiler” approach makes sense as an option.

For people that actually run a bootstrap, yes it's a default.  On NetBSD
people do not normally bootstrap, so it's different.

> It seems that we are a bit off track and making this more complex than
> it really needs to be.  If feel if we can focus on the use cases I
> identified above (are there others?) we can also focus on how to
> address them in the simplest way.

I think you are ignoring the ABI stability issues and relying on the
fact that recently one can mostly get away with ignoring that.  With
earlier gcc versions one could not.

So here's a question:  If on netbsd-8, you:

  run a bootstrap
  build gcc8
  set GCC_REQD=8
  (which is what I think you want the new bootstrap to do)

then

  1) how many packages does you have (built with gcc5)?

  2) Are any of them built with c++ and linking to libstdc++?

  3) Is it guaranteeed to be sound if those libs are included in some
     other program?

  4) If one does pkg_rolling-replace, or make replace, will each of them
     then be rebuilt with gcc8?   Will that cause any issues?  Can you
     prove by specs/guaranteees of ABI stability that it will not?