src/gnu, branch releng/5.1 FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=releng%2F5.1 2003-06-04T05:37:49Z .Os is now 5.1 2003-06-04T05:37:49Z Scott Long scottl@FreeBSD.org 2003-06-04T05:37:49Z urn:sha1:d955d5f9d59029e441ebb85722606593204c603d This commit was manufactured by cvs2svn to create branch 'RELENG_5_1'. 2003-05-31T11:28:29Z cvs2svn cvs2svn@FreeBSD.org 2003-05-31T11:28:29Z urn:sha1:4b38df05470b4d78dd0a2a026ab8f90299ec8382 Add a temporary indirect patch for gcc when targeting amd64. This is to 2003-05-24T20:58:47Z Peter Wemm peter@FreeBSD.org 2003-05-24T20:58:47Z urn:sha1:cd51f0035e64cf8045a944a9abdc7749c52713a2 give the cvs tree a surviving a 'make world'. One of the two diff chunks is already in gcc-3.3, the other has been committed to gcc's HEAD and is in the pipeline for gcc-3.3.1 (but has not been committed yet). The first chunk simplifies an excessively complex assembler statement when generating switch jump tables. The use of '.' causes as(1) to choke on big files. Use a simpler form instead. This is only an issue for TARGET_64BIT mode. The second chunk fixes an internal compiler error when compiling libc/stdio/vfprinf.c. While this is supposedly only an issue for 64 bit mode, it does touch the 32 bit i386 code paths, so this patch is only applied for TARGET_ARCH == amd64 to keep the risks down. Breaking gcc at the 11th hour would suck. This will be removed when it is time to import gcc-3.3. Discussed with: kan Approved by: re (jhb) libstdc++.so breaks on amd64 due to bogons in our build, so prevent the 2003-05-24T19:38:18Z Peter Wemm peter@FreeBSD.org 2003-05-24T19:38:18Z urn:sha1:ed8c5dcdc0253fa6bf1e81ae195fe56b3df7993c shared library being built for amd64. The problem is that libstdc++.so is produced with 'cc -shared'. This has an internal -lgcc, which is not PIC. libstdc++.so uses exceptions and the dwarf2 unwinder, which are in libgcc.a. As a result, non-PIC code gets pulled into libstdc++.so. This is fatal on amd64 when certain relocation types cannot be used in PIC mode. The official FSF solution to this is to have libgcc.so with internal ELF symbol versioning to solve the ABI problem, but I dont want to fight that battle yet. I tried making libgcc_pic.a (which worked fine), but thats not something for the 11th hour before a release. Approved by: re (amd64 "safe" stuff) Set the binutils arch for as/nm correctly on the amd64 platform. 2003-05-08T06:39:31Z Peter Wemm peter@FreeBSD.org 2003-05-08T06:39:31Z urn:sha1:bd3aef3d0dd12e560f0e5fc50f3367f03fe01640 As far as binutils is concerned, the amd64 platform is still called "x86-64"/"x86_64". Setting things from ${MACHINE_ARCH} breaks that. Approved by: re (scottl) Enable GSSAPI/Kerberos 5 support (aka `gserver'). 2003-05-05T16:50:42Z Jacques Vidrine nectar@FreeBSD.org 2003-05-05T16:50:42Z urn:sha1:bc562db9302343e96610836dbcd65b8fff8735f1 MFC after: 1 month Use __FBSDID over rcsid[]. 2003-05-03T21:31:08Z David E. O'Brien obrien@FreeBSD.org 2003-05-03T21:31:08Z urn:sha1:cd883fb6170378586c4ef1f5f1c6c2827c8d5eef This is WARNS=2 clean. 2003-05-03T21:30:34Z David E. O'Brien obrien@FreeBSD.org 2003-05-03T21:30:34Z urn:sha1:d2f7262ed449877f014b18506d981ca668686548 Fix build on 4.x. 2003-05-02T11:56:43Z Ruslan Ermilov ru@FreeBSD.org 2003-05-02T11:56:43Z urn:sha1:a2211ce1e0a9fc2c39c7aa8a4807872898658766 Re-enable building of Groff documentation; texinfo has just been 2003-05-02T00:55:52Z Ruslan Ermilov ru@FreeBSD.org 2003-05-02T00:55:52Z urn:sha1:7a547773ab65688497eddbb13c3d0497dcc45026 upgraded to version 4.5.