with Brian's kernel support for i386 debug registers. This makes
watchpoints actually usable for real-life problems. Note: you can
only set watchpoints on 1-, 2- or 4-byte locations, gdb automatically
falls back to [sloooow] software watchpoints when attempting to use
them on variables which don't fit into this category. To circumvent
this, one can use the following hack:
watch *(int *)0x<some address>
David O'Brien is IMHO considering to get this fully integrated into the
official GDB, but as long as we've got the i386/* files sitting around
in our private FreeBSD tree here, the feature can now be tested more
extensively, so i'm committing this for the time being.
This work has been done in order to debug a tix toolkit problem, thus
it has been sponsored by teh Deutsche Post AG.
Reviewed by: bsd (not the operating system, but Brian :-)
ENABLE_SUIDPERL is set to true. When perl is updated to remove the
fork mail code, additional warnings will enable the users to know what
is gonig on and how to correct it. Markm will make those commits as
part of his perl patch integration. suidperl is installed with
execute permissions so that markm's added error messages wil be seen
by the user.
Previously, using -S/--skip, -f/--force, or -t/--batch to skip a patch in
a patchset still registers a failure which causes patch to return a
non-zero exit code. This is particularly undesirable with regards to
ports as there is no way to ignore the non-zero code. (Luckily, we don't
currently have any ports that make use of any of these options.)
The PR (yes, my own) is slightly incorrect: It states that -f does indeed
properly skip patches. It does, but it still sets the failure flag causing
patch to return non-zero.
PR: 19638
Submitted by: kbyanc@posi.net
1) (Biggest) I tried long-and-hard to keep the version number (5.006)
backwards compatible with FreeBSD; I have lost this battle, and
must defer to the Perl convention (5.6.0). Victims include suidperl.
this means that dirs with a name of 5.006 will be replaced with
dirs named 5.6.0 in both /usr/libdata/perl and /usr/local/lib/perl.
2) Errno module is added.
3) Alpha bits extensively tweeked after a Beast-build.
Other commits to follow.
where it is used. c-decl has symbols that conflict with several of the
cc1plus sources.
GNU `ld' was changed in Dec 1999 to be more be compatable with the way that
other linkers work (specifically in the Solaris linker). The 2.9.1 `ld',
did the Wrong Thing in that if a library contained a common symbol that
matched a definition of that symbol in another (already linked in object)
it would also be linked in, even if there was no other reason to do so.
This is wrong. The library should only be linked in if it contains
non-common, non-weak symbols which are needed by previously linked in
objects.
Don't use MANDEPEND. It hasn't had anything to do with dependencies for
5-6 years, but is still being used, mainly in groff/*/Makefile, where it
amounts to just a macro giving the list of generated man pages. Since
all man pages in groff are generated (from .man to .[1-9]), it's simpler
to use the source names ({$MANX}) to give the list.
Fixed some other style bugs.
branch. Although this problem has been reported to the GNU folks,
it's unlikely that any solution they may come up with will involve
the use of mktemp(1).
PR: 16942
Submitted by: Colin Phipps <crp22@cam.ac.uk>
Fixed wrong path to libperl in LDADD in some funky objdir setups.
Use ${dir}/libfoo.a instead of -L${dir} -lfoo for local static libraries
in LDADD so that `make checkdpadd' doesn't report non-errors.
Fixed misformatting of $FreeBSD$.
libraries in LDADD so that `make checkdpadd' doesn't report non-errors.
Fixed some style bugs (the usual ones for DPADD and LDADD, and misformatting
of $FreeBSD$).
fixes the way that third-party apps like apache link in perl .so's
(and previously did not get libperl linked in.)
NOTE - you neeed to recompile all your perl stuff - all the p5-*
por4ts with C code, and things like mod_perl.
in rev.1.44 (the egcs to gcc switch). The problem is that print-rtl.o
is now needed to build some tools, but it wasn't added to the list of
objects which are specially handled because they are prerequisites for
tools."
Submitted by: bde
as is documented in the man page. Retain the older mistaken version
of the flag for backwards compatibility in case anybody is using it.
Add $FreeBSD$ tag as cvs requires it.
PR: gnu/7800
build-tools target and by the actual target. In a cross-building situation
proj.o is both a native object and a cross-object (i.e., for the target
arch) and thus doesn't work. Creating seperate opjects from the same
source file solves this...
This patch may also fix the following issue:
> it looks like -DNOCLEAN doesn't work too well.
> cd /usr/src/gnu/usr.bin/cc/f771; make build-tools
> make: don't know how to make /usr/obj/usr/src/i386/usr/include/stdarg.h. Stop
This seems caused by wrong dependency information. Dependency
information shouldn't be created for build-tools sources.
Submitted by: marcel
This is a new feature of groff and is a html driver for groff.
From the manual page:
"grohtml translates the output of GNU troff to html."
This is very interesting for people working on documentation.
* Remove "why we need this decl..." comment. The `matcher' variable
is defined in *grepmat.c files in the original distribution, which
we did not import.
It is being re-imported here, to keep our long source change history with
this source continuous.
src/contrib/grep will be deleted some time in the very near future.
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)
of changing the search dirs. This also removes an used search dir,
removes unneeded redundancy, and a bugus dir we enherited on the i386
by baseing off of svr4.h.
We went from:
install: /usr/libexec/(null)
programs: /usr/libexec/<OBJFORMAT>/:/usr/libexec/:/usr/bin/:/usr/libexec/
libraries: /usr/libdata/gcc/:/usr/libexec/:/usr/ccs/lib/:/usr/lib/
to:
install: /usr/libexec/(null)
programs: /usr/libexec/<OBJFORMAT>/:/usr/libexec/
libraries: /usr/libexec/:/usr/lib/
happened as it was working around problems elsewhere (ie: binutils/ld
not doing the right thing according to the ELF design). libcrypt has
been adjusted to not need the runtime -lmd. It's still not quite right
(ld is supposed to work damnit) but at least it doesn't impact all the
users of libcrypt in Marcel's cross-build model.
The target machine is represented by TARGET_ARCH. MACHINE_ARCH always
represents the host machine. When TARGET_ARCH is not defined, it is
assumed to be equal to MACHINE_ARCH. This means that we're building a
native toolset by default. We're creating cross-compilation tools when
MACHINE_ARCH != TARGET_ARCH.
TARGET_ARCH is defined when building binutils as part of the bootstrap
build and is set to reflect the architecture we're currently cross-
building. With this change binutils is ready for cross-building.
