svn commit: r351364 - in head/sys: crypto/blowfish crypto/chacha20 crypto/des opencrypto

Mark Millard marklmi at yahoo.com
Sat Aug 24 19:15:01 UTC 2019


Warner Losh imp at bsdimp.com wrote on
Fri Aug 23 22:05:39 UTC 2019 :

> On Fri, Aug 23, 2019 at 12:26 PM Conrad Meyer <cem at freebsd.org> wrote:
> 
> > At expected peril of wading into a thread >4 emails deep,
> >
> > @Warner, modern GCC reports a similar warning; it just doesn't become
> > an error (at least in CI?).  I'm not sure of the mechanism.  Maybe
> > CI-specific?  Old GCC didn't have a -Wno-error for -Wcast-qual, so
> > -Wcast-qual + -Werror there produced an error; that's why
> > $NO_WCAST_QUAL in conf/kern.mk is defined to -Wno-cast-qual for old
> > GCC but -Wno-error=cast-qual for newer compilers.  That said, this
> > file does not appear to be compiled with ${NO_WCAST_QUAL} either way.
> >
> 
> Yea. I'm unsure. It's an odd warning, and an odd way to get around it. In
> general, nobody cares about gcc 4.2.1, so pinning implementing that belief
> to this specific bug may have been unwise. I just assumed newer versions
> wouldn't warn on this, but I saw on IRC that the types are stupidly
> different...
. . .

While I know how to build for powerpc64 ( using WITHOUT_LIB32= )
without using gcc4.2.1 or the matching binutils, 32-bit powerpc
is not so clear for how to target without gcc 4.2.1, at least
based on what I'm familiar with. (I normally work with materials
from the official FreeBSD svn, not other development material
sources.)

(Locally reverting the secure-plt change would help for
amd64->powerpc cross builds based on system-clang and
devel/powerpc64-binutils or base/binutils . Even lld from
devel/llvm90 is not ready for 32-bit powerpc as yet, from what
I've seen, so llvm90 is not yet a self-contained solution.)

May be someone else does know a good way to build FreeBSD for
tracking head for targeting 32-bit powerpc as things are now?
May I the only one not knowing how to build for this target
as things are?

I'd been trying to avoid disabling the secure-plt change
that causes gnu's modern ld's to revert to bss-plt and return
an error code that stops the build when system-clang or
llvm90 is used. (The old FreeBSD ld does not return the error
code but does report reverting to bss-plt. But it fails for
buildkernel via a separate issue when system-clang is used.)

As stands I'm not aware of how to target 32-bit power pc
from some more modern gcc/binutils combination.

As stands it looks like reverting secure-plt's use is the
direction I'd have to go to avoid gcc 4.2.1 .

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)



More information about the svn-src-head mailing list