Re: [gentoo-amd64] Re: building emul-linux-x86 files

[Andy Wang]

On Wed, Apr 23, 2008 at 9:40 PM, Duncan <1i5t5.duncan@×××.net> wrote:
> "Andy Wang" <dopey74@×××××.com> 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@l.g.o mailing list