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: Why is Guile now setting LD_LIBRARY_PATH? Date: Tue, 11 Sep 2012 09:21:27 -0700 Message-ID: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1347380527 808 80.91.229.3 (11 Sep 2012 16:22:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 11 Sep 2012 16:22:07 +0000 (UTC) To: =?ISO-8859-1?Q?Ludovic_Court=E8s?= , Guile Development Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Sep 11 18:22:10 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 1TBTDx-0006Hr-PE for guile-devel@m.gmane.org; Tue, 11 Sep 2012 18:22:05 +0200 Original-Received: from localhost ([::1]:60954 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBTDu-0001m9-7p for guile-devel@m.gmane.org; Tue, 11 Sep 2012 12:22:02 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:42822) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBTDl-0001fl-HJ for guile-devel@gnu.org; Tue, 11 Sep 2012 12:21:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TBTDh-0001XP-7d for guile-devel@gnu.org; Tue, 11 Sep 2012 12:21:53 -0400 Original-Received: from mail-oa0-f41.google.com ([209.85.219.41]:37118) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBTDh-0001XB-2h; Tue, 11 Sep 2012 12:21:49 -0400 Original-Received: by oagj6 with SMTP id j6so418080oag.0 for ; Tue, 11 Sep 2012 09:21:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type:content-transfer-encoding; bh=v/gEc2KnIL+ARIatvEpJI3060azDS1JKgGfBj/ntuHg=; b=v79kZGOHC3JgXvfNL+BgzBq0E0GtsmZJdTCMhkgRR3yiOOCLTVdoECZXy+XKuSkSjD NdKa3swPDcm3ZbED63wRQfusn676NR2K4WLtDp3MiWbmGYf12UC7m20z4+EVwepMP9R3 auwW4EZRLJNxAuhuG6OiNoJhIYZBKXwebbZHB90ouWwNAMV5M3TMRpupb/ZsAzfMRo9o dZmANQlC1TlmsXrnhKenbslFHiHJCfVBM9MTQ5dtxg5W2gigtLmuo6wtd1F5dhfjL4rJ /2mIbTAqFq5BG+5dVC0KLhaSH8H2+3WOd+HiBPLCkWxYPANVj8uDJDoHttOS5Qhydebe EBAg== Original-Received: by 10.182.72.9 with SMTP id z9mr18925506obu.5.1347380507935; Tue, 11 Sep 2012 09:21:47 -0700 (PDT) Original-Received: by 10.76.120.169 with HTTP; Tue, 11 Sep 2012 09:21:27 -0700 (PDT) X-Google-Sender-Auth: hF16OujUL9arY5V1Il8Ld1lJwM4 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.219.41 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:14880 Archived-At: Hi Ludo, >> in main() LD_LIBRARY_PATH=3D'EMPTY' >> in inner_main() LD_LIBRARY_PATH=3D'/usr/lib64:/usr/lib64/guile/2.0/exten= sions' > >The reason provided in =91sysdep_dynl_init=92 is: > >/* Add SCM_LIB_DIR and ... See > > for details. */ I am sure you are not arguing that I ought to have known due to a comment in source code and an email from a couple of years ago. My point is that messing with the library search path in an effectively secret manner caused me to spend hours chasing the problem. >> libguile needs to be linked with -Wl,-rpath >> -Wl,/usr/lib64/guile/2.0/extensions >> instead of messing up your client's link/load. ("/usr/lib64" should not = be >> needed.) > >Problem is that (1) -rpath is not always available, and (2) when using >GNU ld with --enable-new-dtags, it produces a RUNPATH (not an RPATH), >which can be overridden by $LD_LIBRARY_PATH. > >I agree that using setenv is ugly, but finding an option that=92s portable >and doesn=92t break existing programs seems tricky too. > >Do you have any solutions meeting this criteria in mind? Wrap your dlopen's in code that pushes the needed values to the environment and then removes them when dlopen is done. You still have multi-thread issues when someone is calling dlopen or exec while a libguile thread is messing with the environment. Perhaps you could document a global lock variable that could single-thread these operations for multi-threaded applications. Either way, fiddling the environment only while using dlopen is far better than breaking people's applications in unexpected ways. At the end: messing with LD_LIBRARY_PATH in a library breaks programs that use the library and make calls to exec or dlopen. Please find a solution that does not do this, or at least minimizes the issues. Thank you. Regards, Bruce C.F. Greg Troxel: > I don't follow why you think this is the right fix. It seems that guile > (main) and libguile (library) should both not set LD_LIBRARY_PATH at > all. To be clear, I do not think this the right fix, but since my application ha= s to cope with un-fixed guile releases, I have to do something. Nuking the variable is the easiest. WRT guile the program and libguile the library, = you are correct: neither should set LD_LIBRARY_PATH. It needs to be a user selection to adjust to specific issues in a user's environment.