Originally, MKCRYPTO was introduced because the United States
classified cryptography as a munition and restricted its export. The
export controls were substantially relaxed fifteen years ago, and are
essentially irrelevant for software with published source code.
In the intervening time, nobody bothered to remove the option after
its motivation -- the US export restriction -- was eliminated. I'm
not aware of any other operating system that has a similar option; I
expect it is mainly out of apathy for churn that we still have it.
Today, cryptography is an essential part of modern computing -- you
can't use the internet responsibly without cryptography.
The position of the TNF board of directors is that TNF makes no
representation that MKCRYPTO=no satisfies any country's cryptography
regulations.
My personal position is that the availability of cryptography is a
basic human right; that any local laws restricting it to a privileged
few are fundamentally immoral; and that it is wrong for developers to
spend effort crippling cryptography to work around such laws.
As proposed on tech-crypto, tech-security, and tech-userlevel to no
objections:
https://mail-index.netbsd.org/tech-crypto/2017/05/06/msg000719.htmlhttps://mail-index.netbsd.org/tech-security/2017/05/06/msg000928.htmlhttps://mail-index.netbsd.org/tech-userlevel/2017/05/06/msg010547.html
P.S. Reviewing all the uses of MKCRYPTO in src revealed a lot of
*bad* crypto that was conditional on it, e.g. DES in telnet... That
should probably be removed too, but on the grounds that it is bad,
not on the grounds that it is (nominally) crypto.
restore ABI compatibility with previous releases for ieeefp.h on sh3.
add namespace.h protection for all the fenv interfaces.
use MKSOFTFLOAT on sh3 instead of assuming softfloat.
standardize on comparing MKSOFTFLOAT with "no".
remove the arm-specific softfloat fenv code (which also had several bugs).
fix logic errors in the arm hardfloat feraiseexcept() and feupdateenv().
The problem is that the gnulib interception of <stdint.h> and <inttypes.h>
does not really work because we implement those internally with
<sys/inttypes.h> and <sys/stdint.h> and those internal headers are used
by other internal headers *before* they get a chance to be intercepted
(where the __STDC_ macros are defined).
Another way to fix this is to move the inclusion of the other headers
in <stdint.h> and <inttypes.h> outside multiple inclusion protection.
We don't have a tool that strips tools -- we have only a tool that
strips target programs. $TOOLDIR/bin/$PLATFORM-install supports -s
by invoking the target-stripping tool, which chokes if you try to use
it to strip tools on a sufficiently different cross build. So let's
just not strip the pcc tool -- it's tiny enough that I'm not worried
about its unstripped size!
- reenable cxx rt support
- don't grab insn-modes.h, we build it
- rename the c98 and c11 subdir codecvt.cc files while extracting
them with mknative
- grab GGC_H as well, and use it in dependency lists
This way, nbsed picks it up and it unbreaks the build of xf86-video-intel-old's
man page under Linux and probably other future changes which rightfully expect
the (net)bsd behaviour.
Full release tested on ArchLinux and NetBSD 7.0_STABLE
This way, nbsed picks it up and it unbreaks the build of xf86-video-intel-old's
man page under Linux and probably other future changes which rightfully expect
the (net)bsd behaviour.
- remove GCC 4.5 stuff, add most very basic GCC 5 stuff.
- use mknative-gcc.old for GCC 4.8
- copy mknative-gcc to mknative-gcc.old (should have done this when we
switched to using gcc.old.)
this should not affect current builds.
At least GNU Hurd lacks MAXHOSTNAMELEN/MAXPATHLEN/PATH_MAX, so make sure
those have some arbitrary semi-sane values.
from Robert Millan in PR misc/50166, with some modifications from myself
the support in the rest of the source tree.
X11 sets could use some cleaning up perhaps (just deletion, as
we've never really marked the old X11R6 as obsolete for native
xorg using platforms so far either.)
it to foo.h. This was causing problems with:
.y.h: ${.TARGET:.h=.c}
where .h was ./cgram.h and the source became ./cgram.c confusing for example
/usr/src/tools/lint1 because make had both cgram.c and ./cgram.c in the list
of sources, trying to build both of them in parallel thinking that they were
different files. Since the regular mkdep does not produce such dependencies,
the regular build does not suffer from this issue.
- Old JIT is removed.
- Improvements to debug information handling.
- ARM: check for deprecated instructions and warn in the integrated
assembler
- PPC: VSX support, va_arg support for struct/union types, -fPIC vs
-fpic supported, faster atomics
- x86: improved vectorizer
sh3/include/elf_machdep.h needs it since r1.11.
Unbreaks tools build on non-netbsd hosts (and whatever problems on
netbsd hosts of different endianness that might have been caused by
the mismatch).
as it is needed for the "includes" phase. Make it symlink all necessary
headers in obj to decouple it from "includes" itself, breaking the
dependency cycle. Move the do-x11 target between do-lib and do-build, so
that libraries can get the benefit of build_install (correct .WAIT
behavior) and everything else like "includes" uses the plain SUBDIR
entry in external/mit.
It's not practical for the C89 restriction to be maintained for
compilers, but it is still desirable for most tools. The "long long"
data type is in wide use despite not being in C89. C99 library features
(as opposed to language features) can often be added to the compat
framework when the need becomes apparent.
christos