src-test2/gnu/lib, branch release/5.1.0_cvs FreeBSD source tree https://cgit-dev.freebsd.org/src-test2/atom?h=release%2F5.1.0_cvs 2003-06-04T16:00:27Z This commit was manufactured by cvs2svn to create tag 2003-06-04T16:00:27Z cvs2svn cvs2svn@FreeBSD.org 2003-06-04T16:00:27Z urn:sha1:1c0442969cd576514acfce932c0a0798593c7af7 'RELENG_5_1_0_RELEASE'. This commit was manufactured to restore the state of the 5.1-RELEASE image. Releases prior to 5.3-RELEASE are omitting the secure/ and crypto/ subdirs. 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) 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 Enable wchar_t support in libstdc++. 2003-04-29T18:10:45Z Alexander Kabaev kan@FreeBSD.org 2003-04-29T18:10:45Z urn:sha1:93fa8833c7de99bd09f9eafb63a9d7e4cb7bb3d0 Enable ISO-C99 compatibility -- among other things, this tells libstdc++ 2003-04-25T21:17:31Z David E. O'Brien obrien@FreeBSD.org 2003-04-25T21:17:31Z urn:sha1:7af330a71cf586e8d8a10a6f210a56ff940b9036 not to blindly undef isnan() and other functions that became macros in C99. Enable use of newly grown C99 functions: strtof(), strtold(), wcstof() Submitted by: das Forced non-forced commit by adding a comment mentioning what the 2003-03-17T00:08:47Z Marcel Moolenaar marcel@FreeBSD.org 2003-03-17T00:08:47Z urn:sha1:f35f81b703b31f82f39de4c95f2289a627ffb0e3 previous commit log should have mentioned: PR: ia64/49081 libobjc is linked against shared objects and since we don't have a 2003-03-16T22:44:01Z Marcel Moolenaar marcel@FreeBSD.org 2003-03-16T22:44:01Z urn:sha1:8fb9b278d9b891931668f5528ef42023f6f93872 shared object of libobjc, we end up linking in from the archive version. This is wrong, because we don't compile the archive version suitable for inclusion in shared objects. On ia64 this causes actual breakages. Compile the archive version with PIC on ia64 to avoid the breakage there and also to avoid changing the status quo on other architectures. If other architectures have the same problem, we probably should start building a shared library. There's no indication however that other architectures actually need it. Building the archive version with PIC on ia64 does pessimize linking complete binaries (ie fully archive), but we don't use Objective-C ourselves and so far I haven't seen non-shared executables written in Objective-C, so I'm sure this will be nothing but academic. Trigger case: ports/lang/gnustep-base Only cross-tools may use TARGET_ARCH/TARGET, everyone else 2003-02-27T09:19:31Z Ruslan Ermilov ru@FreeBSD.org 2003-02-27T09:19:31Z urn:sha1:9ef2a48e9747c5c9ccc16ee74a7ae39aa9c587e7 should use the normal MACHINE_ARCH/MACHINE instead. Update for GCC 3.2.2 2003-02-19T04:28:12Z Alexander Kabaev kan@FreeBSD.org 2003-02-19T04:28:12Z urn:sha1:61856f3619094d3c7dd142500f0295f62a970dca