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
