| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
target. These are needed by liloldr.
Found by: make release
|
|
|
|
|
| |
is used by the installation of ld-elf.so when an existing version
exists.
|
|
|
|
| |
the one we built anyway.
|
|
|
|
|
|
|
| |
binaries we just installed. This allows a future upgrade target to
install a new system without intermediate reboots and also
prevents conflicts for parallel make runs where we might exec a
binary that's being installed at the same time.
|
| |
|
|
|
|
| |
It must solve make world breakage
|
| |
|
| |
|
|
|
|
| |
Not reviewed by: sheldonh
|
| |
|
| |
|
|
|
|
|
|
| |
the specific version in -current.
Approved in principle by: marcel
|
|
|
|
|
| |
All builds had been broken; now just upgrade builds are until I or
someone else can figure out the Right Thing.
|
|
|
|
| |
gcc does not depend on version-specific gperf behavior (yet).
|
|
|
|
|
| |
not create required parent directories of the kernel compile
directory specified with its -d option.
|
| |
|
|
|
|
|
|
|
| |
KERNEL specifies multiple kernels.
PR: 17536
Submitted by: Johan Karlsson <k@numeri.campus.luth.se>
|
|
|
|
| |
Approved by: peter
|
|
|
|
| |
Approved by: jkh
|
| |
|
|
|
|
| |
Goodbye libdes; Welcome libcrypto.
|
|
|
|
|
| |
PR: 16818
Submitted by: martti.kuparinen@nomadiclab.com
|
|
|
|
|
|
|
| |
we need -DNOFSCHG at stage 4 (building libraries) to support
non-root buildworlds.
Reviewed by: <buildworld@current.freebsd.org>
|
|
|
|
|
|
| |
src/gnu/libreadline -- reflect that change here.
Ok'ed by: JKH
|
|
|
|
| |
little gain. I'll work out the issues after 4.0R is out.
|
|
|
|
|
|
|
|
|
|
|
| |
and costs us an extra 2% to build it for no reason. It may break
building cross compilation environments for fortran, but that isn't
officially supported at this time anyway (also, the % of our user base
that would use that is < .001% imho). This does't break fortran (it
is built again later anyway).
Reviewed by: obrien
Tested by: make buildworld and make buildworld -DNOCLEAN
|
|
|
|
| |
faint_hearted; serious hackers only!
|
|
|
|
| |
Reviewed by: marcel
|
|
|
|
|
|
| |
from the cross-tools to the bootstrap-tools.
Requested by: bde, marcel
|
|
|
|
|
|
| |
Unbroke the world by moving gnu/usr.bin/texinfo before gnu/usr.bin/cc.
Submitted by: Jim Bloom <bloom@acm.org>
|
|
|
|
|
|
|
| |
We need an up-to-date `makeinfo' and `install-info'
at `world' and `install' stages.
Pointed out by: bde
|
|
|
|
|
|
| |
by gnu/usr.bin/cc/cc_tools/Makefile. This bug is painfully visible
when making buildworld with -DNOCLEAN. This work around is beyond
dirty...
|
|
|
|
|
|
| |
install; use the IMAKE context.
Reported by: sheldonh
|
|
|
|
|
|
| |
as non-root.
Breakage caused by: green
|
|
|
|
| |
in /usr/src/ anymore.
|
|
|
|
|
|
| |
corollary for -DNOINFO and -DNOMAN. I'll fix this properly (add
specific HTML doc magic) in the .mk files later; right now, just
unbreak the world.
|
|
|
|
|
|
| |
it's more easy to build a kernel with debugging information.
Suggested by: sheldonh
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
users can more easily upgrade.
buildworld now makes usr.sbin/config in bootstrap-tools so that
when you first make buildworld, buildkernel will use config(8)
from the temp. world tree (and of course also the compiler).
Which kernel to built is determined by the KERNEL variable. You
can have as many kernels listed as you like. When a config file
exists for the given MACHINE it will be built. When KERNEL has
not been defined it will be set to "GENERIC GENERIC98".
The first valid kernel named in the list will be used by the
installkernel target.
When NOCLEAN is defined the kernel object directory is *not*
removed by config first. This is in line with normal buildworld
behaviour.
The buildkernel target makes aicasm in sys/dev/aic7xxx first and
unconditionally. This hack allows us to cross-build kernels and
can go away when the problem is solved in a structural way.
|
|
|
|
| |
natively (ie non-i386 architectures).
|
|
|
|
|
|
|
|
| |
Makefile.
Fix make world by building appropriate build-tools.
Submitted by: marcel
|
| |
|
|
|
|
|
|
|
| |
If one wishes to anchor the compiler toolchain tree somewhere other than /,
all one needs to do is set "TOOLS_PREFIX" to a different rooting.
Submitted by: marcel (in a different format and reworked by me)
|
|
|
|
|
|
| |
imported these on Freefall yet for the reasons previously explained.
Noticed by: asami
|
|
|
|
|
|
|
| |
reading all my mail.
I still don't understand why this was was committed on freefall before
the libcrypto and libssl subdirectories were imported on freefall though.
|
| |
|
| |
|
|
|
|
|
| |
anymore. Update comments and variable names as well to wipe out any
traces that may confuse people in the future.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
o Add genassym to the list of cross-tools
o Remove sh hashing work-around, we don't need it anymore
o Clean more directories in WORLDTMP when NOCLEAN is specified
The sh hashing work-around is not needed anymore, because we don't
trigger the bug anymore.
When NOCLEAN is not defined, we wipe out the complete WORLDTMP,
including the object directories of the tools we have built. When
NOCLEAN is defined, we remove anything that we install anyway, which
is usr/bin, usr/games, usr/include, usr/lib and usr/sbin.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
property. This fixes the includes target when DESTDIR is empty.
o Do not make build-tools for f771 when NO_FORTRAN is defined.
o Add new build stage. See below.
o Change banners so that staging information is displayed.
The addition of the build-tools target broke the upgrade path because
we couldn't make use of previously built tools that were made for
compatibility reasons. Doing so would also result in the cross-compiler
being used and that is exactly what had to be avoided.
This is solved by designating the bootstrap-tools stage for building
anything that is needed for compatibility only and to create a new
stage (started after the build-tools stage) that handles cross-tools
building. We now have the following stages:
1. bootstrap-tools (for compatibility issues only)
2. build-tools
3. cross-tools (what it says)
4. world
5. install
Stages 1-4 (inclusive) are handled by buildworld.
Stage 5 is handled by installworld.
Any more stages and I'll join Nik in his quest for the
holy grail^W^Wworld :-)
|