building 32 bit stuff on multilib ... official howto ?

[gringo]

Hi all,

yes, i know this has been asked probably hundreds of times, but i have not seen an official or deffinitive answer and would also like to know what is the current state of this stuff.
I will summarize the different ways i´m aware of :

1) eselect-compiler : masked for years and broken, not usable anymore. Was my preferred solution, it apparently worked just fine here til a month ago.
2) stage & chroot : use a 32 bit stage to build your stuff, works great but bloats the system imo.
3) crossdev : looks like another bloated solution, i always supposed that multilib was not about just running 32 & 64 bits stuff, but also having support to build for both.
4) ABI switch in portage. This apparently doesn´t work at all for me, either it breaks when linking or it installs to the wrong place. Haven´t playied much with this.

There are also the gcc switches, but i never playied much with this either, same behaviour like solution 4.
I´m currently using workaround 2 with x86 uclibc stages and it works just fine afaict ( for uclibc you have no other option than using specific stages anyways).

But i miss a definitive answer to what the official way of building this stuff is or what others do to build their stuff. So, can anyone enlighten me please ?
Apologies if this has been already discussed somewhere or if my assumptions are wrong.

cheers

[John Klug]

I have been wondering about that too. I am trying to build the latest grub, so I need lib32 ncurses, lzo, and gpm.

I have been using a lib32 use flag to create the 32 bit libraries, but this causes the deletion of the 64 bit libraries, which I save and restore by hand.

I got this idea from the bug report 161875 on grub, because it required 32 bit lzo (not to mention ncurses and gpm).

Basically you create a /usr/local/portage, and copy the files and a new revision of the emerge file (you should delete the old .emerge files).

Add the following edits to *.emerge:

To the IUSE line, add lib32. For ncurses:

• IUSE="bootstrap build debug doc gpm minimal nocxx profile trace unicode lib32"

In the src_compile() procedure, add the following:

• rc_compile() {
  # start of added code
  if use lib32 ; then
  ABI_ALLOW="x86"
  ABI="x86"
  fi
  #end of added code
  ...

Then do:

• ebuild ncurses-x.y.z-rw.ebuild digest
  env USE=lib32 emerge -v =ncurses-x.y.z-rw

I suspect this isn't too practical if you need large number of packages, but it does cause the correct library location to be installed, but too bad about the deletion of the other library depending on whether you set lib32 or not during emerge. This was most annoying when I found out that emerge depends on the lib64 version of ncurses, but I got it back from my stage3. If anybody knows how to prevent deletions of files that won't be overwritten during emerge when a use flag is changed, I would like to know. I suppose there must be a way ...

I just noticed a preserve-lib feature (but where is the doc):
Maurius Mauch 14 June, 2007

[gringo]

cool, thanks for that I playied just a bit with the ABI switches, will try out probably next weekend and see how it works !

If anybody knows how to prevent deletions of files that won't be overwritten during emerge when a use flag is changed, I would like to know. I suppose there must be a way ...

good question, would like to know that too.

I guess i will forward this to the mailing lists, hopefully someone there can helps us a bit more.

cheers

[Vash63]

I'd love to see something like this. I want to compile my own version of mplayer that can play both win32codecs (not available on amd64) and faad (not available in the 32-bit emulation library).

[beandog]

Hi all,

yes, i know this has been asked probably hundreds of times, but i have not seen an official or deffinitive answer and would also like to know what is the current state of this stuff.

Dunno if this will help or not

http://www.gentoo.org/proj/en/base/amd64/emul/index.xml

[gringo]

thanks for your answer beandog.

Actually i was asking what is the current state of building 32bit apps in the multilib environment. As i said above a chroot looks like a bloated solution to me, i always thought multilib can run and build 32bit stuff, so why do i have to set up another environment to just build 32bit apps ?
I personnally don´t need 32bit apps in my multilib gentoo, i mostly just want to build apps for other x86 boxes. But hey, having the possibility to chose which abi you want to use when building, or having a 32bit and 64 bit version of the same software installed would actually be a cool feature.

It looks quite hacky and tricky to have both 32bit and 64bit versions of the same app installed in the same system, i know, but just building a 32 bit app in a multilib environment shouldn´t be that hard, the hardware can do it, the toolchain can apparently do it, so why can´t portage handle it ? Or maybe it already does it accurately and im just saying BS, i just don´t know, the ABI switches are there already f.ex.

So, do you know if there is something cooking or are there any docs apart from reading eclasses ?
No bitching intended BTW, just would like to know what can be done out of the box and what not in the current multilib profile.

thanks

[beandog]

Actually i was asking what is the current state of building 32bit apps in the multilib environment.

You mean like the amd64 team building stuff? Beats me. Ask in #gentoo-amd64, I dunno who works on that stuff.

As i said above a chroot looks like a bloated solution to me, i always thought multilib can run and build 32bit stuff, so why do i have to set up another environment to just build 32bit apps ?

Because you're linking against other 32-bit apps.

[gringo]

took me while to find the link -> http://dev.gentoo.org/~kanaka/auto-multilib/

thats more or less what i was trying to explain. It would be just so cool to do something like :

ABI="x86" emerge -B openssh"

and have the binaries ready to distribute f.ex.
Apart from other possibilities of course.

thanks

[Naib]

Hi all,

yes, i know this has been asked probably hundreds of times, but i have not seen an official or deffinitive answer and would also like to know what is the current state of this stuff.

Dunno if this will help or not

http://www.gentoo.org/proj/en/base/amd64/emul/index.xml

And THAT is completely broken
stage tarball's have that nice expat timebomb sitting waiting as well as a load of other issues when following this "guide"
I say "guide" cause it doesn't actually work. I filed a bug w.r.t. to this and the response I got is only dev's should be using this

goo userrel \o/