under HAVE_NBTOOL_CONFIG_H for disktab.h as well. This means
disktab.h has to be installed in the nbinclude include directory.
(Failure mode: with TOOLDIR as a subdirectory of /usr, the host's disktab.h
got picked up, and not the in-tree copy.)
Reviewed by dyoung.
and install ${TOOLDIR}/bin/${MACHINE_GNU_PLATFORM}-disklabel,
${TOOLDIR}/bin/${MACHINE_GNU_PLATFORM}-fdisk by "reaching over" to
the sources in ${NETBSDSRCDIR}/sbin/{disklabel fdisk}/.
To avoid clashes with a build-host's header files, especially on
*BSD, the host-tools versions of fdisk and disklabel search for
#includes such as disklabel.h, disklabel_acorn.h, disklabel_gpt.h,
and bootinfo.h in a new #includes namespace, nbinclude/. That is,
they #include <nbinclude/sys/disklabel.h>, <nbinclude/machine/disklabel.h>,
<nbinclude/sparc64/disklabel.h>, instead of <sys/disklabel.h> and
such. I have also updated the system headers to #include from
nbinclude/-space when HAVE_NBTOOL_CONFIG_H is #defined.
1. Works if the last line does not end up in \n
2. Does not scan the string multiple times.
3. Does not copy the string, but writes it directly in the buffer.
4. Handles out of memory conditions gracefully.
the build step. Catches things like binutils which do a bunch of configures
on the build step and lose possibly. Fixes issues from PR#29197 for lex
not being picked up here.
so generated objects vs listed objects in make line up and dependcies happen
correctly. Found because libiberty (on this binutils import) was leaving
all objects as ./object.o and make wasn't picking up correct depends on
config.h as a result.
gets built and installed in a hp700 distribution.
TODO
- merge with hp300
- pick a preferred method for dealing with the elf headers.
hp700-mkboot and prep-mkbootimage (bintuils) vs mips-elf2ecoff and
tools/installboot
this is not currently being used and should be replaced with
HAVE_STRUCT_STATVFS_F_IOSIZE, but that will be done separately.
This commit should be able to be safely pulled up to
the netbsd-2-0 branch to address PR toolchain/26415
So, don't wrap definitions in it, and instead check for it and #error out
if it somehow leaks into scope.
Tested a complete build to sets on x86 from a clean source tree.
- Protect dirfd() macro so that we don't re-define it.
These changes make my build proceed further.
The problem is that automatically generated files, might include system
files before they include anything else (for example our yacc skeleton
includes <stdlib.h> before it does anything else). This foils the scheme
of defining _POSIX_SOURCE and friends so that _NETBSD_SOURCE does not
get defined; in fact, we include many files with _NETBSD_SOURCE defined,
enough to cause confusion in compat_defs.h which tries to re-define things.
exposed all the time, but routines which use it do not. Otherwise callers
of strtouq will lose.
XXX: Need to come back through here and clean up the configure tests better
for this
_NETBSD_SOURCE as this makes cross building from older/newer versions of
NetBSD harder, not easier (and also makes the resulting tools 'different')
Wrap all required code with the inclusion of nbtool_config.h, attempt to
only use POSIX code in all places (or when reasonable test w. configure and
provide definitions: ala u_int, etc).
Reviewed by lukem. Tested on FreeBSD 4.9, Redhat Linux ES3, NetBSD 1.6.2 x86
NetBSD current (x86 and amd64) and Solaris 9.
Fixes PR's: PR#17762 PR#25944
sure to use _POSIX_C_SOURCE and undef _NETBSD_SOURCE so the myriad of NetBSD
extentions don't get pulled into scope (and likely conflict at some point
with branched code trying to build on -current due to drift). Fixes PR#25533
XXX: The entire process here is just wacky and the entire cross tools process
needed to be reviewed to build clean w. just _POSIX_C_SOURCE or the equiv
set on NetBSD hosts or this will lose again somewhere..
no dependencies are known in advance. So a simple 'build.sh -r -u' will
often lose and end up with a TOOLDIR without a toolchain, groff, etc. Fix
by forcing .install_done to always run.
Instead of adding MAKE_BOOTSTRAP for hosted environments, i.e., when
you want things simple, instead add MAKE_NATIVE to get those hugely
important features like __RCSID().
Also, get rid of a now-unneeded -I.
This means that the tools now have correct dependencies (xxx.lo: ... instead
of xxx.o: ...) and in particular causes the pax to be built with consistent
headers.
There could also be other lossage on update builds of tools.
Fix the behaviour of native and tools gcc when MKPIC=no is specified for
platforms that mknative has determined support shared libraries.
XXX distrib/sets/sets.subr doesn't support MKPIC=no
and exception handling have a chance of working properly.
- creates libgcc, libgcc_eh and libgcc_s
- updates LIBGCC_SPEC to use them appropriately.
There's a hack in here at the moment with respect to libgcc_so in that it
is preferable to link against libgcc_so will only when -shared-libgcc is
specified (the c++ frontend does this automatically.) Configurations where
LINK_EH_SPEC is defined already do this. The gcc configuration for
NetBSD/alpha and another NetBSD platform (I forget which) actually define
LINK_EH_SPEC probably by accident rather than design.
- updates share/mk to use the compiler's knowledge of what needs linking into
libraries and executables. This removes an hppa hack.
- updates the sets for the newly created libgcc* files.
- support for linking against the _pg version of libgcc has been removed.
- Disable symbol versioning (for now)
- Make sure that libiberty knows its being configured with a
cross compiler.
- The CXX_* variables are no longer needed/used.
- LIB2FUNCS_EXTRA gets pulled in via LIB2ADD
- Get LIB1ASMFUNCS and LIB2ASMSRC
- MAYBE_USE_COLLECT2 got renamed to USE_COLLECT2 (but might not
be used)
- Get EXTRA_HEADERS so that we get generate the right paths for
CPPFLAGS
- Get some variables related to shared libgcc
There are three levels of compliance w.r.t. HOSTEXEEXT. (1) built and
installed both wrong, (2) both right, and (3) one right, one wrong.
Most tool builds do (1), i.e., wrong, but not seriously so. This makefile
actually built them the "right" way, leading to error (3), which was fatal.
* Rename "config.h" to "nbtool_config.h" and
HAVE_CONFIG_H to HAVE_NBTOOL_CONFIG_H.
This makes in more obvious in the source when we're using
tools/compat/config.h versus "standard autoconf" config.h
* Consistently move the inclusion of nbtool_config.h to before
<sys/cdefs.h> so that the former can provide __RCSID() (et al),
and there's no need to protect those macros any more.
These changes should make it easier to "tool-ify" a program by adding:
#if HAVE_NBTOOL_CONFIG_H
#include "nbtool_config.h"
#endif
to the top of the source files (for the general case).
* Rename "config.h" to "nbtool_config.h" and
HAVE_CONFIG_H to HAVE_NBTOOL_CONFIG_H.
This makes in more obvious in the source when we're using
tools/compat/config.h versus "standard autoconf" config.h
* Consistently move the inclusion of nbtool_config.h to before
<sys/cdefs.h> so that the former can provide __RCSID() (et al),
and there's no need to protect those macros any more.
These changes should make it easier to "tool-ify" a program by adding:
#if HAVE_NBTOOL_CONFIG_H
#include "nbtool_config.h"
#endif
to the top of the source files (for the general case).
* Don't bother prefixing commands with a line of ${_MKCMD}\
and instead rely upon "make -s". This is less intrusive on
all the Makefiles than the former. Idea from David Laight.
* Rename the variables use to print messages. The scheme now is:
_MKMSG_FOO Run _MKMSG 'foo'
_MKTARGET_FOO Run _MKMSG_FOO ${.TARGET}
From discussion with Alistair Crooks.
the tool build from attempting to build the GCC crtstuff before the
target include files are installed. PR toolchain/23112.
(Note: You would not see the bad behavior described in the PR unless
your .mk files were hacked to configure the toolchain target as
*-*-netbsd*2.0.)
<sys/bootblock.h>:
* Added definitions for the Master Boot Record (MBR) used by
a variety of systems (primarily i386), including the format
of the BIOS Parameter Block (BPB).
This information was cribbed from a variety of sources
including <sys/disklabel_mbr.h> which this is a superset of.
As part of this, some data structure elements and #defines
were renamed to be more "namespace friendly" and consistent
with other bootblocks and MBR documentation.
Update all uses of the old names to the new names.
<sys/disklabel_mbr.h>:
* Deprecated in favor of <sys/bootblock.h> (the latter is more
"host tool" friendly).
amd64 & i386:
* Renamed /usr/mdec/bootxx_dosfs to /usr/mdec/bootxx_msdos, to
be consistent with the naming convention of the msdosfs tools.
* Removed /usr/mdec/bootxx_ufs, as it's equivalent to bootxx_ffsv1
and it's confusing to have two functionally equivalent bootblocks,
especially given that "ufs" has multiple meanings (it could be
a synonym for "ffs", or the group of ffs/lfs/ext2fs file systems).
* Rework pbr.S (the first sector of bootxx_*):
+ Ensure that BPB (bytes 11..89) and the partition table
(bytes 446..509) do not contain code.
+ Add support for booting from FAT partitions if BOOT_FROM_FAT
is defined. (Only set for bootxx_msdos).
+ Remove "dummy" partition 3; if people want to installboot(8)
these to the start of the disk they can use fdisk(8) to
create a real MBR partition table...
+ Compile with TERSE_ERROR so it fits because of the above.
Whilst this is less user friendly, I feel it's important
to have a valid partition table and BPB in the MBR/PBR.
* Renamed /usr/mdec/biosboot to /usr/mdec/boot, to be consistent
with other platforms.
* Enable SUPPORT_DOSFS in /usr/mdec/boot (stage2), so that
we can boot off FAT partitions.
* Crank version of /usr/mdec/boot to 3.1, and fix some of the other
entries in the version file.
installboot(8) (i386):
* Read the existing MBR of the filesystem and retain the BIOS
Parameter Block (BPB) in bytes 11..89 and the MBR partition
table in bytes 446..509. (Previously installboot(8) would
trash those two sections of the MBR.)
mbrlabel(8):
* Use sys/lib/libkern/xlat_mbr_fstype.c instead of homegrown code
to map the MBR partition type to the NetBSD disklabel type.
Test built "make release" for i386, and new bootblocks verified to work
(even off FAT!).
* DPSRCS contains extra dependencies, but is _NOT_ added to CLEANFILES.
This is a change of behaviour. If a Makefile wants the clean semantics
it must specifically append to CLEANFILES.
Resolves PR toolchain/5204.
* To recap: .d (depend) files are generated for all files in SRCS and DPSRCS
that have a suffix of: .c .m .s .S .C .cc .cpp .cxx
* If YHEADER is set, automatically add the .y->.h to DPSRCS & CLEANFILES
* Ensure that ${OBJS} ${POBJS} ${LOBJS} ${SOBJS} *.d depend upon ${DPSRCS}
* Deprecate the (short lived) DEPENDSRCS
Update the various Makefiles to these new semantics; generally either
adding to CLEANFILES (because DPSRCS doesn't do that anymore), or replacing
specific .o dependencies with DPSRCS entries.
Tested with "make -j 8 distribution" and "make distribution".
Replace defined(UNPRIVED) tests with ${MKUNPRIVED} != "no"
Add MKUPDATE; if not no has the same semantics as if UPDATE was defined.
Replace defined(UPDATE) tests with ${MKUPDATE} != "no"
Improve documentation for these and other make flags.
the same as "$TOOLDIR", run "make cleandir" here first.
This should prevent various problems where $TOOLDIR is encoded into the
build process for various tools (lint, groff, texinfo, toolchain),
$TOOLDIR changes, and various programs don't get rebuilt correctly.
Should fix PR [toolchain/21988].
* Clean up how the `${MKTOOLS} == no' check is performed.
* Remove "cleantools"; it made a big assumption about the location of
TOOLDIR that won't be correct in many cases.
program/tool from "FOO" to "TOOL_FOO". The new variables are:
TOOL_ASN1_COMPILE TOOL_CAP_MKDB TOOL_CAT TOOL_CKSUM TOOL_COMPILE_ET
TOOL_CONFIG TOOL_CRUNCHGEN TOOL_CTAGS TOOL_DB TOOL_EQN TOOL_FGEN
TOOL_GENCAT TOOL_GROFF TOOL_HEXDUMP TOOL_INDXBIB TOOL_INSTALLBOOT
TOOL_INSTALL_INFO TOOL_M4 TOOL_MAKEFS TOOL_MAKEINFO TOOL_MAKEWHATIS
TOOL_MDSETIMAGE TOOL_MENUC TOOL_MKCSMAPPER TOOL_MKESDB
TOOL_MKLOCALE TOOL_MKMAGIC TOOL_MKTEMP TOOL_MSGC TOOL_MTREE
TOOL_PAX TOOL_PIC TOOL_PREPMKBOOTIMAGE TOOL_PWD_MKDB TOOL_REFER
TOOL_ROFF_ASCII TOOL_ROFF_DVI TOOL_ROFF_HTML TOOL_ROFF_PS
TOOL_ROFF_RAW TOOL_RPCGEN TOOL_SOELIM TOOL_SUNLABEL TOOL_TBL
TOOL_UUDECODE TOOL_VGRIND TOOL_ZIC
For each, provide default in <bsd.sys.mk> of the form:
TOOL_FOO?= foo
and for the ${USETOOLS}=="yes" case in <bsd.own.mk>, provide override:
TOOL_FOO= ${TOOLDIR}/bin/${_TOOL_PREFIX}foo
Document all of these in bsd.README.
This cleans up a chunk of potential (and actual) namespace collision
within our build infrastructure, as well as improves consistency in
the share/mk documentation and provision of appropriate defaults for
each of these variables.
for a 64-bit target on a 32-bit host.
NB: There seems to be a bug in either gcc itself or the way we import
it, b/c the incorrect #define HAVE_ATOLL is picked from (e.g. for
sparc64) gnu/usr.bin/gcc/arch/sparc64/auto-host.h - so when gen*
auxilary (host) programs are built in gnu/usr.bin/gcc/backend, they
incorrectly pick-up target's HAVE_ATOLL.
For now providing atoll(3) in libnbcompat is a simple and sufficient
workaround.
by the application, all NetBSD interfaces are made visible, even
if some other feature-test macro (like _POSIX_C_SOURCE) is defined.
<sys/featuretest.h> defined _NETBSD_SOURCE if none of _ANSI_SOURCE,
_POSIX_C_SOURCE and _XOPEN_SOURCE is defined, so as to preserve
existing behaviour.
This has two major advantages:
+ Programs that require non-POSIX facilities but define _POSIX_C_SOURCE
can trivially be overruled by putting -D_NETBSD_SOURCE in their CFLAGS.
+ It makes most of the #ifs simpler, in that they're all now ORs of the
various macros, rather than having checks for (!defined(_ANSI_SOURCE) ||
!defined(_POSIX_C_SOURCE) || !defined(_XOPEN_SOURCE)) all over the place.
I've tried not to change the semantics of the headers in any case where
_NETBSD_SOURCE wasn't defined, but there were some places where the
current semantics were clearly mad, and retaining them was harder than
correcting them. In particular, I've mostly normalised things so that
_ANSI_SOURCE gets you the smallest set of stuff, then _POSIX_C_SOURCE,
_XOPEN_SOURCE and _NETBSD_SOURCE in that order.
Tested by building for vax, encouraged by thorpej, and uncontested in
tech-userlevel for a week.
dbj