Re: [gentoo-dev] Gentoo i486 support

["M. J. Everitt" <m.j.everitt@iee.org>]

[-- Attachment #1.1: Type: text/plain, Size: 1641 bytes --]

On 22/08/18 20:20, Matt Turner wrote:
> On Wed, Aug 22, 2018 at 5:26 AM Ben Kohler <bkohler@gentoo.org> wrote:
>> 2) Patch catalyst to start setting CXXFLAGS again.  Rather than roll
>> back to exactly CXXFLAGS="${CFLAGS}" again, it's been suggested that we
>> start setting COMMON_FLAGS, and CFLAGS="${COMMON_FLAGS}"
>> CXXFLAGS=${COMMON_FLAGS}" etc.  I prepared such a patch a while back
>> [4], which seems to work but may need a bit of updating.
> [snip]
>> [2]
>> https://gitweb.gentoo.org/proj/catalyst.git/commit/?id=b409bd9bb4b50f69a555e4e148057ade86a7ed16
> I don't think that was intentional, was it?
>
> That commit looks like it's supposed to just be a plain refactor (It's
> titled "stagebase.py: Refactor the *FLAGS handling code in
> chroot_setup()" after all) so it shouldn't have changed behavior. I'm
> guessing the commit is just broken. It doesn't even look like the
> commit message was finished when it was pushed.
>
> I think you should do whatever is required to fix catalyst brokenness.
>
Discussions on IRC in -releng demonstrate that this change resulted in
the CXXFLAGS variable *disappearing* from the stage3 make.conf. I
consider this a regressoin. I haven't personally looked as to how this
happened (although I'm familiar with the code from ARM profile changes),
but I think that also needs fixing. All my workstations descend from the
time when both CFLAGS *and* CXXFLAGS were set in make.conf and I hadn't
noticed this until today; however, this is a secondary issue to the one
that Ben has highlighted, which is a rather unhelpful fall-back
situation for x86 users ..

MJE


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]