From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21204 invoked by uid 1002); 12 Jul 2003 22:40:49 -0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 31278 invoked from network); 12 Jul 2003 22:40:48 -0000 X-Authentication-Warning: utx.utx.cz: sb set sender to utx@gentoo.org using -f From: Stanislav Brabec To: gentoo-dev@gentoo.org In-Reply-To: <1057840805.8047.10.camel@huggins.eng.cam.ac.uk> References: <873cheefw9.fsf@kirk.better-com.de> <1057840805.8047.10.camel@huggins.eng.cam.ac.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1058049617.2565.0.camel@utx.utx.cz> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 13 Jul 2003 00:40:17 +0200 Subject: Re: [gentoo-dev] How to fix pathnames in .ebuilds X-Archives-Salt: b9f262a2-59e4-425c-be2c-c03a0d80102d X-Archives-Hash: 734d324364a4fe22449a57041c31bd01 Alastair Tse wrote: > On Thu, 2003-07-10 at 13:16, Martin Lesser wrote: > make DESTDIR=${D} install || die "install failed" > Yes, it is the correct and recommended solution! See "info automake" for more. But einstall still uses ancient way: make prefix=${D}/usr \ datadir=${D}/usr/share \ infodir=${D}/usr/share/info \ localstatedir=${D}/var/lib \ mandir=${D}/usr/share/man \ sysconfdir=${D}/etc \ "$@" install This way works for many packages and in past it was the only way, but it is basically incorrect - those values has influence to compiler and linker, not only for destination paths! This is the reason why automake developers has added DESTDIR, which is designed to have no influence to compiler. Please change the default in portage and rename current einstall to old_einstall. Well, there are some bad projects, which installs OK with this old way, but not with DESTDIR, but it's better to use autoreconf or write a fix. Why? Changing prefix-based dirs is very dangerous way to install automake based projects and can lead to access violation or even to mis-compiled projects! 1) Many paths (e. g. PIXMAPS_DIR) are evaluated in configure time and this install hack does not change it. 2) Purpose of all these variables is definition of default paths for compiler and linker. If package recompiles/links something during install process, it changes default path compiled into binary/library. OT: Similar problem exists also for libraries: Do not use LDFLAGS and CPPFLAGS for references to build root - use LIBRARY_PATH and CPATH (C_INCLUDE_PATH, CPLUS_INCLUDE_PATH, OBJC_INCLUDE_PATH). Otherwise you will get library with incorrect hardwired paths either to binary/library or to la file. It is security hole, if la file points to /var/tmp. -- Stanislav Brabec http://www.penguin.cz/~utx -- gentoo-dev@gentoo.org mailing list