1
0
mirror of https://git.FreeBSD.org/src.git synced 2024-12-22 11:17:19 +00:00
Commit Graph

293 Commits

Author SHA1 Message Date
David E. O'Brien
5a87307b7f Use a more API denoting way to handle what is in libc and what isn't. 2002-05-18 04:49:44 +00:00
David E. O'Brien
00900fed40 Don't depend on gperf. 2002-05-18 00:18:00 +00:00
David E. O'Brien
9c2a81d5ba Remove some WIP bits that I didn't fully clean out before merging to HEAD. 2002-05-17 06:35:44 +00:00
Ruslan Ermilov
a43171c248 Back out revision 1.30 change.
cc1plus can apparently be built if you happen to have
/usr/bin/gperf, or set CXX to point to a C++ compiler
that can build gperf(1) in the bootstrap-tools stage
of buildworld.
2002-05-17 05:41:47 +00:00
David E. O'Brien
cffafa9e12 Do not cut `docs' out of the build with NO_CXX.
There are no longer GNU C++ specific info files, and it was a bug with Gcc
2.95 that NO_CXX would cause the C and CPP info files to not be installed.
2002-05-17 03:00:33 +00:00
Ruslan Ermilov
35abacef2a MD_EXEC_PREFIX doesn't work for the cross-arch compiler.
The change also makes the `cc -print-search-dirs' output
sane (the pre-3.1 way) in the non-cross case.

Draft reviewed by:	obrien
2002-05-16 15:22:58 +00:00
Ruslan Ermilov
2898afe627 Make it possible to build a cross compiler for alpha,
ia64 and sparc64 on systems that do not have atoll(3).
The "cross" here doesn't necessarily mean cross-arch.
2002-05-16 15:18:13 +00:00
David E. O'Brien
fcbdc1f8a0 Add x86-64 bits. 2002-05-15 22:40:50 +00:00
David E. O'Brien
23735e10dd The IA-64 config needs to know that we are using GNU ld & as.
Submitted by:	peter
2002-05-15 21:59:46 +00:00
Ruslan Ermilov
83f56d9ae4 Make sure to not yet build the GNU C++, but still allow
for the C++ progs to be built with e.g. an old compiler,
CXX=/usr/bin/c++, for the time being.
2002-05-15 16:29:45 +00:00
Ruslan Ermilov
423e9124d9 Mark all internal libraries with INTERNALLIB. 2002-05-13 11:24:03 +00:00
David E. O'Brien
6677f3e022 Restore some of the implementation from the Bmake gcc 2.95 bits.
In the end, I can do things more like the previous Bmake bits than was
apparent in the middle of the gcc31 WIP.
2002-05-13 03:27:03 +00:00
David E. O'Brien
5b3bcd0c77 I was finally able to repeat the -j breakage on one of my machines. Fix it.
I borrowed some ideas from Ruslan, and made the style match cc_tools/Makefile
2002-05-13 01:54:26 +00:00
David E. O'Brien
a0eb22834d Tidy up the cleanfiles. 2002-05-12 12:06:19 +00:00
David E. O'Brien
79c021244b Fixes for building a.out bits.
Submitted by:	bde
2002-05-12 12:01:12 +00:00
David E. O'Brien
c00b947e3f Sorry, I did not mean to turn collect2 back on yet. 2002-05-11 04:51:45 +00:00
David E. O'Brien
b42da20fd5 Revert rev 1.3 -- I tested using the wrong build compiler. 2002-05-11 00:15:45 +00:00
David E. O'Brien
943aada83d Actually we don't need any special YACC'ing here. The ones known to
Bmake are fine.
2002-05-10 23:20:54 +00:00
David E. O'Brien
d147c3da04 Touching the sjlj setting on IA-64 makes things not build.
Submitted by:	peter
2002-05-10 17:42:19 +00:00
David E. O'Brien
871d3affa7 Doh! Add IA-64 to our target list. 2002-05-10 17:23:04 +00:00
David E. O'Brien
415f2bb46f Gather up the stragglers that depends on genrtl.h. This is -j10 safe now. 2002-05-10 10:21:19 +00:00
David E. O'Brien
01c50f1782 This was *very* -j unsafe. Add a dependency on the common generated
headers to mostly make it -j1 safe.
2002-05-10 10:14:53 +00:00
David E. O'Brien
3cdd876f04 Bmake bits for Gcc 3.1.
Partially made possible by:	Wilko.Bulte@compaq.com
2002-05-10 08:54:50 +00:00
David E. O'Brien
7b4716843d Use MD_EXEC_PREFIX now to get us thru `buildworld'.
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.
2002-05-10 08:41:46 +00:00
David E. O'Brien
066003a540 Gcc 3.1 now offers both a C99 and a K&R traditional C preprocessor.
This is the ISO C99 one.
2002-05-10 02:46:01 +00:00
David E. O'Brien
dd7731cf37 Bmake bits for GCC 3.1. 2002-05-10 02:36:12 +00:00
cvs2svn
ff24f7832c This commit was manufactured by cvs2svn to create branch 'WIP_GCC31'. 2002-05-09 00:52:10 +00:00
David E. O'Brien
354b719bf7 Gcc 3.1 now offers both a C99 and a K&R traditional C preprocessor.
This is the traditional one.
2002-05-09 00:52:09 +00:00
David E. O'Brien
b9b736e422 Using ${.ALLSRC} here is dangerious as it sometimes picks up more
"sources" than desired.
2002-05-08 02:46:10 +00:00
David E. O'Brien
672528fa3d Make the YACC'ing more bullet proof. 2002-05-07 01:41:46 +00:00
David E. O'Brien
baef823236 The GCC target name does not always match our platform's name.
MFC: rev 1.61 (needed a different way to keep from multiple inclusion)
2002-05-07 01:26:58 +00:00
David E. O'Brien
66ecbefa3d The HAVE_AS_GOTOFF_IN_DATA definition needs to depend on obj format. 2002-05-07 01:19:56 +00:00
David E. O'Brien
a5cc86f163 Add support for using the profiled versions of the C++ (and related) libs. 2002-05-01 19:19:22 +00:00
David E. O'Brien
e5ccba11ac Don't use "GCCDIR" as the multiple inclusion protector. Subdir Makefiles
may want to override GCCDIR and this gets in the way.
2002-04-23 00:10:18 +00:00
David E. O'Brien
9d838dbb47 Remove the #ifdef IN_GCC junk. We *know* we are building GCC with these
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.
2002-04-15 03:41:47 +00:00
David E. O'Brien
d99ab028e5 Note that HAVE_GAS_SHF_MERGE is a new feature, and it can be surprising if
one does not know about it.

Experienced by:	peter
2002-04-15 03:39:20 +00:00
David E. O'Brien
d6c4eef6dd Turn off collect2.
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
2002-04-15 03:15:40 +00:00
David E. O'Brien
8089148b52 In the cross case we need to provide TARGET_MACHINE. 2002-04-11 18:40:37 +00:00
David E. O'Brien
8f5dad4aa0 Update infodoc building for GCC 3.1. 2002-04-11 02:56:30 +00:00
David E. O'Brien
cb2a59bc57 In the cross case we need to provide TARGET_MACHINE. 2002-04-10 02:20:48 +00:00
David E. O'Brien
e228f1da77 Change YACCing.
Submited by:	ru
2002-04-10 01:48:47 +00:00
David E. O'Brien
9833f59b8c Fine! I cannot freaking take the bikeshed any more.
These binaries will be static, peroid.
2002-04-08 18:48:38 +00:00
David E. O'Brien
bf4990bb76 Fix search path. 2002-04-07 08:05:33 +00:00
David E. O'Brien
9e3b001017 Bmake bits for GCC 3.1. 2002-04-06 23:18:01 +00:00
cvs2svn
4e6aeb72b4 This commit was manufactured by cvs2svn to create branch 'WIP_GCC31'. 2002-04-06 23:16:27 +00:00
David E. O'Brien
f99189726f Break some things used by the front-ends from Makefile.inc that cannot
be used build-wide for GCC 3.1.
2002-04-06 23:16:26 +00:00
David E. O'Brien
dbb66afa0b Build and install collect2. This is needed for some C++ programs. 2002-04-06 23:12:46 +00:00
David E. O'Brien
cf5eb7bb89 Break some things out of Makefile.inc that cannot be used build-wide
for GCC 3.1.
2002-04-06 22:37:19 +00:00
David E. O'Brien
a5cf1da8f8 Expand the toolchain a little bit.
Requested by:	fjoe (collect2), des (protoize)
2002-04-06 09:35:06 +00:00
David E. O'Brien
bb5545c63e Tell GCC 3.1 our capibilities. 2002-04-05 12:14:36 +00:00