From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4562 invoked by alias); 6 Aug 2014 02:12:20 -0000 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 Received: (qmail 3003 invoked by uid 89); 6 Aug 2014 02:12:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: smtp.gentoo.org Received: from smtp.gentoo.org (HELO smtp.gentoo.org) (140.211.166.183) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 06 Aug 2014 02:12:00 +0000 Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id AD4A2340185; Wed, 6 Aug 2014 02:11:58 +0000 (UTC) From: Mike Frysinger To: gdb@sourceware.org Cc: Tony Wang , yunlian@chromium.org Subject: Re: Is python dependency detection acceptable? Date: Wed, 06 Aug 2014 02:12:00 -0000 Message-ID: <1490951.iZjJNAbgyO@vapier> User-Agent: KMail/4.13.1 (Linux/3.14.2; KDE/4.13.1; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4588910.1Qh1rNyGWd"; micalg="pgp-sha1"; protocol="application/pgp-signature" X-IsSubscribed: yes X-SW-Source: 2014-08/txt/msg00004.txt.bz2 --nextPart4588910.1Qh1rNyGWd Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Content-length: 1577 On Tue 24 Jun 2014 10:48:05 Tony Wang wrote: > Recently I'm building gdb with python support, and I noticed that gdb > with python support will heavily depends on the python environment on > the build machine. >=20 > So if I give the gdb with python support to other PC, and the python > environment is different from my build machine, the gdb will fail to > launch. Basically, I think python support is not wanted by every user, > but it's a little bit confusing for toolchain maintainer to release > two version of gdb(with and without python). So is it possible to > detect in the gdb, whether the user python environment is ok?(Usually > user will have python, but the library path or version may cause the > gdb fail to launch). If the user do not have the python, then just > disable python function in gdb. >=20 > I've noticed a hack patch to do this before, it just test the pyinit > function in a new thread to see if the python environment is ready. Is > such a operation acceptable? this is how we addressed it in CrOS: https://chromium.googlesource.com/chromiumos/third_party/gdb/+/b35e9f2915f3= 19ed23e50d66c5d157370e113317%5E%21/ we had to do this for the same reason you describe -- we build gdb in one e= nv=20=20 (Gentoo) and deploy it in another (Ubuntu), and the two have different pyth= ons=20 available. python works fine in the original env and we want to keep it=20 viable, but we don't want gdb killing itself simply because python isn't=20 available. hopefully Yunlian will submit the patch for official consideration at some= =20 point :). -mike= --nextPart4588910.1Qh1rNyGWd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABAgAGBQJT4Y70AAoJEEFjO5/oN/WBNY0P/2awMR4EXcs3SnxGMt44Ejxt FW+A8yV33DOtN8CIG6X++Jm1LagwKo70pFPn0ZYSgQF4BQtW/98nfkWv/ycPQa7a QCUYEUcLGL4QAsnjbC62Yo9+fb92aQvBYVLqseEEG4zkbJVJVO88CdABd5bXfs/u +zbQoPqF8DQr7+3TSPSvGMqUZRGRzx5vGXI1SKeQ5IGHPdtWd5C1dJCIP8dXNLsZ RuKYinHHGqBsw0RVYa0LqTWKm8KoOk8eRchEPn15MeqdaMLzppysaC6YgjPLUPZx vsKpDJAyN4kLwArIZ4co76qBl9AkfPp+Xl9PMCQq+YenwT8Yd/2CWbm60qk7CzZA Yfi55PZkU/EcgFsTrdVsXASguzCzw1WuyUkyVNmFibolrlyC2+vBWBAZ6ki6oxA/ f08Gwx1UbrE+b9Is8tGgHaakzJlpsnPXgPFp65LNTAb4k4/qTRpcHxtvRECdmBDM Q9WIpr3dZRITa8CYPRBo6e/0qRZyJQYX6vCxnhHXmDlxjBkz6qJSTHfZwkC3nH62 hrfQjN29ZG6YWSSpq29se6QvJFCrkx9bFrxD18LS9DelyMP3NQ0OtgvqbVoCNzv8 q1ixV1ZVvRvSXP2LONwvX58lQsg3IY/F64skdaOrri9G0ojcY0wP2Ek1dkhzivNn DzrL7m25IkcU7ZTknyZU =cy7l -----END PGP SIGNATURE----- --nextPart4588910.1Qh1rNyGWd--