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.
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
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
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.
"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
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.
of stuff (and thus length of error output) we put on the invocation command
line. Also follow the new FSF/GNU style of giving the symbol a value so it
can be used in `if()' statements in addition to `#if' so seldomly compiled
in code (on some platforms) gets compiled always, to help reduce bit-rot.
non-threaded programs. This provides threaded programs with the
needed exception frame symbols.
parts submitted by: Max Khon <fjoe@iclub.nsu.ru>
PR: 23252
LinuxThreads port. Dike it out as it was removed from freebsd.h on
19-July-2000 as this option depended on bits not part of the base system
and required people to install the LinuxThreads port in a manner
non-consistent with the workings of our Ports Collection.
Requested by: jasone
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.
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
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
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/
anymore as building -CURRENT sources on 3-STABLE was the reason for the
previous revision adding this.
Note that since the GCC Project moved mkstemp.c from GCC's world to
libiberty, we no longer support building -CURRENT sources on non-FreeBSD
boxes unless that box has a very simular libc mix as FreeBSD.
__FreeBSD_version < 400004.
This allows -STABLE to build -CURRENT sources.
[mkstemps() was added to -current just before the version bump to 400004
(a matter of hours in this case), so the test is as exact as possible.]
Submitted by: marcel
When I imported EGCS into contrib/egcs/ I failed to prune out
egcs/gcc/cp/hash.h which is generated from gxx.gperf. Thus `cc1plus' wasn't
using the hash.h we generated by cc/cc_tools/Makefile, but rather the one in
egcs/gcc/cp/.
When I imported contrib/gcc/ I did prune gcc/cp/hash.h. Unfortunately the
GCC maintainers weren't smart on their file nameing and there is also a
egcs/gcc/hash.h (name overloading does NOT work as well on the filesystem
as in C++...). Due to the -I ordering we are were then picking up gcc/hash.h
when compiling `cc1plus'.
Configuration header inclusion has been moved around to reduce diffs from
the offical GCC distribution. We now generate the same ``tm.h'' produced by
gcc's `configure' script [minus all the "#ifdef IN_GCC"'s].
Jeff Law of EGCS/Cygus says the new "approved" way of doing configure-related
includes is to list them all in ``tm.h'' rather than having the architure
config headers include large numbers of other configure headers.
was installed in /usr/bin normally got clobbered when objformat
was installed. Indirection through objformat is correct although
underscore handling is the only thing that differs for aout and
elf -- going through objformat is the easiest way to set c++filt's
underscore handling flag correctly.
code still applies, but the code attached to it had rotted:
# ../Makefile.inc will put an absolute path to our objdir in CFLAGS.
# Prevent mkdep from using it, so that we don't have to give rules for
# aliases of generated headers.
Many other makefiles seem to have the same bug (i.e., spelling "." as
"${.OBJDIR}" or as an even more complicated alias in -I directives).
The previous commit made things worse by breaking the -j0 case and
moving around the breakage for the -jN case. The fix involves
restoring .ORDER statements that were deleted in the previous commit,
removing wrong special handling of tree-check.h, and rewriting the
generation of fudged dependencies based on an idea I got from the
previous commit (filter out problematic objects first).
than ".so". The old extension conflicted with well-established
naming conventions for dynamically loadable modules.
The "clean" targets continue to remove ".so" files too, to deal with
old systems.
before it is installed.
This upsets Bruce because the host boostrap build forces tools to be
static anyway. He says I'm abusing NOTOOLS in src/Makefile by using
it to do a aout->elf transition build. One day I'll find a place to
install host tools like these to allow a true cross build.
name of entry points, functions, subroutines, and program to
stderr error. The enclosed patches do 3 things:
(1) Silenced the output to stderr.
(2) Added a -v option to f2c and f77. This will turn on a verbose
mode, and dumps quite a bit of stuff to stderr.
(3) Updated the f2c man page.
PR: 7369
Submitted by: Steven G. Kargl <kargl@troutmask.apl.washington.edu>
`XCC= <relative cc> -B<path to relative cc1> ...'. This is equivalent
when cc and cc1, etc. have just been bootstrapped by `make world'.
The relative versions normally won't work if the target system is
not binary compatible. Bootstrapping different versions of gcc
without going through `make world' is slightly more broken than
before.
Uniformized macro names (P1OBJS -> LIB1POBJS, etc.).
Don't give full paths to sources.
They have been bootstrapped by `make world' since long before the
hacks here were cloned from ../libgcc/Makefile. The versions just
built in "../*" normally won't work if the target system is not binary
compatible.
Don't use OBJS to defeat `make depend'; just put generated sources in
SRCS.
Added temporary files to CLEANFILES.
with `make -jN' because they did the right things to generate cexp.h
without clobbering cexp.c, and there were no missing dependencies on
cexp.h because cexp.h isn't actually used.
Fixed style bugs.
on bi-parser.h. Not having it sometimes (only with `make -j') triggered
a bug suite that led to ordinary cpp output being put in .depend files.
Various bugs (the main one only with `make -j') prevented timely detection
of failure to build and install gnu/usr.bin/cc. Eventually the missing
${WORLDTMP}/usr/libexec/cpp caused ${WORLDTMP}/usr/bin/cpp to be invoked
by cc, and this version of cpp is not suitable for such invocation.
Ordinary cpp output was put in .depend files when cpp terminated options
processing before seeing the -M flag.
Cleaned up.
target. .ORDER doesn't work right, but is used for things related
to the depend target. It "works" for the depend target by skipping
the build of .depend when N >= 2 and there is a non-default
beforedepend target with no rules. Recent fixes made almost all
the beforedepend targets in the tree a no-op except for this bug.
Removed vestiges of elf and aout targets.
a.out gas and the binutils gas (elf or a.out) with a single compiler.
This uses other infrastructure not yet committed, in order to support
both a.out and elf it needs to be able to get to both a.out and elf
gas, ld, libs, crt* etc. So for now, the support is pretty much dormant.
The new freebsd.h file is based on the old freebsd-elf.h file (which has a
long lineage, right back through linux and svr4 files). The change is
pretty dramatic from a gcc internals standpoint as it overrides a lot of
definitions in order to generate different output based on target mode.
There is potential for screw-ups, so please be on the lookout - gcc's
configuration mechanism wasn't really meant for this kind of thing.
It's believed to compile world etc just fine under both a.out and elf, can
handle global constructors and destructors, handles the differences in
a.out and elf stabs, and what sections things like exceptions go in.
The initial idea came from i386/osfrose.h which is a dual rose/elf format
target. These two are not as diverse as a.out and elf it would seem.
The cc front-end uses external configuration to determine default object
format (still being thrashed out, so read the source if you want to see
it so far), and has a '-aout' and '-elf' override command line switch.
There are some other internal switches that can be accessed, namely -maout,
-mno-aout, -munderscores and -mnounderscores. The underscore and local
symbol prefixing rules are controllable seperately to the output format.
(ie: it's possible to generate a.out without the _ prefixes on symbols and
also to generate elf with the _ prefixes. This isn't quite optimal, but
does seem to work pretty well, except the linkers don't always recognise
the local symbols without their normal names)
The default format is a.out (still), nobody should see any major changes.
With both elf and a.out tools and libraries installed:
[1:26pm]/tmp-223> cc -elf -o hello hello.c
peter@beast[1:27pm]/tmp-224> file hello
hello: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped
[1:27pm]/tmp-225> ./hello
hello world!
[1:27pm]/tmp-226> cc -aout -o hello hello.c
[1:27pm]/tmp-227> file hello
hello: FreeBSD/i386 compact demand paged dynamically linked executable not stripped
1:27pm]/tmp-228> ./hello
hello world!
Since my co-conspirators put a lot of effort into this too, I'll add them
so they can share the blame^H^H^H^H^Hglory. :-)
Reviewed by: sos, jdp
objects depend on all generated headers doesn't work because it gives
cyclic dependencies. Give enough dependencies explicitly. We no
longer need to use .SINGLESHELL for `make depend'. .SINGLESHELL was
more of a bottleneck than usual because `make depend' makes everything.
Fixed some spelling and English errors.
machine independent, with the only dependency being the binary format
to build. We only expect to build ELF on alpha although we'll need
ECOFF compatibility with Digital Unix.
