tech-pkg archive

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

Re: default C versions

> On Jun 30, 2023, at 1:40 PM, Greg Troxel <> wrote:
> David Brownlee <> writes:
>> If I could ask two random stupid questions? :)
>> Would it be possible to manage this by having GCC_REQD set by default
>> on such a platform, with code to allow "BYPASS_GCC_REQD", so bootstrap
>> could set BYPASS_GCC_REQD to build pkg_tools, and then again to build
>> a useful gcc version? (though rebuilding any gcc dependency later
>> would switch to one built with gcc, which may be... unhelpful)
> This is sort of what Jason has done, but slightly different.  It would
> be nice if this were package settable as well, so rebuilds would be
> consistent and it would work on NetBSD which does not bootstrap.   I
> think the way for you to find out if it's possible reasonable is to
> prototype it and see.
> Jason's approach means that things in the gcc build path (which is a
> crazy big set) use the base compiler.
>> Alternatively, would it be feasible to bootstrap twice, once without
>> GCC_REQD just enough to build a gcc package which would install in
>> /usr/pkg-gcc and then a normal bootstrap into /usr/pkg using that as
>> an external compiler?
> Probably.  Please prototype and post, and that might be something people
> might want to use.  The real win would be that if we can say "on
> platforms with gcc < X, this is the way" and have pbulk do it too,
> because if it doesn't work in the default pbulk, it doesn't work at all
> from the viewpoint of binary package sets.
>> If neither of those work, would there be an sense in maintaining the
>> code you included in-pkgsrc-tree as a file not included by default?
> As something to opt into, that seems reasonable to me.  So far there has
> not been a "I would like to commit this; please review".   Besides not
> surprising people, keeping it optional makes the /usr/pkg-compiler tree
> approach (be it gcc or clang) also feasible.

I would very much like to see an integrated solution to this problem, as I often run into systems with funky toolchains, which makes it hard to get pkgsrc up and running.

One idea I have considered is adding a variable to Makefiles for dependencies to indicate the versions of gcc they are dependencies for.  Then the depends logic (perhaps with another opt-in selection?) could automatically bypass the GCC_REQD stuff for the appropriate subset of packages.

Maintenance would only require updating these variables for new gcc versions.  Jason’s work more or less does this, but entirely outside of pkgsrc; his lists could be used to initially populate these putative variables.

Does this make sense as an approach?


Home | Main Index | Thread Index | Old Index