Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 8 Apr 2002 11:36:37 +0300
From:      Ruslan Ermilov <ru@FreeBSD.org>
To:        Peter Wemm <peter@wemm.org>
Cc:        Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>, "M. Warner Losh" <imp@village.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/gnu/usr.bin/gperf Makefile src/gnu/usr.bin/groff/src/devices/grodvi Makefile src/gnu/usr.bin/groff/src/devices/grohtml Makefile src/gnu/usr.bin/groff/src/devices/grolbp Makefile sr
Message-ID:  <20020408083637.GB53790@sunbay.com>
In-Reply-To: <20020408063937.EAE793810@overcee.wemm.org>
References:  <Pine.BSF.4.44.0204080648390.76282-100000@naos.dbai.tuwien.ac.at> <20020408063937.EAE793810@overcee.wemm.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--24zk1gE8NUlDmwG9
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Apr 07, 2002 at 11:39:37PM -0700, Peter Wemm wrote:
> Gerald Pfeifer wrote:
> > On Sun, 7 Apr 2002, M. Warner Losh wrote:
> > >            Peter Wemm <peter@FreeBSD.org> writes:
> > >:   Add -lstdc++ to the link args for these C++ tools so that they can=
 be
> > >:   compiled with gcc-3.1.  Somebody thought it was a good idea to move
> > >:   the implementation of new and delete from libgcc to libstdc++.  Th=
is
> > >:   change doesn't harm the current compiler in the tree.
> > > Is this a band-aid until the compiler can be fixed, or a real solution
> > > long term?
> >=20
> > If I'm right, the problem is that the gcc driver is used to compile the=
se
> > C++ sources.
> >=20
> > One of the differences between gcc and g++ is that the latter automagic=
ally
> > links in libstdc++ while the former does not. This has been the case si=
nce
> > (at least GCC 2.95), but we did get away with it because, as Peter obse=
rved,
> > new/delete have been in libgcc which got linked in anyway.
> >=20
> > GCC 3.0 and 3.1, however, have new/delete in libstdc++; the proper fix
> > long-term would be using the g++ driver instead of the gcc driver for
> > these C++ sources.
>=20
> The .cc files are compiled with 'c++' as expected.  The problem is that
> the final link phase uses 'cc'.  Our makefiles have no way to signal that
> the final link should be done with c++ instead since it just sees a bunch
> of .o files that need to be linked into an executable.
>=20
OK, how about backing these out and committing this instead?

%%%
Index: bsd.prog.mk
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /home/ncvs/src/share/mk/bsd.prog.mk,v
retrieving revision 1.105
diff -u -r1.105 bsd.prog.mk
--- bsd.prog.mk	7 Apr 2002 14:58:12 -0000	1.105
+++ bsd.prog.mk	8 Apr 2002 08:34:58 -0000
@@ -32,7 +32,12 @@
 OBJS+=3D  ${SRCS:N*.h:R:S/$/.o/g}
=20
 ${PROG}: ${OBJS}
+.if ${SRCS:M*.cc} !=3D "" || ${SRCS:M*.C} !=3D "" || ${SRCS:M*.cpp} !=3D "=
" || \
+    ${SRCS:M*.cxx} !=3D ""
+	${CXX} ${CFLAGS} ${LDFLAGS} -o ${.TARGET} ${OBJS} ${LDDESTDIR} ${LDADD}
+.else
 	${CC} ${CFLAGS} ${LDFLAGS} -o ${.TARGET} ${OBJS} ${LDDESTDIR} ${LDADD}
+.endif
=20
 .else !defined(SRCS)
=20
%%%


Cheers,
--=20
Ruslan Ermilov		Sysadmin and DBA,
ru@sunbay.com		Sunbay Software AG,
ru@FreeBSD.org		FreeBSD committer,
+380.652.512.251	Simferopol, Ukraine

http://www.FreeBSD.org	The Power To Serve
http://www.oracle.com	Enabling The Information Age

--24zk1gE8NUlDmwG9
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (FreeBSD)
Comment: For info see http://www.gnupg.org

iD8DBQE8sVaVUkv4P6juNwoRAk5mAJ9mQkBqAT3bqaeLJPgk4tZDAAFzCgCfYn2k
T8DfXGZlAesVAI4XqngD5zM=
=7tSD
-----END PGP SIGNATURE-----

--24zk1gE8NUlDmwG9--

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020408083637.GB53790>