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

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

[Andy Wang]

Hi all (specifically KingTaco, as I think you're building most of these now)
In the past, I've been using Blubb's documentation at:
http://www.gentoo.org/proj/en/base/amd64/emul/
To setup my 32-bit chroot environment to build my own emul-linux
packages.  Specifically, gconf, gnome-vfs and gnome packages for xdg
and gnome integration into 32-bit firefox-bin.

With the new gnome 2.20 packages, I figure it's time to keep updated,
and I see the new emul-linux-x86-*-[datestamp] ebuilds are a little
different than before, is Blubb's old method of doing this still the
most correct way or is there another better way of building emul
packages?

Thanks in advance for any info on this stuff.  FYI, I'm more than
willing to make my ebuild and tar.bz2 files available for anyone who
wants gnome/xdg integration into 32-bit firefox-bin.
Andy
-- 
gentoo-amd64@gentoo.org mailing list

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

[Mike Doty]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andy Wang wrote:
> Hi all (specifically KingTaco, as I think you're building most of these now)
> In the past, I've been using Blubb's documentation at:
> http://www.gentoo.org/proj/en/base/amd64/emul/
> To setup my 32-bit chroot environment to build my own emul-linux
> packages.  Specifically, gconf, gnome-vfs and gnome packages for xdg
> and gnome integration into 32-bit firefox-bin.
> 
> With the new gnome 2.20 packages, I figure it's time to keep updated,
> and I see the new emul-linux-x86-*-[datestamp] ebuilds are a little
> different than before, is Blubb's old method of doing this still the
> most correct way or is there another better way of building emul
> packages?
> 
> Thanks in advance for any info on this stuff.  FYI, I'm more than
> willing to make my ebuild and tar.bz2 files available for anyone who
> wants gnome/xdg integration into 32-bit firefox-bin.
> Andy

That page is deprecated, the instructions invalid.  We've built a new
system, and emul-linux-x86-* have a new versioning scheme(YYYYMMDD).
There is no documentation yet for the new system, maybe in a month or 2.

- --
=======================================================
Mike Doty                      kingtaco -at- gentoo.org
Gentoo Infrastructure
Gentoo/AMD64 Strategic Lead
GPG: E1A5 1C9C 93FE F430 C1D6  F2AF 806B A2E4 19F4 AE05
=======================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)

iQCVAwUBR0cXeYBrouQZ9K4FAQL9rQP/dSRmx3mqC5jEQjxqUgSa+rDMFaLDe+lP
b1ShWMvQLA0A7NXUcOMUuuOS3aq0mB+9WqO2eF/MiC3sMIC3s9FXQD/HijoAwsZs
rx2u+ucETRzShf5e9+Fx3QdExatJWmQDqZ1s5qZCKNuZI58AD08uspaFd1uv35Qa
4jhrpXYhdpw=
=YgHc
-----END PGP SIGNATURE-----
-- 
gentoo-amd64@gentoo.org mailing list

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

[Andy Wang]

On Nov 23, 2007 12:10 PM, Mike Doty <kingtaco@gentoo.org> wrote:
>
> That page is deprecated, the instructions invalid.  We've built a new
> system, and emul-linux-x86-* have a new versioning scheme(YYYYMMDD).
> There is no documentation yet for the new system, maybe in a month or 2.
>

Thanks, I'm going to start looking at the eclass and ebuild and files,
but is there any chance you have anything, even random notes you could
pass along for me to try to get an emulation build environment up?

If not, no biggie, I can wait the month or two.
-- 
gentoo-amd64@gentoo.org mailing list

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

[Andy Wang]

[-- Attachment #1: Type: text/plain, Size: 810 bytes --]

Just wanted to follow up on this e-mail from a while ago.  Any new progress
on creating documentation for how gentoo builds it's emul-linux-x86-* files?

Thanks,
Andy


On Mon, Nov 26, 2007 at 3:52 PM, Andy Wang <dopey74@gmail.com> wrote:

> On Nov 23, 2007 12:10 PM, Mike Doty <kingtaco@gentoo.org> wrote:
> >
> > That page is deprecated, the instructions invalid.  We've built a new
> > system, and emul-linux-x86-* have a new versioning scheme(YYYYMMDD).
> > There is no documentation yet for the new system, maybe in a month or 2.
> >
>
> Thanks, I'm going to start looking at the eclass and ebuild and files,
> but is there any chance you have anything, even random notes you could
> pass along for me to try to get an emulation build environment up?
>
> If not, no biggie, I can wait the month or two.
>

[-- Attachment #2: Type: text/html, Size: 1189 bytes --]

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

[Duncan]

"Andy Wang" <dopey74@gmail.com> posted
17dc8bc70804231739jc6f8adcr7eb1b5daf33bda7b@mail.gmail.com, excerpted
below, on  Wed, 23 Apr 2008 19:39:32 -0500:

> Just wanted to follow up on this e-mail from a while ago.&nbsp; Any new
> progress on creating documentation for how gentoo builds it&#39;s
> emul-linux-x86-* files?<br><br>Thanks,<br>Andy<br><br><br><div
> class="gmail_quote">On Mon, Nov 26, 2007 at 3:52 PM, Andy Wang &lt;<a
> href="mailto:dopey74@gmail.com">dopey74@gmail.com</a>&gt; wrote:<br>
> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204,
> 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div
> class="Ih2E3d">On Nov 23, 2007 12:10 PM, Mike Doty &lt;<a
> href="mailto:kingtaco@gentoo.org">kingtaco@gentoo.org</a>&gt; wrote:<br>

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.

I don't have a direct answer to your question, but FWIW if I were doing 
it...

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.

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.

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.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@lists.gentoo.org mailing list

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

[Volker Armin Hemmann]

On Donnerstag, 24. April 2008, Duncan wrote:

> 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.

since he sent both html&text the people who don't have html enabled mail 
clients should be fine. kmail can display the text part just fine. And if 
YOUR mail client can't deal with a multipart email, get a different one.

Andy, as long as you sent multipart, everything should be fine. People who 
care about bandwidth shouldn't subscribe to a high volume list anyway.
-- 
gentoo-amd64@lists.gentoo.org mailing list

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

[Peter Humphrey]

On Thursday 24 April 2008 04:20:11 Volker Armin Hemmann wrote:

> People who care about bandwidth shouldn't subscribe to a high volume list
> anyway. 

They're supposed to remain ignorant instead?

-- 
Rgds
Peter
-- 
gentoo-amd64@lists.gentoo.org mailing list

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

[Andy Wang]

On Wed, Apr 23, 2008 at 9:40 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> "Andy Wang" <dopey74@gmail.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@lists.gentoo.org mailing list

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

[Duncan]

"Andy Wang" <dopey74@gmail.com> posted
17dc8bc70804232143k1572c362pf1b3adfaa8d72f66@mail.gmail.com, excerpted
below, on  Wed, 23 Apr 2008 23:43:16 -0500:

> 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's a library search path issue, and would normally be solved by 
setting LDPATH appropriately.  For that, drop a file as appropriate in 
/etc/env.d/ (see the existing files already there), and remember to 
rebuild the libloader cache (/etc/ld.so.cache, running env-update does 
this among other things) afterward.

An exception would be plugins, as for firefox, etc.  For 32-bit 
executables with plugins, you'll need to properly configure their search 
path to look in the 32-bit location.

Of course, again, a chroot is a reasonably simple way to manage all 
this.  Let the 32-bit system run in a chroot so it sees its own 
/lib and /usr/lib just as it would on a normal 32-bit system, and mount 
--bind stuff like /home (probably /tmp too, and maybe part or all of 
/var) as appropriate, so it appears in the chroot location as well.  Then 
run all your 32-bit apps from the chrooted environment so they aren't 
looking at the 64-bit paths but instead their own (chrooted) 32-bit 
paths, and the setup I described should work, because as far as the 32-
bit system is concerned, it's running on its own machine and doesn't even 
know about nor can it see* the 64-bit system.

The 32-bit chroot method should be simpler and cleaner for the 64-bit 
system as well, which should then be perfectly fine running a no-multilib 
profile, with the exception of 32-bit execution turned on in the kernel, 
and a script that sets up the 32-bit stuff and enters the chroot.  No 
more conflicts between 32-bit and 64-bit executables with the same name, 
no having to prioritize either 32-bit or 64-bit libraries first in the 
search order, etc.

===
* "See" here is taken in the convenience sense, not the security sense.  
As with any chroot, it's possible for an app to escape the chroot if it 
tries to do so, particularly if it is running as root.  That shouldn't be 
an issue, however, in the purely convenience context of running the 
chroot simply to keep the 32-bit stuff from getting confused by the 64-
bit system.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@lists.gentoo.org mailing list

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

[Andy Wang]

On Thu, Apr 24, 2008 at 11:40 AM, Duncan <1i5t5.duncan@cox.net> wrote:

>  That's a library search path issue, and would normally be solved by
>  setting LDPATH appropriately.  For that, drop a file as appropriate in
>  /etc/env.d/ (see the existing files already there), and remember to
>  rebuild the libloader cache (/etc/ld.so.cache, running env-update does
>  this among other things) afterward.

No, LDPATH modifies the ld.so.conf, which affects runtime dynamic
linking.  It doesn't affect things that don't use the standard ld.so
dynamic linker.  To give you an example, take a look the gnome-vfs
package.  It places a bunch of binary files in
/usr/lib/gnome-vfs-2.0/modules.  The location to these libraries are
fixed during configure/compile time via the libpath location given to
configure.  I can screw with LDPATH and LD_LIBRARY_PATH all I want and
it won't make a bit of difference.

>  An exception would be plugins, as for firefox, etc.  For 32-bit
>  executables with plugins, you'll need to properly configure their search
>  path to look in the 32-bit location.

Sure, but not all applications allow you to reconfigure the module
location at runtime.  Many of the gnome libraries, such as gnome-vfs
that I gave as an example above, don't have a simple way of overriding
where it finds it's modules at runtime.

>  Of course, again, a chroot is a reasonably simple way to manage all
>  this.  Let the 32-bit system run in a chroot so it sees its own
>  /lib and /usr/lib just as it would on a normal 32-bit system, and mount
>  --bind stuff like /home (probably /tmp too, and maybe part or all of
>  /var) as appropriate, so it appears in the chroot location as well.  Then
>  run all your 32-bit apps from the chrooted environment so they aren't
>  looking at the 64-bit paths but instead their own (chrooted) 32-bit
>  paths, and the setup I described should work, because as far as the 32-
>  bit system is concerned, it's running on its own machine and doesn't even
>  know about nor can it see* the 64-bit system.
>
>  The 32-bit chroot method should be simpler and cleaner for the 64-bit
>  system as well, which should then be perfectly fine running a no-multilib
>  profile, with the exception of 32-bit execution turned on in the kernel,
>  and a script that sets up the 32-bit stuff and enters the chroot.  No
>  more conflicts between 32-bit and 64-bit executables with the same name,
>  no having to prioritize either 32-bit or 64-bit libraries first in the
>  search order, etc.

I don't really want to debates the merits of a multilib vs. chroot
system as it's not my point.  There are pros and cons for both.
Suffice it to say, I'm not happy with a chroot 32-bit environment I
don't think it's simpler and cleaner than a multilib environment and
it's not acceptable for me to have to deal with a 32-bit chroot
environment.  Until gentoo moves to a true multilib environment were
every library package can be built with both 32-bit and 64-bit I'm
more than happy to maintain my own emul-linux-x86-* packages.  I just
want to know how to do it in a way that's most like how the gentoo
devs are creating their packages.
-- 
gentoo-amd64@lists.gentoo.org mailing list

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

[Duncan]

"Andy Wang" <dopey74@gmail.com> posted
17dc8bc70804241228h5477551dp80cf1c687ebfed1a@mail.gmail.com, excerpted
below, on  Thu, 24 Apr 2008 14:28:01 -0500:

> Until gentoo moves to a true multilib environment were every library
> package can be built with both 32-bit and 64-bit I'm more than happy to
> maintain my own emul-linux-x86-* packages.  I just want to know how to
> do it in a way that's most like how the gentoo devs are creating their
> packages.

'Twould be nice if portage (or $PM) was full multi-arch, wouldn't it?

Meanwhile, I did say that's how I'd handle it.  It's not going to be 
"most like how the Gentoo devs are" handling it and I didn't claim it 
was, so it appears it's not suitable for your purposes if that indeed is 
a requirement.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@lists.gentoo.org mailing list