The problem is the GCC driver now turns STANDARD_EXEC_PREFIX into a relative
path -- "<basename argv[0]>/../../libexec" for our normal install location.
However, in the middle of `buildworld' we need
"<basename argv[0]>/../../../../libexec" due to the prefix we tell the GCC
driver. But either the GCC driver is buggy, or we are confusing it, as it
tries to exec "<basename argv[0]>/../../libexec/cpp0" as if it were installed
in the normal place (but isn't).
MD_EXEC_PREFIX is still absolute, so I'll use that for now. I would like to
later make it so MD_EXEC_PREFIX is set only for `buildworld', as
MD_EXEC_PREFIX is also in the search path for libraries. Don't ask me why!
Another way is to add ${OBJFORMAT_PATH} (as set in CROSSENV) to the PATH
in src/Makefile.inc's WMAKEENV.
our patch to look a little more like NetBSD's, and has the nice characteristic
that the object code is exactly the same after the change as before it (even in
patch.c and pch.c, which have pesky 'assert' statements in them).
Reviewed by: /sbin/md5 on i386, alpha, sparc64
MFC after: 3 days
\ No newline at end of file
line that some versions of diff print out if the last line of the two files
are different, and one of the two files does not have a newline character
on that last line.
This change is still somewhat under discussion in -arch and -standards, but I
want to commit it to -current today so I'd have the chance to MFC it to -stable
before the code freeze for 4.6-release (which would be May 1st).
Note: the related change to 'diff' (so it might *generate* that line) is NOT
expected to be included in 4.6-release. We can debate that change later.
Obtained from: NetBSD (1.13 of basesrc/usr.bin/patch/pch.c, by kristerw)
MFC after: 4 days
Do not install games and profiled libraries to the ${CHROOTDIR}
with the initial installworld.
Eliminate the need in the second installworld. For that, make sure
_everything_ is built in the "world" environment, using the right
tool chain.
Added SUBDIR_OVERRIDE helper stuff to Makefile.inc1. Split the
buildworld process into stages, and skip some stages when
SUBDIR_OVERRIDE is set (used to build crypto, krb4, and krb5
dists).
Added NO_MAKEDB_RUN knob to Makefile.inc1 to avoid running
makewhatis(1) at the end of installworld (used when making crypto,
krb4, and krb5 dists).
In release/scripts/doFS.sh, ensure that the correct boot blocks are
used.
Moved the creation of the "crypto" dist from release.5 to
release.2.
In release.3 and doMFSKERN, build kernels in the "world"
environment. KERNELS now means "additional" kernels, GENERIC is
always built.
Ensure we build crunched binaries in the "world" environment.
Obfuscate release/Makefile some more (WMAKEENV) to achieve this.
Inline createBOOTMFS target.
Use already built GENERIC kernel modules to augment mfsfd's
/stand/modules. GC doMODULES as such.
Assorted fixes:
Get rid of the "afterdistribute" target by moving the single use
of it from sys/Makefile to etc/Makefile's "distribute".
Makefile.inc1: apparently "etc" no longer needs to be last for
"distribute" to succeed.
gnu/usr.bin/perl/library/Makefile.inc: do not override the
"install" and "distribute" targets, do it the "canonical" way.
release/scripts/{man,cat}pages-make.sh: make sure Perl manpages and
catpages appear in the right dists. Note that because Perl does
not respect the MANBUILDCAT (and NOMAN), this results in a loss of
/usr/share/perl/man/cat* empty directories. This will be fixed
soon.
Turn MAKE_KERBEROS4 into a plain boolean variable (if it is set it
means "make KerberosIV"), as documented in the make.conf(5)
manpage. Most of the userland makefiles did not test it for "YES"
anyway.
XXX Should specialized kerberized libpam versions be included into
the krb4 and krb5 dists? (libpam.a would be incorrect anyway if
both krb4 and krb5 dists were choosen.)
Make sure "games" dist is made before "catpages", otherwise games
catpages settle in the wrong dist.
Fast build machine provided by: Igor Kucherenko <kivvy@sunbay.com>
bits. Also remove comment about keeping in sync with other instances in
the source tree -- it was too easy to get out of sync, so the other
instances now use this instance.
collect2 was added based on the need of -frepo. However, -frepo is currently
broken on -CURRENT (Gcc 2.95.4 20020320 [FreeBSD] / ld 2.12.0 [FreeBSD]
2002-04-10). It is also broken on RELENG_4 (Gcc 2.95.3 20010315 / ld
2.11.2 20010719), so there is no need to MFC collect2 there yet. I have
a feeling the brokeness is due to the wide difference between the libiberty
bits of Gcc 2.95 and the later ld.
Testing by: fjoe
compiled with gcc-3.1. Somebody thought it was a good idea to move
the implementation of new and delete from libgcc to libstdc++. This
change doesn't harm the current compiler in the tree.
sized integer' bites. The various malloc functions return pointers,
but without any prototype/declarations visible to callers, the compiler
expects them to return int.
Correct backtrace was made more complex when the new signal trampoline
was introduced to support more than 32 signals, while keeping a modified
version of the old signal trampoline.
The 'where' command will now show:
#2 <signal handler called>
where appropiate.
Submitted by: Tor.Egge@fast.no
manpages in machine-specific subdirectories (like man4/i386/) to
"../". This change didn't propagate here resulting in a loss of
whatis(1) database entries. Fix this.
Reviewed by: tobez
MFC after: 1 week
Rev 1.2 changed the default emulation from ``elf64_sparc'' to ``elf32_sparc''
and I never noticed it after my review of rev 1.1. Backing the change of
the default emulation out, and Wa-la!, I can now build a native [and usable]
binutils. WTF, the "-m elf64_sparc" parameter handed to `ld' by `gcc'
wasn't DTRT is beyond me.
about 'STANDARD_EXEC_PREFIX'. It is used now and is needed if one does not
set 'MD_EXEC_PREFIX'.
Do not define a 'MD_EXEC_PREFIX'. It is not needed, not used in the
cross case, and just ends up causing "/usr/libexec" being added to the
library search path.
compiler.
* Undo the diking out of cross compiler logic from gcc.c rev 1.16.
* Add the `CROSS_STARTFILE_PREFIX' knob.
* Add our own definition of `STANDARD_INCLUDE_DIR'. This should have been
included in freebsd-native.h rev 1.5.
I am committing this here rather than in gcc/config/freebsd.h because the
profiled libgcc only exists with the native system compiler. It is not
created by a stock FSF build and we will never be able to get these bits
committed to the FSF CVS repo. Thus this is very much a FreeBSD "native"
issue.
compiler.
* Undo the diking out of cross compiler logic from gcc.c rev 1.16.
* Add the `CROSS_STARTFILE_PREFIX' knob.
* Add our own definition of `STANDARD_INCLUDE_DIR'. This should have been
included in freebsd-native.h rev 1.5.
* Minimize a little bit more, things we dike out in the FREEBSD_NATIVE case.
Submitted by: ru & obrien
cross case, and just ends up causing "/usr/libexec" being added to the
library search path.
Also remove misleading comment about 'STANDARD_EXEC_PREFIX'. It is needed
if one does not set 'MD_EXEC_PREFIX'.
Submitted by: ru
- point at the FDP article rather than GNU's send-pr documentation
- warn the user that PRs are public information and will be published in
mailing lists and on the web
- suggest that the user contact security-officer@ directly if the report
concerns sensitive security issues.
This backs out (sort of) delta 1.18 to perl/miniperl/Makefile.
Update to the ld(1) comment by peter in this revision:
ld(1) built as part of the cross-tools stage of buildworld has
been fixed to look for dynamic dependencies in the right place,
${WORLDTMP}/usr/lib, effective binutils/ld/Makefile,v 1.20.
Approved by: markm
Presumably the issue was with arparse.[ch]. Those are now in FREEBSD-Xlist
and FREEBSD-deletelist. So we do not import the Bison produced files that
was causing the problem.
Submitted by: ru
(the two may be different (ie, build vs. runtime))
Allow ldscript's SEARCH_DIR do be rooted somewhere other than `/'.
(in this case at TOOLS_PREFIX)
These changes are most helpful during `make buildworld' so that the shared
libs built in the middle of `make buildworld' are used vs. the ones in
/usr/lib on the build machine.
Submitted by: ru
The code will be fixed for all known security vulnerabilities,
and a make.conf(5) knob (ENABLE_SUID_MAN) will be provided for
those who still want it installed setuid for whatever reasons.
The catpaging and setuidness features of man(1) combined make
it vulnerable to a number of security attacks. Specifically,
it was possible to overwrite system catpages with arbitrarily
contents by either setting up a symlink to a directory holding
system catpages, or by writing custom -mdoc or -man groff(1)
macro packages and setting up GROFF_TMAC_PATH in environment
to point to them. (See PR below for details).
This means man(1) can no longer create system catpages on a
regular user's behalf. (It is still able to if the user has
write permissions to the directory holding catpages, e.g.,
user's own manpages, or if the running user is ``root''.)
To create and install catpages during ``make world'', please
set MANBUILDCAT=YES in /etc/make.conf. To rebuild catpages
on a weekly basis, please set weekly_catman_enable="YES" in
/etc/periodic.conf.
PR: bin/32791
back (as of man.c,v 1.45), change the meaning of the -m option
from poorly documented and badly coded "alternate system" to a
much more useful "different architecture for the same system".
PR: docs/31261
It is here in case we decide we want the directory to match the binary name
since neither the binary nor the source file(s) are named 'cccp' any longer.
Really irritating changes are the "forced" layering of malloc + friends
in order to use the GNU versions. Sorry, we have a *very* fine malloc,
and we will use it. Period. Even more irritating is that the GNU people
now want to replace ctype also!! So we partially dike it out here.
We now have to use the GCC stdarg.h varargs.h. We simply have no choice
as it has an internal representation that we really cannot properly define
in our headers.
This thing grew. We now have to link with many more files as if it
were one of the driver programs. We also have to deal with the very
irritating layering of malloc and friends. Our malloc works *very*
well thank you. Thus we will use it.
We now fake out the native libgcc.mk + GNU autoconf'ed Makefile.
This gives us the flexability we will need to support our new arches
(StrongARM, Sparc64, PowerPC, and IA-64). If this new way proves to
be too much a hassle, I still have a close-to-being-finished version
that is more like the 2.95 version of this file.
bsd.obj.mk -> bsd.prog.mk in modules makefiles, as the
latter automatically includes ../Makefile.inc and adds
-I${DESTDIR}/usr/include to ${CFLAGS} needed for "make
world" which is built with -nostdinc.
Reviewed by: MAINTAINER timeout
code in ipl.s and icu_ipl.s that used them was removed when the
interrupt thread system was committed. Debuggers also knew about
Xresume* because these labels hide the real names of the interrupt
handlers (Xintr*), and debuggers need to special-case interrupt
handlers to get the interrupt frame.
Both gdb and ddb will now use the Xintr* and Xfastintr* symbols to
detect interrupt frames. Fast interrupt frames were never identified
correctly before, so this fixes the problem of the running stack
frame getting lost in a ddb or gdb trace generated from a fast
interrupt - e.g. when debugging a simple infinite loop in the kernel
using a serial console, the frame containing the loop would never
appear in a gdb or ddb trace.
Reviewed by: jhb, bde
1. To cross-build, one now needs to set TARGET_ARCH, and not the
MACHINE_ARCH. MACHINE_ARCH should never be changed manually!
2. Initialize DESTDIR= explicitly for bootstrap-tools, build-tools,
and cross-tools stages. This fixes broken header and library
dependencies problem. We build them in the host environment,
and obviously want them to depend on host headers and libraries.
The problem with broken header dependencies for bootstrap-tools
and cross-tools was already partially solved (see BOOTSTRAPPING
tests in bsd.prog.mk and bsd.lib.mk), but it was still there for
build-tools if the user ran "make world DESTDIR=/foo". Also,
for all of these stages, the library dependencies were broken
because of how bsd.libnames.mk define DPADD members.
We still provide a glue to install bootstrap- and cross-tools
under the ${WORLDTMP}.
Removed PATH overrides for bootstrap-, build-, and cross-tools
stages. There is just no reason why we would need to override
it, and the hacks to clean up the ${WORLDTMP} in the -DNOCLEAN
case are no longer needed with fixes from this step.
That is, we now never use ${WORLDTMP} headers and libraries,
and we don't use any ${WORLDTMP} installed binaries during
these stages. Again, these stages depend solely on the host
environment, including compiler, headers, and libraries.
3. Moved "miniperl" back from cross-tools (it has nothing to do
with a cross-compiler) to build-tools where it belongs. The
change from step 1 let to do this. Also, to make this work,
build-tools targets of "cc_tools" and "miniperl" were modified
to call "depend". Here follow the detailed explanations.
There are two categories of build tools, for now. In the first
category there are "cc_tools" and "miniperl". They occupy the
whole (sub)directory, and nothing needs to be done in this
subdirectory later during the "all" stage. They are also
constructed using system makefiles. We must build the .depend
early in the build-tools stage because:
1) They use (and depend on) the host environment.
2) If we don't do this in build-tools, the "depend" stage of
buildworld will do this for us; wrong library and header
dependencies will be recorded (DESTDIR=${WORLDTMP}) and,
what's worse, the "all" stage may then clobber the
build-architecture format tools (that we built in the
build-tools stage) with the target-architecture format
ones, breaking cross build.
In the second category there are all other build-tools. They
share their directory with the "main" module that needs them
in the "all" stage, and they don't show up themselves in the
.depend file. The portion of this fix was already committed
in gnu/usr.bin/cc/cc_tools/Makefile,v 1.52.
4. "libperl" is no longer a build tool, and "miniperl" is the
stand-alone application. I had to make this change because
build-tools and "all" stages share the same object directory.
Without this change, if we cross compile, libperl.a is first
built for the build architecture during the build-tools stage
(for the purposes of immediate linkage with "miniperl").
Later on, the "all" stage sees this library as up-to-date,
and doesn't rebuild it. The effect is that the wrong format
static libperl library is installed with installworld.
5. Fixed "includes" to install secure/lib/libtelnet headers if
required.
Reviewed by: bde
"build-tools". If we do not do this, the "depend" stage of
"buildworld" will build ``.depend'' and it will record the wrong
library and header dependencies (DESTDIR=${WORLDTMP}). Even worse,
the "all" stage may clobber build-architecture-format build tools
built in the "build-tools" stage with target-architecture-format ones.
Submitted by: ru
are linking against does not have basename(). There is a buffer overflow
bug in lib/libc/gen/basename.c rev 1.1. There is no way for us to test
what revision of basename() we have in libc, thus this change.
Requested by: ru
misuse of /usr/src/include headers. This REALLY fixes
the 20010919 src/UPDATING entry.
With this patch the 4.2-RELEASE box was able to survive
the 5.0-CURRENT "make world".
Beat over the head with this patch: obrien
The version of the kernel has no bearing on what is in libc.
We now search for basename in libc to determin if we need to include
the libiberty version in the build.
This is all still a bit bogus as it will (like the sysctl method) cause
basename.o to be linked into the cross-build as well as the host build. It
would probably be better to test if we were doing the initial host build and
unconditionally include that. Once we've generated the target libc we know
that basename is available. (maybe test for $TOOLS_PREFIX or something).
Submitted by: peter
Note ALL MODULES MUST BE RECOMPILED
make the kernel aware that there are smaller units of scheduling than the
process. (but only allow one thread per process at this time).
This is functionally equivalent to teh previousl -current except
that there is a thread associated with each process.
Sorry john! (your next MFC will be a doosie!)
Reviewed by: peter@freebsd.org, dillon@freebsd.org
X-MFC after: ha ha ha ha
paths are chflaged 'schg' to prevent exploit vectors when run
by cron, by a root user, or by a user other then the one owning the
binary. This applies to most of the uucp binaries, cu, tip, and
man (man was already installed properly).
MFC will occur when approved.
value, it forces GCC to not optimize above this level. For intance, GCC
made with "WANT_FORCE_OPTIMIZATION_DOWNGRADE=1" is a good setting for the
Alpha platform when building ports.
This makes the following difference:
-groff_mdoc(7), -(7) - groff_mdoc reference for groff's mdoc implementation
+groff_mdoc(7) - reference for groff's mdoc implementation
empty line by troff(1) and is ignored. Teach makewhatis(1)
about this. This makes the following difference:
-groff_man(7), . groff_man(7) - groff `man' macros to support generation of man pages
+groff_man(7) - groff `man' macros to support generation of man pages
-groff_mdoc(7), -(7) - . groff_mdoc reference for groff's mdoc implementation
+groff_mdoc(7), -(7) - groff_mdoc reference for groff's mdoc implementation
-troff(1), . . troff(1) - format documents
+troff(1) - format documents
Noticed by: yar
