From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Bruce Korb Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] do not augment environment Date: Mon, 01 Oct 2012 11:27:52 -0700 Message-ID: <5069E0A8.8030704@gnu.org> References: <505CF9FC.9060007@gmail.com> <5069022C.9040600@netris.org> <5069AB0F.4010805@gnu.org> <5069CBF6.9030108@netris.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1349116101 5784 80.91.229.3 (1 Oct 2012 18:28:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Oct 2012 18:28:21 +0000 (UTC) Cc: Guile Development To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Oct 01 20:28:26 2012 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TIkj2-0005iN-EV for guile-devel@m.gmane.org; Mon, 01 Oct 2012 20:28:16 +0200 Original-Received: from localhost ([::1]:59671 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TIkiw-0005fp-Q9 for guile-devel@m.gmane.org; Mon, 01 Oct 2012 14:28:10 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:44761) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TIkir-0005fi-9I for guile-devel@gnu.org; Mon, 01 Oct 2012 14:28:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TIkii-0006CD-0V for guile-devel@gnu.org; Mon, 01 Oct 2012 14:28:05 -0400 Original-Received: from fencepost.gnu.org ([208.118.235.10]:60685) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TIkih-0006C9-T0 for guile-devel@gnu.org; Mon, 01 Oct 2012 14:27:55 -0400 Original-Received: from adsl-76-254-31-152.dsl.pltn13.sbcglobal.net ([76.254.31.152]:59739 helo=[192.168.10.2]) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1TIkih-0003Px-4O; Mon, 01 Oct 2012 14:27:55 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120825 Thunderbird/15.0 In-Reply-To: <5069CBF6.9030108@netris.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 208.118.235.10 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:14924 Archived-At: On 10/01/12 09:59, Mark H Weaver wrote: > On 10/01/2012 10:39 AM, Bruce Korb wrote: >> On 09/30/12 19:38, Mark H Weaver wrote: >>> In the current code, SCM_LIB_DIR and SCM_EXTENSIONS_DIR are only >>> added to the library search path when GUILE_SYSTEM_EXTENSIONS_PATH >>> is not set. Your patch mishandles this, because it _always_ acts >>> as if SCM_LIB_DIR and SCM_EXTENSIONS_DIR have been added to the search path. >> >> Always inserting "GUILE_SYSTEM_EXTENSIONS_PATH=" into the environment >> is a better fix than erasing LD_LIBRARY_PATH, but I hadn't read and >> digested the source. Thanks for the pointer. > > Are you deploying this fix in widely-used software, or just within your private environment? If the latter, that's fine, and you can disregard the rest of this message. > > If the former, then we need to be careful. By setting GUILE_SYSTEM_EXTENSIONS_PATH="", you will break Guile programs that need to load extensions, not just within your own program, but within any subprocesses that might be unrelated to your project. > > Also, our internal hack of setting GUILE_SYSTEM_EXTENSIONS="" during the Guile build is not documented as far as I know, and might change in the future. It's actually a bad hack, for the same reasons given above. For example, if 'gcc' started using Guile, then setting GUILE_SYSTEM_EXTENSIONS="" within the Guile build could break gcc. > > I admit that we created this mess by deploying a bad hack, but let's try to avoid getting ourselves into an even bigger mess by deploying more bad hacks that lock us into preserving our current hacks. > > Before I spend any more time thinking about this, can you please answer my question above? autogen is used within GCC for constructing the top level Makefile.am's and for cobbling together all the hackery required to fix up broken include files. There are another dozen or so lesser known projects that use it for building out Java Beans infrastructure and similar repetitive tasks. The most common use is likely option processing, but that use would surely never bump into problems with GUILE_SYSTEM_EXTENSIONS_PATH. (NTP and GNU TLS are two well known users of the option stuff.) I control all the associated templates and they do not use any "subprograms" implemented in Scheme/Guile. In general, I've found my clients to be reluctant users of scheme and it is actually more a barrier to use rather than a facilitator of use. In other words, I suspect, but do not know, that there would be little issue. WRT my problem, I have several choices that I would activate only when the problematical versions of Guile are detected (2.0.1 thru 2.0.?? - what ??): 1. putenv("LD_LIBRARY_PATH="); 2. putenv("GUILE_SYSTEM_EXTENSIONS_PATH="); 3. putenv("GUILE_SYSTEM_EXTENSIONS_PATH=/dev/null"); 4. any other suggestions? I think #3 would likely be safest for my environment, but I would certainly like your opinion. Thank you! Regards, Bruce P.S. To be clear: I would not bind you into keeping the null extensions hack. I would stop using it upon detecting a Guile version that does not hack LD_LIBRARY_PATH.