system in a messy state *if* the user is upgrading from a system
which has no /libexec to a system which builds a DYNAMICROOT, and
if that user has set DISTDIR (as documented for ports, but it turns
out that the same variable name is used for a completely unrelated
purpose in 'make release').
There are other possible fixes for this issue, and ru@ may later
decide to commit one of those fixes. I just wanted some fix in
ASAP, and this is the fix that I have tested.
Reviewed by: bde, imp, and ru
as it was decided that our toolchain will revert to looking
for libraries in /usr/lib only.
- Make /usr/lib/libfoo.so -> /lib/libfoo.so.X symlinks absolute
so that they still work if /usr is symlinked.
- Remove stale /usr/lib/libfoo.so.X libraries during install.
Discussed with: gordon, obrien, peter
syntax. The
make buildworld
mv /usr/include /usr/include.old
make installworld
issue has been fixed a month ago in Makefile,v 1.285, and there
is no valid reason to continue to keep the wrong syntax here --
buildworld takes care of upgrading a make for you if necessary.
But if you find yourself in an environment with an old make(1)
binary that breaks on this, and this is because you attempted
to run a target other than buildworld, don't whine but try again
with -DALWAYS_CHECK_MAKE defined -- it should do the trick.
Otherwise, if you still have a problem, please report it as a
bug and attach the ``make -dl ...'' output.
Reviewed by: marcel
5.x signal code from the 4.x signal code. The split happened in
Oct 2002 and we have had 2 releases since then. A kernel older than
5.0-R cannot reasonably be called a -current kernel anymore.
This does not break upgrading from an 10 month older kernel. It just
makes it more exiting.
/usr/include/osreldate.h doesn't exist on the system. While this
could be worked around by saying something like 'make includes
OSLRELDATE=0' when this file doesn't exist, it is just as easy to
provide a fallback when the file we know we depend on doesn't exist.
While this doesn't make all targets work w/o a
/usr/include/osreldate.h, because some of the FreeBSD bootstrap tools
use this file. 'make includes' however does work.
Noticed by: peter, obrien (and likely others)
Pointy hat to: imp (for suggesting a method that depended on /usr/include)
using underscores or not, so I just randomly picked a style. I think
I have the logic correct, but if someone wants to give it a once over
that would be good.
Tim submitted a patch to fix the cross-building issues which I tested
with a tinderbox run for sparc64.
Submitted by: Tim Kientzle <kientzle@acm.org>
The latter needs to be built either if it's used as a cross-tool
(${TARGET_ARCH} != ${MACHINE_ARCH}) or if it has backward compat
issues, like e.g. lack of the AMD64 support.
4.8-stable:
Must build lib/libc before libpthread. Fix how we do this to be more
consistant with how lists are handled in the file. Also, don't bother
to prebuild libc if we're not building libpthread.
Submitted by: ru@
Reviewed by: bde@ (before ru@ submitted it)
This was the initial intent anyway, and it became clear that it is
really necessary to treat it this way, as many people happen to run
with kernel newer than the installed world.
Submitted by: imp, ru
Approved by: re (scottl)
in the SHARED=symlinks case. Symlinks to directories only work if all the
the necessary headers are in 1 directory, but the necessary headers are
scattered for at least ipfilter headers in <netinet>. This change also
avoids polluting /usr/include with non-headers; the /usr/include hierarchy
is now independent of the setting of SHARED.
Submitted by: ru (edited to fix netgraph/bluetooth/include and machine/pc)
PR: 44148
supported, it usually works for months at a time. Allow these people
to override the OSRELDATE of their installed world when things don't
match and the exact OSRELDATE matters and is different than the
kernel. Now that Makefile.inc1 depends more and more about which date
you have to optimize the pieces it builds, it may be necessary to
pessimize things if its guesses are wrong.
If OSRELDATE is already set, we won't fork the sysctl to find out what
the kernel's date is.
Developers on IRC suggested that they run mismatches all the time as
well.
Reviewed by: obrien
This allows us to use them as early as possible while building
bootstrap-, build-, and cross-tools. Some cleanups to follow.
This change resolves the gperf(1) bootstrapping issue (missing
-E option) in gnu/usr.bin/cc/cc1plus while in the cross-tools
stage when upgrading from 4.0-RELEASE.
legacy stuff (binutils) depend on this order.
For this to work, provide (and use) specialized versions
of bsd.prog.mk and bsd.lib.mk that include the standard
versions first, then augment CFLAGS, DPADD, LDADD, and
LDFLAGS as necessary, with the legacy stuff.
Tested on: 4.0-RELEASE
is because we populate these directories later, and a subsequent
-DNOCLEAN build may fail. So, we put them in
${WORLDTMP}/build/usr/{include,lib} instead and adjust Makefile.boot.
Again, this works on -stable and -current, but might break older
versions.
Submitted by: ru@
FreeBSD. This method attempts to centralize all the necessary hacks
or work arounds in one of two places in the tree (src/Makefile.inc1
and src/tools/build). We build a small compatibility library
(libbuild.a) as well as selectively installing necessary include
files. We then include this directory when building host binaries.
This removes all the past release compatibilty hacks from various
places in the tree. We still build on tip of stable and current. I
will work with those that want to support more, although I anticipate
it will just work.
Many thanks to ru@, obrien@ and jhb@ for providing valuable input at
various stage of implementation, as well as for working together to
positively effect a change for the better.
buildworld. This gives 5-11% percent gain in real buildworld
times on various UP and SMP systems here. I used 4 * hw.ncpu
as an argument to "make -j" in my tests.
glibc which is externally maintained, so GCC ships with these
warnings turned off by default. This is also consistent with
the src/contrib/gcc/c-lex.c,v 1.2 change.
and kgzip(8) from the list of cross-tools during the normal,
non-"make release" buildworld.
Also, don't gratuitously build them, btxld(8) and elf2aout(1)
for native architecture builds, since they have no known
boostrapping issues along the supported upgrade path.
Prodded by: peter
from the source directory. (This mostly affects the RELENG_4's
``make release'' release.5 target, where "rtermcap" build-tool
for release/sysinstall ends up in the source directory and later
steps of release.5 wipe it out.)
Spotted by: jhay
is a compiler tool and needs to be compiled by the host compiler. I've
tested this in i386->sparc cross-build, 4.7->current upgrade, normal
buildkernel target, and normal /sys/i386/compile/GENERIC configurations.
Submitted by: ru
non-cross cases without DESTDIR, that the bin/sh that we're about to
install works. Otherwise, a 'make installworld' without having already
rebooted with a post-signal-fix kernel is a rather big disaster when
important things like /bin/sh coredump.
under way to move the remnants of the a.out toolchain to ports. As the
comment in src/Makefile said, this stuff is deprecated and one should not
expect this to remain beyond 4.0-REL. It has already lasted WAY beyond
that.
Notable exceptions:
gcc - I have not touched the a.out generation stuff there.
ldd/ldconfig - still have some code to interface with a.out rtld.
old as/ld/etc - I have not removed these yet, pending their move to ports.
some includes - necessary for ldd/ldconfig for now.
Tested on: i386 (extensively), alpha
doing the cd. This is done for bootstrap-tools,
build-tools, cross-tools, and the libraries loop.
Reviewed by: ru
Approved by: sheldonh (mentor)
MFC after: 1 week
endless recursion bug similar to the one that has been fixed in
release/Makefile,v 1.698, in advance. A related fix to make(1)
has been committed in make/main.c,v 1.68.
Requested by: bde (who has them merged already)
If there was no CPUTYPE assignment in /etc/make.conf, this would
cause the ``CPUTYPE assignment type'' check to falsely fail.
Reported by: johan
Fixed this by making sure we always pass the non-empty CPUTYPE.
Also make sure we use the correct set of share/mk files in our
test.
