From owner-freebsd-ports Mon Nov 18 05:45:32 1996 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA10100 for ports-outgoing; Mon, 18 Nov 1996 05:45:32 -0800 (PST) Received: from ki1.chemie.fu-berlin.de (ki1.Chemie.FU-Berlin.DE [160.45.24.21]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id FAA10060; Mon, 18 Nov 1996 05:44:59 -0800 (PST) Received: by ki1.chemie.fu-berlin.de (Smail3.1.28.1) from mail.hanse.de (193.174.9.9) with smtp id ; Mon, 18 Nov 96 14:44 MET Received: from wavehh.UUCP by mail.hanse.de with UUCP for freebsd-ports@freebsd.org id ; Mon, 18 Nov 96 14:41 MET Received: by wavehh.hanse.de (4.1/SMI-4.1) id AA24457; Mon, 18 Nov 96 14:41:45 +0100 Date: Mon, 18 Nov 96 14:41:45 +0100 From: cracauer@wavehh.hanse.de (Martin Cracauer) Message-Id: <9611181341.AA24457@wavehh.hanse.de> To: peterh@prognet.COM Cc: current-users@freebsd.org, jkh@freebsd.org, freebsd-ports@freebsd.org, nakai@mlab.t.u-tokyo.ac.jp Subject: Re: guavac, libstdc++ Newsgroups: hanse-ml.freebsd.current References: <3.0b36.32.19961116131427.010daf60@prognet.com> Reply-To: cracauer@wavehh.hanse.de Sender: owner-ports@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I verified that the following problem (libstdc++ from gnu/lib/libg++ is not being build) still exists in RELENG_2_2 and 3.0-current as of today. I appended diffs. I included Jordan in the CC line because I think this fix should be in 2.2 This bug means people - can't use the public guavac compiler or the public java language - can't make serious use of C++ (?) - they will say its better to run native GNU tools than to use FreeBSD's - the universe as we know it will collapse Sorry for the broadcast, but the issue spread over -current, -ports and -hackers. I also sent a pr. >>Hello >> There are three *.cc files in >>/usr/src/contrib/libg++/libstdc++/stl >> >>random.cc >>tree.cc >>tempbuf.cc >> >>That are not being built under FreeBSD. Should these three files >>be added to the build process for libstdc++? They really need >>to be included into a library. >I encountered this problem too. It is not that those files are not being >compiled at all, but that they are not compiled into the shared library. I >moved 'libstdc++.so.2.0' out of my /usr/lib and any STL stuff that uses red >black trees now works. >This only happened after I upgraded to the 2.2-961014-SNAP. I don't know >whether this is still a problem. I can't verify that the shared lib is OK, the Makefile leave the files out for both library variants. Anyway, here's the fix for RELENG_2_2 and 3.0-current =================================================================== RCS file: src/gnu/lib/libstdc++/Makefile,v retrieving revision 1.1 diff -r1.1 Makefile 7c7 < .PATH: ${GPPDIR}/libstdc++ ${GPPDIR}/libio ${GPPDIR}/libiberty --- > .PATH: ${GPPDIR}/libstdc++ ${GPPDIR}/libstdc++/stl ${GPPDIR}/libio ${GPPDIR}/libiberty 40c40 < projectn.h set.h stack.h tempbuf.h tree.h vector.h --- > projectn.h set.h stack.h tempbuf.h tree.h vector.h 43c43,45 < stdexcepti.cc cstdlibi.cc cmathi.cc --- > stdexcepti.cc cstdlibi.cc cmathi.cc \ > random.cc tree.cc tempbuf.cc > -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://cracauer.cons.org Fax +49405228536 "As far as I'm concerned, if something is so complicated that you can't ex- plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin