From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11326 invoked by alias); 9 Apr 2012 20:15:03 -0000 Received: (qmail 11181 invoked by uid 22791); 9 Apr 2012 20:15:00 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,KHOP_DYNAMIC,KHOP_THREADED,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mx0a-000f4101.pphosted.com (HELO mx0a-000f4101.pphosted.com) (67.231.144.146) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 09 Apr 2012 20:14:47 +0000 Received: from pps.filterd (m0000260 [127.0.0.1]) by mx0a-000f4101.pphosted.com (8.14.5/8.14.5) with SMTP id q39KEaSk025403; Mon, 9 Apr 2012 16:14:45 -0400 Received: from mta1.netezza.com (mta1.netezza.com [12.148.248.132]) by mx0a-000f4101.pphosted.com with ESMTP id 13yjupvej6-22 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 09 Apr 2012 16:14:45 -0400 Received: from [172.29.90.126] (172.29.90.126) by owa1.netezza.com (172.29.50.131) with Microsoft SMTP Server id 8.1.436.0; Mon, 9 Apr 2012 16:14:44 -0400 Subject: Re: Will therefore GDB utilize C++ or not? From: Paul Smith Reply-To: psmith@gnu.org To: Pedro Alves CC: Jan Kratochvil , Tom Tromey , gdb@sourceware.org In-Reply-To: <4F833D29.4050102@redhat.com> References: <20120330161403.GA17891@host2.jankratochvil.net> <87aa2rjkb8.fsf@fleche.redhat.com> <4F832D5B.9030308@redhat.com> <20120409190519.GA524@host2.jankratochvil.net> <4F833D29.4050102@redhat.com> Content-Type: text/plain; charset="us-ascii" Date: Mon, 09 Apr 2012 20:15:00 -0000 Message-ID: <1334002484.22831.8.camel@psmith-ubeta> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7498,1.0.260,0.0.0000 definitions=2012-04-09_03:2012-04-09,2012-04-09,1970-01-01 signatures=0 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2012-04/txt/msg00066.txt.bz2 On Mon, 2012-04-09 at 20:48 +0100, Pedro Alves wrote: > I don't even need to leave my office to find such a system. > > $ssh 192.168.0.253 > [pedro@NAS][~] > >ls /usr/lib/libstd* > ls: cannot access /usr/lib/libstdc*: No such file or directory I personally have no strong feelings about this either way but note the above is not an argument against C++ on embedded systems. On many of the systems I use I statically link libstdc++ with at least some programs; this is well-supported (by GCC at least) and IMO a quite reasonable solution for utilities such as gdbserver. The question is not whether systems provide a C++ userspace environment by default (such as libstdc++): static linking can take care of that very neatly. The question is how many of them WOULD be able to run gdbserver in C, but NOT able to run gdbserver in C++ (from a resource point of view).