#
256281 |
|
10-Oct-2013 |
gjb |
Copy head (r256279) to stable/10 as part of the 10.0-RELEASE cycle.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation |
#
245311 |
|
11-Jan-2013 |
brooks |
Add pwcache(3) and vis(3) to libegacy as install(1) is about to grow a dependency on them.
Sponsored by: DARPA, AFRL
|
#
240377 |
|
11-Sep-2012 |
obrien |
r235638 is not the clean way to add support for building on ancient FreeBSD versions. Instead use Imp's good work on "legacy" and follow the outcome of the previous TRB discussions on this topic.
Now use the libc getline() if it exists, and only where it doesn't create a bootstraping version.
|
#
227636 |
|
17-Nov-2011 |
dim |
Revert r227538, since it doesn't compile with clang at all (it doesn't allow the built-in operations to be redefined, at least not without excessive force).
Instead, just disable LLVM's support for atomic operations for now. Nothing in either clang or the tablegen tools currently depends on it.
This still allows users of head built before r198344 to upgrade to top-of-head seamlessly.
|
#
227538 |
|
15-Nov-2011 |
dim |
LLVM uses atomic operations, which are not supported on i386 and GCC emits calls for them, rather than expanding them inline. Older FreeBSD versions compile for i386 by default and as such we end up with unresolved symbols when we build LLVM's TableGen utility as a build tool on them. Add the functions that GCC emits here, but don't bother to make them atomic. Such is not needed.
Submitted by: marcel MFC after: 1 week
|
#
175539 |
|
21-Jan-2008 |
obrien |
Remove 5.x and 6.x cruft - source upgrades to RELENG_8 from versions prior to RELENG_7 are not supported.
|
#
146261 |
|
16-May-2005 |
ru |
Make <runefile.h> internal to libc.
Suggested by: phantom
|
#
143044 |
|
02-Mar-2005 |
ru |
Add hacks that I use to test cross-builds (by building on native and foreign architectures and comparing products). They eliminate most of the differences caused by different object directory paths, timestamping, and identification.
(Note WORLDTMP was renamed to ${OBJTREE}${.CURDIR}/tmp.)
|
#
142683 |
|
27-Feb-2005 |
ru |
Bootstrap gencat(1).
OK'ed by: phantom
|
#
142640 |
|
27-Feb-2005 |
ru |
As threatened, drop support for source upgrades from pre-5.3.
Inspired by: obrien
|
#
142582 |
|
26-Feb-2005 |
ru |
Make the format of LC_CTYPE files architecture independent by introducing the disk formats for _RuneLocale and friends.
The disk formats do not have (useless) pointers and have 32-bit quantities instead of rune_t and long. (htonl(3) only works with 32-bit quantities, so there's no loss).
Bootstrap mklocale(1) when necessary. (Bootstrapping from 4.x would be trivial (verified), but we no longer provide pre-5.3 source upgrades and this is the first commit to actually break it.)
|
#
126451 |
|
01-Mar-2004 |
ru |
Removed extraneous parentheses.
|
#
126344 |
|
28-Feb-2004 |
ache |
Add getopt_long.c if ${BOOTSTRAPPING} < 502104
|
#
126039 |
|
20-Feb-2004 |
ru |
Unbreak the upgrade path from 4.9 after removal of GNU getopt and <gnuregex.h>.
|
#
113508 |
|
15-Apr-2003 |
ru |
A version of <sys/endian.h> in RELENG_4 doesn't have 64-bit functions.
Spotted by: simokawa
|
#
113368 |
|
11-Apr-2003 |
ru |
libc_gen/basename.c depends on include/libgen.h.
|
#
113185 |
|
06-Apr-2003 |
imp |
-legacy and /.../legacy/... looks better than build or bootstrap in the logs, so use that instead.
Submitted by: obrien.
|
#
113136 |
|
05-Apr-2003 |
imp |
Migrate to a new way of dealing with building from old revisions of 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.
|