(auto) finds the mpfr library in tools, but then when it tries to build using
the proper headers it does not find it anymore since we don't install it
(like the native build does not find it).
the Matt Thomas rbtree:
- Include rb.c in libnbcompat, and provide a nbcompat sys/rbtree.h
header.
- Make sure libprop's source file include prop_object_impl.h before
anything else, and pull in nbtool_config.h from there.
Tested by simulating such a host system by renaming the host's
<sys/rbtree.h> out of the way (which reproduced the build failure)
and verifying that the host-tool installboot contained the rb_*
functions in its own .text segment.
boards that use u-boot. A known board database lists boards and their
respective u-boot packages. u-boot packages are discovered at run-time
(in /usr/pkg/share/u-boot, by default). These packages contain board
database overlays that describe u-boot installation procedure that's
specific for that board.
Support this as a native tool and as a host tool. The native tool
will attempt to determine the running board type using OpenFirmware
calls. Host tool and native tool alike may also specify a board type
directly using the "-o board=xxx option" or have installboot(8) determine
the board type from a device tree blob using "-o dtb=/path/to/board.dtb".
A "-o media=xxx" option is provided for boards that have different u-boot
binaries and/or installation procedures for different media types (e.g.
SDMMC, eMMC, or USB).
This is trivial to extend to other evb* platforms that use u-boot, even if
they don't use FDT for autoconfiguration.
- only build clang or clang-tblgen if MKLLVMCMDS != "no"
- move HAVE_MESA_VER earlier so we can detect mesa 18 and enable
MKLLVM on platforms that need it
- move the clang commands and headers into llvmcmds group
- only build the clang specific LLVM libraries if MKLLVMCMDS != "no"
much of this work came from maya@'s github commit
f90685c11d4460d3098fa35f48b58d1893e974e0, reworked for HAVE_MESA_VER
and llvmcmds vs MKCLANG.
build tested on several platforms and on amd64 and i386 with several
different build options (clang build, gcc build, gcc build with llvm
libs).
unfortunately, we attempted to do this for netbsd-8 but we did
not actually end up having any ABI incompatibility with that,
as turning off dual ABI in libstdc++ means *only* enabling the
old ABI. however, enabling dual ABI with C11 defaults (ie,
a forward looking ABI) *is* an ABI-change for some special
cases and thus we should have bumped this a couple of weeks
ago when we re-enabled dual ABI.
call this "nb3 20190319".
mknative-gcc regen all switched ports and almost all of the
unswitched ports.
touch the build. this comes from:
commit f90685c11d4460d3098fa35f48b58d1893e974e0
Author: Maya Rashish <maya@NetBSD.org>
Date: Sat Feb 23 09:46:14 2019 +0200
Separate MKCLANG from MKLLVM.
build LLVM libraries as PIC.
Add AMDGPU target, and adjust tools accordingly.
the checking for gcc 4.6 and some exception handling routines which
we need on several platforms.
this should fix missing symbol issues seen on current-users.
having dozens of copies of the same thing in the tree.
- don't fetch any gthr*.h files.
- delete ancient gthr-tpf.h that was removed in GCC 4.8 or so.
this should fix the call_once tests for real now.
the configuration in this version of file is non-functional and results
in build failure if detected. The next version should be fine, but let's
ensure nobody runs into this build failure until it's imported.
reported by e3ef13f4ff44 on freenode.
--build to the same as the --host, so that it never changes based
upon the host you ran mknative on. (some recent changes are only
because i updated a system from netbsd-7 to netbsd-8. this will
avoid that in the future.)
programs there; make all Makefiles that use bsd.hostprog.mk include it.
Namely turn off MKREPRO and don't make lint, man pages, info files etc.
Remove the Makefile.inc files that contained these same settings, and
remove the settings from Makefile.host
not support the necessary options. This is done thusly:
1. Set MKREPRO=no in Makefile.host. This handles all the Makefiles that
use it and don't include bsd.own.mk.
2. Create Makefile.inc and set MKREPRO=no in it. Change the Makefiles that
include bsd.own.mk, to include bsd.init.mk which includes Makefile.inc
first. This will also allow us to control other tools options from a
single location if we need to.
XXX: pullup-8
- sys/arch/evbarm64 is gone and integrated into sys/arch/evbarm. (by skrll@)
- add support fdt. evbarm/conf/GENERIC64 fdt (bcm2837,sunxi,tegra) based generic 64bit kernel config. (by skrll@, jmcneill@)
- HAVE_GCC=5 is now the default (vs. HAVE_GCC=53 we've been using for
GCC 5.4 and GCC 5.5.)
- remove some more GCC 4.8 code. we don't support GCC 4 here.
- adjust set lists to gcc=5 from gcc=53.
add some basic HAVE_GCC=6 handling (totally unused so far.)
CFLAGS set to HOST_CFLAGS, etc - so HOST_* environment variables are
already taken into account if set.
OTOH, if configure were to add anything to CFLAGS etc, the old code
would happily ignore those changes, picking up original environment
variables instead.
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
uwe