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.
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.
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.
(the old cc has been tagged with "gcc_2_6_3_final" so we have a reference
point in case of unforseen disasters...)
This has the objc backend active, and I think I've managed to get the
f77 f2c support through in one piece, but I don't know fortran to test it.
A 'make world' change and libobjc commit will follow.
If you normally do 'make -DNOCLEAN world', do not do so this time, I know
it can fail with groff.
This version of gcc makes a **LOT** more warnings on our kernel.
Notice that the libgcc DOESN'T change number, because there are no
changes.
Also now the gnu2bmake stuff is synchronized again.
I commit this so that others can test too.
You might want to postpone any "make worlds" until tomorrow, to
avoid any problems I didn't see in the first pass.
Thanks to Bruce for rounding up our changes to gcc.
GCC-2.6.1 COMES TO FREEBSD-current
----------------------------------
Everybody needs to 'make world'.
Oakland, Nov 2nd 1994. In a surprise move this sunny afternoon, the release-
engineer for the slightly delayed FreeBSD-2.0, Poul-Henning Kamp (28),
decided to pull in the new version 2.6.1 of the GNU C-compiler.
The new version of the compiler was release today at noon, and hardly 9
hours later it was committed into the FreeBSD-current source-repository.
"It's is simply because we have had too much trouble with the version 2.6.0
of the compiler" Poul-Henning told the FreeBSD-Gazette, "we took a gamble
when we decided to use that as our compiler for the 2.0 release, but it
seems to pay of in the end now" he concludes.
The move has not been discussed on the "core" list at all, and will come as
a surprise for most Poul-Hennings peers. "I have only discussed it with
Jordan [J. K. Hubbard, the FreeBSD's resident humourist], and we agreed that
we needed to do it, so ... I did it!". After a breath he added with a grin:
"My email will probably get an all time 'disk-full' now!".
This will bring quite a flag-day to the FreeBSD developers, the patch-file
is almost 1.4 Megabyte, and they will have to run "make world" to get
entirely -current again. "Too bad, but we just had to do this." Was
the only comment from Poul-Henning to these problems.
When asked how this move would impact the 2.0 release-date, Poul-Hennings
face grew dark, he mumbled some very Danish words while he moved his fingers
in strange geometrical patterns. Immediately something ecclipsed the Sun, a
minor tremor shook the buildings, and the temperature fell significantly.
We decided not to pursure the question.
-----------
JOB-SECTION
-----------
Are you a dedicated GCC-hacker ?
We BADLY need somebody to look at the 'freebsd' OS in gcc, sanitize it and
carry the patches back to the GNU people. In particular, we need to get
out of the "i386-only" spot we are in now. I have the stuff to take a
gnu-dist into bmake-form, and will do that part.
Please apply to phk@freebsd.org
No Novice Need Apply.
no longer link against the whole library, since they don't require much
from it, but just compile the few small modules they actually need static.
This should save a measurable amount of space; compare:
-r-xr-xr-x 1 bin bin 155648 Sep 18 18:00 cc1*
-r-xr-xr-x 1 root bin 1048576 Sep 18 17:33 cc1.noshae*
Of course, the library takes up a bit of space, but when you add in the
savings from the C++ compiler, you more than make up the difference:
-r--r--r-- 1 bin bin 1157344 Sep 18 18:27 /usr/lib/libcc_int.so.26.0
-r-xr-xr-x 1 bin bin 491520 Sep 18 18:27 /usr/libexec/cc1plus*
automagically. -lfoo has to be right to work, but ${LIBFO0} is too
easy to forget or misspell; nothing checks it and it should be
different for shared libraries.
