From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3537 invoked from network); 19 Aug 2004 23:01:37 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 19 Aug 2004 23:01:37 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.34) id 1BxvuX-0003Ub-Qp for arch-gentoo-dev@lists.gentoo.org; Thu, 19 Aug 2004 23:01:33 +0000 Received: (qmail 17238 invoked by uid 89); 19 Aug 2004 23:01:33 +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 4001 invoked from network); 19 Aug 2004 23:01:33 +0000 Message-ID: <412531C7.901@gentoo.org> Date: Thu, 19 Aug 2004 19:03:35 -0400 From: Travis Tilley User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040811) X-Accept-Language: en-us, en MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org, amd64@gentoo.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [gentoo-dev] hardcoding lib in ebuilds, and using econf without einstall X-Archives-Salt: 7b053a3b-7bcd-4d95-acfb-e425b7186b59 X-Archives-Hash: da2466566166ff0d3c014ba9c971e4bb supporting configurations where lib64 or lib32 is a directory will probably require a change in policy and a change in the dev quiz regarding the use of hardcoded lib directories in ebuilds and when einstall should be used. problem #1) with hardcoded references to lib, i have to go and fix each ebuild that does this by hand so that it will work with lib64 or lib32. there are a LOT more ebuilds that do this in the tree than i expected. problem #2) after having fixed ncurses so that it's libdir agnostic and can install into lib64, it was updated to have utf-8 support and that update included some more hardcoded references to lib. this broke ncurses for users with lib64, and there was one bug report where a user was unable to run anything linked against ncurses. so if an ebuild is CONF_LIBDIR aware, -all- references should use this variable (or another one set based on whether or not CONF_LIBDIR is set). problem #3) since econf might set libdir now, it's no longer sane to not set libdir during make install, either by setting it in the ebuild or by using einstall. ebuilds that use econf will have --libdir=/usr/${CONF_LIBDIR} when [ -z "${CONF_LIBDIR}" ] (this change is in the ebuild.sh in >= portage 2.0.51_pre18), so make install will try to install the libraries to the live filesystem if einstall isnt also used. problem #4) since the stable portage doesnt support CONF_LIBDIR and this variable will not be in all profiles even when it is supported, ebuilds that use this variable must default to setting it to lib. note that not all ebuilds will need to even touch this... anything that uses econf and einstall without using hardcoded lib references in the ebuild is already perfect. none of these problems exist when using econf and einstall, and when you're not messing with libs in the ebuild. all the problems can also be avoided in ebuilds that mess with libs by simply using a variable. if there are any instances where einstall cant be used, that needs to be fixed in einstall so that it can be. so... maybe something like this for an ebuild that needs to install to /lib: pkg_setup() { [ -z "${CONF_LIBDIR}" ] && export CONF_LIBDIR="lib" } src_compile(){ econf --libdir=/${CONF_LIBDIR} blah emake } src_install(){ einstall cd ${D}/${CONF_LIBDIR} dodir /usr/${CONF_LIBDIR} mv blah blahdiddly moo ${D}/usr/${CONF_LIBDIR} more stuff here } ...though, suggestions for a better way to do this would be appreciated. especially for solving problem #3. i'm going to have to edit econf so that it sees --prefix, sets a variable based on it, and then sets --libdir=/${myprefix}/${CONF_LIBDIR}. that -looks- like the easiest way to handle it to me, with myprefix=usr when --prefix isnt passed. Travis Tilley -- gentoo-dev@gentoo.org mailing list