d/freebsd-dev
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
87,956 Commits 72 Branches 135 Tags 3.2 GiB
a4d7a3c069
Commit Graph

312 Commits

Author SHA1 Message Date
Ruslan Ermilov
2587947187 Install the gcov(1) manpage; kernbb(8) references it. 2003-02-24 22:58:19 +00:00
David E. O'Brien
685272c479 Gperf is usable again. 2002-12-04 17:34:21 +00:00
David E. O'Brien
f685377c2e Remove our custom mixed ELF/a.out support. This means the base compiler 
now only produce ELF objects.  It also makes us closer to stock GCC, and
simplifies the set of changes we still need from stock GCC on every import.

Applauded by:	peter
Approved by:	re
 2002-11-26 18:25:20 +00:00
Ruslan Ermilov
4192cfffe2 Bootstrapping aid for 4.0-RELEASE. 2002-11-13 11:50:40 +00:00
David E. O'Brien
837bd2fa82 Better emulate the FSF build for Sparc64. 2002-11-06 07:00:59 +00:00
David E. O'Brien
597e16e012 We HAVE_STPCPY now. 2002-10-20 07:50:20 +00:00
Alexander Kabaev
9734ce03a2 Add multilib_options variable definition. 
Approved by:	obrien
 2002-10-10 04:56:35 +00:00
Peter Wemm
66422f5b7a Initiate deorbit burn for the i386-only a.out related support. Moves are 
under way to move the remnants of the a.out toolchain to ports.  As the
comment in src/Makefile said, this stuff is deprecated and one should not
expect this to remain beyond 4.0-REL.  It has already lasted WAY beyond
that.

Notable exceptions:
gcc - I have not touched the a.out generation stuff there.
ldd/ldconfig - still have some code to interface with a.out rtld.
old as/ld/etc - I have not removed these yet, pending their move to ports.
some includes - necessary for ldd/ldconfig for now.

Tested on: i386 (extensively), alpha
 2002-09-17 01:49:00 +00:00
David E. O'Brien
1ca4970561 We're going to have to use a TARGET_ARCH of "x86_64" rather than "x86-64" 
to make building GCC happy.
 2002-09-12 15:56:21 +00:00
David E. O'Brien
60f9b09d26 Allow one to profile FORTRAN77 programs. 2002-06-09 00:03:56 +00:00
David E. O'Brien
9291f1b122 Restore revision 1.15 (use profiled C++ libs) which wasn't on the WIP_GCC31 
branch and thus was lost in the shuffle on the move to Gcc 3.1.
 2002-06-08 19:58:31 +00:00
David E. O'Brien
a32192cc4f Fix compiling FORTRAN77 programs. 2002-06-08 18:48:40 +00:00
David E. O'Brien
86f99a57b2 Read specs from /usr/libdata/gcc/specs if it exists. 2002-06-06 03:47:02 +00:00
David E. O'Brien
eb5cb11b70 The best we can do about man pages for the moment. 2002-06-05 21:30:46 +00:00
David E. O'Brien
f09cdb5b44 Search the "backward" C++ compatibility include dir also. 2002-06-05 16:10:59 +00:00
David E. O'Brien
1fd8bea50e We don't need bsd.dep.mk here. 2002-06-05 15:40:39 +00:00
David E. O'Brien
d09b305248 Install the i386 MMX headers, and IA-64 intrinsics functions. 
Requested by:	peter
 2002-06-04 20:00:29 +00:00
David E. O'Brien
8df64a7d4f We don't need this library any more. 2002-06-04 19:45:09 +00:00
David E. O'Brien
ca9578f3ef I missed the setting of PREFIX_INCLUDE_DIR when I visually santity checked 
the output from a autoconfig run.
 2002-05-27 17:48:28 +00:00
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