From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1JotIl-0008Lj-QO for garchives@archives.gentoo.org; Thu, 24 Apr 2008 04:43:20 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4F87FE07F4; Thu, 24 Apr 2008 04:43:17 +0000 (UTC) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by pigeon.gentoo.org (Postfix) with ESMTP id 021B5E07F4 for ; Thu, 24 Apr 2008 04:43:16 +0000 (UTC) Received: by wa-out-1112.google.com with SMTP id k34so4823054wah.10 for ; Wed, 23 Apr 2008 21:43:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=eH3sUAv4oQktOD5zo3/rl986G0amYKdrazZrBWsWe9Y=; b=UdkqF41BpLbQmQuugFcxEDVBxi2c4L1CCcS2MYTCAlCKwBS87/I75FbeyvbmuOFdDB8Z47JqdYsWWkds5fuePzvM7ASLLYhODhWw/gAkLq15td4V8K2cHxunFVZ/fY//5iiuglXNVoOZANRfxFTvwZiZC/4TTUxovwpuvhA9Gsw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=yAieSNBSN0eQgrPePtiw6Mk4UxWtId54/zfg/GE4zrt5QNkumAdsDlL0+zsREkDMEO/wJ7lbxrgTN0gB/c0Y/9VwW5E4q1fePiD7/6A/njWGOjybVqX2xqhUw/Qpop6QgK5M3I8whpz2LbdjGuUKjTV2csmoZ7HqyGqk9Py6U6Q= Received: by 10.114.135.1 with SMTP id i1mr1249610wad.88.1209012196506; Wed, 23 Apr 2008 21:43:16 -0700 (PDT) Received: by 10.115.74.12 with HTTP; Wed, 23 Apr 2008 21:43:16 -0700 (PDT) Message-ID: <17dc8bc70804232143k1572c362pf1b3adfaa8d72f66@mail.gmail.com> Date: Wed, 23 Apr 2008 23:43:16 -0500 From: "Andy Wang" To: gentoo-amd64@lists.gentoo.org Subject: Re: [gentoo-amd64] Re: building emul-linux-x86 files In-Reply-To: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@lists.gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <17dc8bc70711230742r118e829dt217c3f6f0cc0998f@mail.gmail.com> <47471782.9030204@gentoo.org> <17dc8bc70711261252t1da74970j32134d75b88415d7@mail.gmail.com> <17dc8bc70804231739jc6f8adcr7eb1b5daf33bda7b@mail.gmail.com> X-Archives-Salt: 99468eb6-de8d-4134-b9e7-f288cb8d98ef X-Archives-Hash: 389e1017e8cda5a303bbd3bc298750bb On Wed, Apr 23, 2008 at 9:40 PM, Duncan <1i5t5.duncan@cox.net> wrote: > "Andy Wang" posted > If you'd kill the HTML next time, some of us would be grateful. Not > everyone here likes webmail, and HTML based messages can be a security > issue, so some of us choose not to enable it or use clients that handle > it. Thanks. Gmail defaults to multipart html and plain text, and as Volker said in his reply, that shouldn't be a problem with any modern mailer. Given that gentoo is a "geek" distribution, I'm sure there are plenty of legacy e-mail client holdouts thus I will make it a point to try to remember to force plain text formatting (which I've done with this message). Given the volume of mail on this list, I sure as hell am not going to use my regular e-mail account's quota given my 6GB+ gmail quota :) > > I'd use the 32-bit chroot (or build on a 32-bit machine) and use > FEATURES=buildpkg so all the packages ended up as tbz2 binaries. > > For individual cases that should be enough on the build side. On the > binary package consumer, I'd use a 32-bit chroot again (to keep the 32- > bit packages tracked separately from the 64-bit ones) and either emerge > a more or less full system or use package.provided and/or --nodeps when > merging individual packages if I chose not to do the full 32-bit system. > The problem with a 32-bit chroot system is that for things to work properly on a multilib system, 32-bit libraries go in /lib32|/usr/lib32. A standard x86 environment doesn't deal with that. The old instructions at http://www.gentoo.org/proj/en/base/amd64/emul/ basically document doing this with a 32-bit chroot with a custom profile (that's in the portage tree) to deal with the multilib directory structure. However, that howto is obsolete as per Mike Doty's original e-mail on this thread when I started it over half a year ago. Back then the response was maybe in a month or two it would be documented and it still isn't, so I'm asking again just to see if anyone has made any progress on the documentation. > For something more suitable for general distribution, IOW, usable > directly from the main system's portage/other-pm, I'd use the binaries > created in the first step as the "sources", and build an ebuild script > wrapper around them to untar and install them manually (and to an > appropriately different location for libs, or name for executables, than > the 64-bit stuff), while tracking them using emul- (or similar) to keep > them separate from the 64-bit packages of the otherwise same name. The > same skeleton untar and install script could be used for all such > packages, with specific extra configuration, etc. attached as necessary. This doesn't work for libraries that have additional modules that are located in /usr/lib32/[moduledirectory] as I mentioned in my previous comment when you have libraries built in a regular chroot environment with a libdir of /usr/lib, it's going to look for /usr/lib/[moduledirectory]/module.so which will be the 64-bit library and thus incompatible > > That seems fairly straightforward and would the existing portage binary > package capabilities, but is obviously not quite the method they took, as > they have more generalized packages that include binaries (libraries, > etc) from multiple normal packages. The advantage of doing it as above, > however, would be that the generic wrapper ebuild script could be simply > renamed as appropriate to use with 32-bit packages other than those > currently supplied. > > As I said, FWIW... It may or may not be suitable for your purposes. Unless you have a suggestion on how to deal with LIBDIR during configure runs and such, your suggest is unfortunately not suitable for my purposes. What little digging I have been able to do shows that ABI=x86 seems to provide some ability to build 32-bit packages so long as all of the dependencies have been built as 32-bit. Unfortunately, some of the packages I want to build have different header files in /usr/include for 64-bit and 32-bit platforms making it very difficult to build without a chroot environment, but the only chroot environment that I know of that partially works is the one that was documented that is now considered obsolete. -- gentoo-amd64@lists.gentoo.org mailing list