From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23103 invoked by alias); 21 Sep 2012 17:28:07 -0000 Received: (qmail 23092 invoked by uid 22791); 21 Sep 2012 17:28:05 -0000 X-SWARE-Spam-Status: No, hits=-6.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_GC X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 21 Sep 2012 17:27:46 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q8LHReL8019135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 21 Sep 2012 13:27:40 -0400 Received: from host2.jankratochvil.net (ovpn-113-58.phx2.redhat.com [10.3.113.58]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q8LHRade025350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 21 Sep 2012 13:27:38 -0400 Date: Fri, 21 Sep 2012 17:28:00 -0000 From: Jan Kratochvil To: Joel Brobecker Cc: Doug Evans , Meador Inge , gdb@sourceware.org Subject: Re: Using Py_SetPythonHome Message-ID: <20120921172735.GA4341@host2.jankratochvil.net> References: <50511945.2070400@codesourcery.com> <20120917170657.GB5716@adacore.com> <20120917174611.GA27891@host2.jankratochvil.net> <20120919080410.GA12296@host2.jankratochvil.net> <20120921153645.GD5439@adacore.com> <20120921154345.GA30615@host2.jankratochvil.net> <20120921155758.GE5439@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120921155758.GE5439@adacore.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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-09/txt/msg00067.txt.bz2 On Fri, 21 Sep 2012 17:57:58 +0200, Joel Brobecker wrote: > > This is creating OS-in-an-application designs reimplementing what OS > > should do. > > Really? You keep dismissing the model where everything is managed by > a GNU/Linux distribution, and this has been a regular source of > fustration. Some users, myself included (and I am not speaking as > an AdaCore employee), routinely install software from sources, and > I keep everything separate from the system installs, because it's > easier to manage. Are you going to deny that this is a legitimate > situation? It may be a perfectly legitimate situation, I do not argue with this part. I argue that no other system application does what GDB does. If some changes should be done they should be done in a system, not in one application. The question is whether such behavior is at least native for GNU Toolchain which has various specifics. I have discovered now that default build of GCC really uses something like relocate_gdb_directory for its own components (like cc1), it does not use constant compiled-in path like normal applications do. This justifies relocate_gdb_directory for the default build of GDB, it was not clear to me. This also means GCC is violating standard system packaging practices. But gcj still loads external dependency --with-ecj-jar=/path/to/eclipse-ecj.jar from its original location, without any relocation: 2833 stat("/home/jkratoch/redhat/gcchead2-root-moved/bin/../lib/gcc/../../share/java/libgcj-4.8.0.jar", {st_mode=S_IFREG|0644, st_size=10619110, ...}) = 0 2834 execve("/home/jkratoch/redhat/gcchead2-root-moved/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/ecj1", ...], [/* 54 vars */] - relocated 2834 access("/home/jkratoch/redhat/gcchead2-root/eclipse-ecj.jar", F_OK) = -1 ENOENT (No such file or directory) - not relocated Is this gcj behavior considered a bug or not? eclipse-ecj.jar is external (==part of a different system rpm/deb) to GCC like Python is external to GDB. I did mind about relocate_gdb_directory, when that part seems native to GNU Toolchain I leave the Python configuration to Python maintainers. There is already an IMO-incorrect part of GDB setting Py_SetProgramName so Py_SetPythonHome may be a part of it, I do not know Python to say more. Python itself is already violating packaging standards (single directory for both source .py and arch-dependent .pyc/pyo, incorrect use of -rdynamic, there may be more) so I understand applications using Python may also violate it. Regards, Jan