Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Gentoo: AMD64

Wine with no-multilib on AMD64

 

 

Gentoo amd64 RSS feed   Index | Next | Previous | View Threaded


mansour.alakeel at gmail

Mar 13, 2010, 6:15 AM

Post #1 of 17 (2204 views)
Permalink
Wine with no-multilib on AMD64

Hello all,

I have been looking into installing wine and a cross dev tool chain. I
didn't get much luck, since I have amd64 and I use no-multilib. I found
this http://bugs.gentoo.org/269439 and I am wondering if any one can
provide an advice. Is it be possible to run wine on amd64 with
no-multilib ?


volkerarmin at googlemail

Mar 13, 2010, 7:29 AM

Post #2 of 17 (2159 views)
Permalink
Re: Wine with no-multilib on AMD64 [In reply to]

On Samstag 13 Mrz 2010, Mansour Al Akeel wrote:
> Hello all,
>
> I have been looking into installing wine and a cross dev tool chain. I
> didn't get much luck, since I have amd64 and I use no-multilib. I found
> this http://bugs.gentoo.org/269439 and I am wondering if any one can
> provide an advice. Is it be possible to run wine on amd64 with
> no-multilib ?

you won't be able to run any 32bit windows app. Which makes wine pretty
useless.


1i5t5.duncan at cox

Mar 13, 2010, 2:20 PM

Post #3 of 17 (2162 views)
Permalink
Re: Wine with no-multilib on AMD64 [In reply to]

Volker Armin Hemmann posted on Sat, 13 Mar 2010 16:29:06 +0100 as
excerpted:

> On Samstag 13 März 2010, Mansour Al Akeel wrote:
>> Hello all,
>>
>> I have been looking into installing wine and a cross dev tool chain. I
>> didn't get much luck, since I have amd64 and I use no-multilib. I found
>> this http://bugs.gentoo.org/269439 and I am wondering if any one can
>> provide an advice. Is it be possible to run wine on amd64 with
>> no-multilib ?
>
> you won't be able to run any 32bit windows app. Which makes wine pretty
> useless.

FWIW, I have no-multilib, but with the 32-bit compatibility turned on in
the kernel, I'm able to do the 32-bit chroot thing as in the gentoo/amd64
documentation.

In my case, I'm doing a full 32-bit chroot image, which then gets
transferred to my AA1 netbook. (The big machine has far more memory and
power to do the compiles, so it makes more sense to do that and not even
have the gentoo tree on the netbook, just transfer over the prebuilt,
preconfigured image, and rsync it again after every update. I've never
booted the 32-bit image on the big machine, tho, and indeed, couldn't, as
the kernel drivers, etc, are all built-in and configured for the netbook.)

For just running 32-bit stuff on the same machine, tho, you'd not need the
full system image, as you'd be able to skip stuff like syslog and the
kernel, as they'd be 64-bit hosted.

That'd give you the 32-bit stuff including wine in its own little chroot,
fully built from source as any Gentooer should appreciate, without
dirtying up your 64-bit-clean no-mulilib main install as the 32-bit stuff
would be in its own chroot, and without the compromise of the prebuilt 32-
bit libraries the typical multilib installation uses. It's a bit more
work to keep updated than a multilib install, but because the main install
is 64-bit clean no-multilib, you don't have the broken 32-bit toolchain
issues that seem to strike many multilib users after awhile. (...that I
got tired of after a few times, and that I was VERY glad to be rid of,
when I dumped multilib myself.)

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


volkerarmin at googlemail

Mar 13, 2010, 3:27 PM

Post #4 of 17 (2162 views)
Permalink
Re: Re: Wine with no-multilib on AMD64 [In reply to]

On Samstag 13 März 2010, Duncan wrote:
> Volker Armin Hemmann posted on Sat, 13 Mar 2010 16:29:06 +0100 as
>
> excerpted:
> > On Samstag 13 März 2010, Mansour Al Akeel wrote:
> >> Hello all,
> >>
> >> I have been looking into installing wine and a cross dev tool chain. I
> >> didn't get much luck, since I have amd64 and I use no-multilib. I found
> >> this http://bugs.gentoo.org/269439 and I am wondering if any one can
> >> provide an advice. Is it be possible to run wine on amd64 with
> >> no-multilib ?
> >
> > you won't be able to run any 32bit windows app. Which makes wine pretty
> > useless.
>
> FWIW, I have no-multilib, but with the 32-bit compatibility turned on in
> the kernel, I'm able to do the 32-bit chroot thing as in the gentoo/amd64
> documentation.
>

so you wasted a lot of space. For what benefit again?

And - because you seem to lack some understanding. There is no 'dirtying up'.
So please, keep your dubios advise down. Chrooting just to be able to run an
app is not a good choice, if a few mb of 32bit libs, residing in /usr/lib32
would be all that is needed.

> It's a bit more work to keep updated than a multilib install,

yeah, that too. So lets keep honest, ok? no-multilib+chroot means more work on
maintenance, more work to set up. More compiling, more disk space wasted
for... zero benefits.

Hm, yeah, sounds really great.


realnc at arcor

Mar 13, 2010, 4:31 PM

Post #5 of 17 (2152 views)
Permalink
Re: Wine with no-multilib on AMD64 [In reply to]

On 03/14/2010 02:34 AM, Duncan wrote:
> Volker Armin Hemmann posted on Sun, 14 Mar 2010 00:27:20 +0100 as
> excerpted:
>
>> so you wasted a lot of space. For what benefit again?
>
> What, you can't even read? In the same message you quoted part of, I
> explained why -- I build my (32-bit only) netbook image in that chroot, on
> my main machine. I then rsync the completely build and configured image
> to my netbook, thus allowing me to run Gentoo on the netbook without
> having to actually /build/ Gentoo on the netbook.

This thread is about running Wine though, not about building a 32bit
Gentoo image on AMD64 :P


1i5t5.duncan at cox

Mar 13, 2010, 4:34 PM

Post #6 of 17 (2167 views)
Permalink
Re: Wine with no-multilib on AMD64 [In reply to]

Volker Armin Hemmann posted on Sun, 14 Mar 2010 00:27:20 +0100 as
excerpted:

> so you wasted a lot of space. For what benefit again?

What, you can't even read? In the same message you quoted part of, I
explained why -- I build my (32-bit only) netbook image in that chroot, on
my main machine. I then rsync the completely build and configured image
to my netbook, thus allowing me to run Gentoo on the netbook without
having to actually /build/ Gentoo on the netbook.

> And - because you seem to lack some understanding. There is no 'dirtying
> up'. So please, keep your dubios advise down. Chrooting just to be able
> to run an app is not a good choice, if a few mb of 32bit libs, residing
> in /usr/lib32 would be all that is needed.

Well, depending on what you consider dirtying it up. If you consider
unnecessarily installing a somewhat brittle dual-bitness toolchain that
has an annoying tendency to have the 32-bit side break at times "dirtying
up", if you consider it installing only generically optimized 32-bit
binary-only emul-linux libraries "dirtying up", then yes, it's definitely
"dirtying up". Certainly so as opposed to a separate full 32-bit chroot,
thus allowing the 64-bit side to stay clean 64-bit (no brittle dual-
bitness toolchain), and no compromise only generic optimizations binary
emul-linux libraries.

Now a 32-bit chroot is definitely more work than standard multilib, but
it's also definitely cleaner, and from personal experience, less brittle.
It's also far more flexible. Whether it's worth the tradeoff is for an
individual to decide.

I was simply posting that the 32-bit chroot thing is possible with
no-multilib, something that's poorly documented, so some people might not
realize it's even possible. (They may think that multilib is required for
it.)

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


mansour.alakeel at gmail

Mar 15, 2010, 11:04 AM

Post #7 of 17 (2148 views)
Permalink
Re: Re: Wine with no-multilib on AMD64 [In reply to]

Hello Duncan:
Pleae read my comments.

On Sat Mar 13,2010 10:20 pm, Duncan wrote:
> Volker Armin Hemmann posted on Sat, 13 Mar 2010 16:29:06 +0100 as
> excerpted:
>
> > On Samstag 13 M??rz 2010, Mansour Al Akeel wrote:
> >> Hello all,
> >>
> >> I have been looking into installing wine and a cross dev tool chain. I
> >> didn't get much luck, since I have amd64 and I use no-multilib. I found
> >> this http://bugs.gentoo.org/269439 and I am wondering if any one can
> >> provide an advice. Is it be possible to run wine on amd64 with
> >> no-multilib ?
> >
> > you won't be able to run any 32bit windows app. Which makes wine pretty
> > useless.
>
> FWIW, I have no-multilib, but with the 32-bit compatibility turned on in
> the kernel, I'm able to do the 32-bit chroot thing as in the gentoo/amd64
> documentation.
>
> In my case, I'm doing a full 32-bit chroot image, which then gets
> transferred to my AA1 netbook. (The big machine has far more memory and
> power to do the compiles, so it makes more sense to do that and not even
> have the gentoo tree on the netbook, just transfer over the prebuilt,
> preconfigured image, and rsync it again after every update. I've never
> booted the 32-bit image on the big machine, tho, and indeed, couldn't, as
> the kernel drivers, etc, are all built-in and configured for the netbook.)

Are you saying that you have another 32bit gentoo image, and you mount it
somewhere and chroot to it? If so, what does the memory has to do with this ?
Can you please elaborate on this ? The space is not a concern to me, but
I'd rather not mix 32 and 64 libs.

>
> For just running 32-bit stuff on the same machine, tho, you'd not need the
> full system image, as you'd be able to skip stuff like syslog and the
> kernel, as they'd be 64-bit hosted.
>
> That'd give you the 32-bit stuff including wine in its own little chroot,
> fully built from source as any Gentooer should appreciate, without
> dirtying up your 64-bit-clean no-mulilib main install as the 32-bit stuff
> would be in its own chroot, and without the compromise of the prebuilt 32-
> bit libraries the typical multilib installation uses. It's a bit more
> work to keep updated than a multilib install, but because the main install
> is 64-bit clean no-multilib, you don't have the broken 32-bit toolchain
> issues that seem to strike many multilib users after awhile. (...that I
> got tired of after a few times, and that I was VERY glad to be rid of,
> when I dumped multilib myself.)
>
> --
> 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
>
>


1i5t5.duncan at cox

Mar 15, 2010, 6:56 PM

Post #8 of 17 (2140 views)
Permalink
Re: Wine with no-multilib on AMD64 [In reply to]

Mansour Al Akeel posted on Mon, 15 Mar 2010 15:04:49 -0300 as excerpted:

> Hello Duncan:
> Pleae read my comments.
>
> On Sat Mar 13,2010 10:20 pm, Duncan wrote:
>> Volker Armin Hemmann posted on Sat, 13 Mar 2010 16:29:06 +0100 as
>> excerpted:
>>
>> > On Samstag 13 M??rz 2010, Mansour Al Akeel wrote:
>> >> Hello all,
>> >>
>> >> I have been looking into installing wine and a cross dev tool chain.
>> >> I didn't get much luck, since I have amd64 and I use no-multilib. I
>> >> found this http://bugs.gentoo.org/269439 and I am wondering if any
>> >> one can provide an advice. Is it be possible to run wine on amd64
>> >> with no-multilib ?
>> >
>> > you won't be able to run any 32bit windows app. Which makes wine
>> > pretty useless.
>>
>> FWIW, I have no-multilib, but with the 32-bit compatibility turned on
>> in the kernel, I'm able to do the 32-bit chroot thing as in the
>> gentoo/amd64 documentation.
>>
>> In my case, I'm doing a full 32-bit chroot image, which then gets
>> transferred to my AA1 netbook. (The big machine has far more memory
>> and power to do the compiles, so it makes more sense to do that and not
>> even have the gentoo tree on the netbook, just transfer over the
>> prebuilt, preconfigured image, and rsync it again after every update.
>> I've never booted the 32-bit image on the big machine, tho, and indeed,
>> couldn't, as the kernel drivers, etc, are all built-in and configured
>> for the netbook.)
>
> Are you saying that you have another 32bit gentoo image, and you mount
> it somewhere and chroot to it? If so, what does the memory has to do
> with this ? Can you please elaborate on this ? The space is not a
> concern to me, but I'd rather not mix 32 and 64 libs.

Yes. I have a 32-bit chroot image that gets mounted and chrooted into
(using linux32 chroot ...) as per the gentoo/amd64 32-bit chroot guide.
That works just fine with no-multilib, and indeed, multilib would
duplicate functionality to some degree. Just make sure your kernel has
32-bit "emulation" turned on (tho it's not really emulation, in the same
way that wine is not an emulator, amd64/x86_64 is true dual-bitness
hardware).

I posted the link to the guide in the doomsday thread pretty much
concurrently to the discussion here, but for convenience, here's the link:

http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=2

That explains the process and covers the step-by-step quite nicely. I
discuss it in more depth in the doomsday thread, so I'd suggest you read
it if you're seriously interested in this. Meanwhile...

As mentioned, I use the 32-bit chroot for a somewhat different purpose,
building a separate 32-bit image to run on my 32-bit-only netbook. As
such, I have a fully configured and bootable build-out of the 32-bit as if
it were an entirely separate machine, even if I never boot to it on this
machine, because it is intended to run on a separate machine. However,
while that's a reasonably trivial extension from the 32-bit chroot guide,
it's not why it was written, nor what it directly addresses. But as you
specify, it's definitely entirely separate, no mixed 32/64-bit as multilib
does, or it'd be unsuitable for the 32-bit-only machine usage to which I
put it. So rest assured on that point. The only mixing between the two
systems are mount-binds setup to expose stuff like a common tempdir
between the two systems (and of course that you happen to be running on a
64-bit host kernel in the first place), and it's relatively trivial to
simply not mount-bind what you specifically don't need. If you're
familiar with chroots, mount-binds for access within the chroot are pretty
standard stuff, and it /is/ a chroot, so it's as entirely separate as a
chroot normally would be.

As to your specific question "what does the memory have to do with this?",
I don't quite understand the question, so pardon my not answering it
specifically.

Unless of course you're referring to the fact that you can't normally
combine 32-bit apps with 64-bit libs, or the reverse, a typical source of
newbie confusion (and quite some emerge bugs when the build happens across
the wrong bitness lib before it sees the correct one) on multilib setups.

That, IMO, is one of the advantages of the separate 32-bit chroot concept,
particularly with no-multilib. The main 64-bit system basically doesn't
know it's there, it's just data to it, and the 32-bit chroot of course
only knows about the parts of the 64-bit system that you've exposed to it
thru bind-mounts, so there's very little chance of getting things mixed
up, unless you deliberately mount a 64-bit libdir into the chroot or
something, and as Gentooers should know by now, Gentoo does specifically
allow you to (metaphorically) point a loaded gun at yourself and pull the
trigger if you want, which is about what deliberately mounting a 64-bit
libdir into the chroot would be doing.

So... read my detailed response in the doomsday thread and the chroot
guide, and that should give you a far better idea of whether what we're
talking about is useful for you or not.

Personally, I don't know. Honestly, it's definitely a lot of work,
perhaps more than you're willing to put into it.

You might be able to do what you want, and would arguably be better off,
switching to a multilib profile and starting with a standard 64-bit
stage-3 tarball again, to rebuild your Linux-side toolchain as multilib.
That'll be some work now, but will definitely be less work maintaining
than a 32-bit chroot. Unfortunately I don't know enough about the wine
and MS platform cross-dev toolchain bit to evaluate what problems you
might or might not have with that. I'm simply assuming it'll "just work"
with a multilib profile, but that's a best-case assumption.

OTOH, the 32-bit chroot concept, while definitely more work maintaining
(it's roughly comparable work immediately to switching back to multilib,
starting again from a standard multilib-compatible amd64 stage-3 tarball,
but the 32-bit chroot will be more work maintaining over time as you'll be
having to update stuff both on the main machine and in the chroot), *IS* a
cleaner, more logically separate, solution. And, installing a 32-bit wine/
MS-platform cross-dev is much more likely a known quantity with any bug
you might happen across much more common, than the dual bitness multilib
concept.

The thought occurs to me that it may hinge on 64-bit MS cross-dev status
and whether you anticipate doing both 32-bit and 64-bit development, or
only 32-bit. It's possible multilib would enable both, while you'd very
likely have to have separate 32-bit and 64-bit cross-dev arrangements too,
if your Linux host is separate 32-bit and 64-bit, as with the chroot
solution. If you're not interested in the 64-bit MS side at all, that's
not an issue. Likewise if your cross-dev solution doesn't include a
64-bit MS side at all. But if you are and it does, then going the
separate 32-bit chroot route on the Linux side probably necessitates a
separate cross-dev for each as well, thus an even higher continuing
maintenance burden choosing the separate chroot route.

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


sebastian at darkmetatron

Mar 16, 2010, 2:23 AM

Post #9 of 17 (2127 views)
Permalink
Re: Re: Wine with no-multilib on AMD64 [In reply to]

Am 16.03.2010 02:56, schrieb Duncan:

> I posted the link to the guide in the doomsday thread pretty much
> concurrently to the discussion here, but for convenience, here's the link:
>
> http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=2

What I don't like with this guide is that you have to be root to chroot
into and run the applications as root inside of the chroot.

schroot could be a way to get around this, but I can't test because
schroot fails to build here. So atm I try something with a sshd running
inside the chroot.

I think the guide should be extended to cover one way or more. Maybe
when done with it I write something with my experiences, problems and
solutions.

Greetings

Sebastian


realnc at arcor

Mar 16, 2010, 4:01 AM

Post #10 of 17 (2134 views)
Permalink
Re: Wine with no-multilib on AMD64 [In reply to]

On 03/16/2010 11:23 AM, Sebastian Beßler wrote:
> Am 16.03.2010 02:56, schrieb Duncan:
>
>> I posted the link to the guide in the doomsday thread pretty much
>> concurrently to the discussion here, but for convenience, here's the link:
>>
>> http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=2
>
> What I don't like with this guide is that you have to be root to chroot
> into and run the applications as root inside of the chroot.

Wait a minute. You're telling me that all the people who posted that
they use chroot in order to have a "clean 64bit" system are actually
running all their 32bit application as root and still consider the
chroot a viable alternative to multilib?

I have only one word to describe this:

PHAIL.


wired at gentoo

Mar 16, 2010, 4:22 AM

Post #11 of 17 (2130 views)
Permalink
Re: Re: Wine with no-multilib on AMD64 [In reply to]

On Tue, Mar 16, 2010 at 10:23:06AM +0100, Sebastian Beler wrote:
> Am 16.03.2010 02:56, schrieb Duncan:
>
> > I posted the link to the guide in the doomsday thread pretty much
> > concurrently to the discussion here, but for convenience, here's the link:
> >
> > http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=2
>
> What I don't like with this guide is that you have to be root to chroot
> into and run the applications as root inside of the chroot.

You don't need to be root in the chroot to run applications. Just create
a user in the chroot and switch:

su - youruser

--
Alex Alexander :: wired
Gentoo Developer
www.linuxized.com


sebastian at darkmetatron

Mar 16, 2010, 5:15 AM

Post #12 of 17 (2129 views)
Permalink
Re: Re: Wine with no-multilib on AMD64 [In reply to]

Am Dienstag, 16. März 2010 12:01:38 schrieb Nikos Chantziaras:
> On 03/16/2010 11:23 AM, Sebastian Beßler wrote:
> > Am 16.03.2010 02:56, schrieb Duncan:
> >> I posted the link to the guide in the doomsday thread pretty much
> >> concurrently to the discussion here, but for convenience, here's the
> >> link:
> >>
> >> http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=2
> >
> > What I don't like with this guide is that you have to be root to chroot
> > into and run the applications as root inside of the chroot.
>
> Wait a minute. You're telling me that all the people who posted that
> they use chroot in order to have a "clean 64bit" system are actually
> running all their 32bit application as root and still consider the
> chroot a viable alternative to multilib?

If you follow the guide word by word and do nothing more then:
Yes, as far as I understand the guide. But it is "only" root in a chroot.. I
know that is not better at all.

> I have only one word to describe this:
>
> PHAIL.

Exactly that is why I work something out to use my user account inside the
chroot. I need the 32bit chroot because I have still some programms that I
can't get to work with multilib on Gentoo. I tried already the multilib-
overlay but that was a total failure for me.

Oh and I do it because I really like to try new (new for me at last) stuff all
the time, if it is complicated then it is only better.. ;-) Thats why I love
Gentoo, you can break so much so easy :-D

Greetings

Sebastian


1i5t5.duncan at cox

Mar 16, 2010, 5:50 AM

Post #13 of 17 (2135 views)
Permalink
Re: Wine with no-multilib on AMD64 [In reply to]

Nikos Chantziaras posted on Tue, 16 Mar 2010 13:01:38 +0200 as excerpted:

> On 03/16/2010 11:23 AM, Sebastian Beßler wrote:
>> Am 16.03.2010 02:56, schrieb Duncan:
>>
>>> I posted the link to the guide in the doomsday thread pretty much
>>> concurrently to the discussion here, but for convenience, here's the
>>> link:
>>>
>>> http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=2
>>
>> What I don't like with this guide is that you have to be root to chroot
>> into and run the applications as root inside of the chroot.
>
> Wait a minute. You're telling me that all the people who posted that
> they use chroot in order to have a "clean 64bit" system are actually
> running all their 32bit application as root and still consider the
> chroot a viable alternative to multilib?
>
> I have only one word to describe this:
>
> PHAIL.

Actually, neither the invoking nor the invoked side are root here. Here's
how I handle it.

1) I use chroot's --userspec=UID:GID option so I end up as the specified
user -- not root -- in the chroot. The guide doesn't mention this,
unfortunately, but the chroot manpage does, and when I got tired of su-ing
back to a normal user, it was easy enough to lookup, and then to change my
invoking scripts, accordingly. =:^)

2) On the invoking side, I have sudo setup to authorize the specific
linux32 chroot command used, so while it's executed as root, the user
never sees it, and sudo can be set to only allow that specific command
with those specific parameters (including the --userspec bit), so that
bit's reasonably locked down.

3) Since the allowed command is a fixed string of some length, it makes
sense to setup either a scriptlet or an alias, invoked with a much shorter
command. Since in my case, the chroot is the image for my Acer Aspire One
netbook, I use the scriptlet name "aastart".

4) I also scripted the chroot setup, called "aamount", that handles all
the bind-mounts, etc, and have that invokable using sudo as well. I
separated the setup from the actual chroot entry command as it can be
useful to run multiple sessions, all in the same chroot. So I run the
setup script once, and can then run aastart multiple times as desired.
There's a similar "aaumount" script that tears down the setup, umounting
all the mount-binds, etc.

But you're right that the --userspec bit should really be documented in
the guide.

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


mansour.alakeel at gmail

Mar 16, 2010, 7:51 AM

Post #14 of 17 (2152 views)
Permalink
Re: Re: Wine with no-multilib on AMD64 [In reply to]

Thank you Duncan,
I checked this yesterday. In fact I was considering the idea of a
chroot last. And I didn't know there's a guide for it. The guide served
as a refrence in case I forgot something.

In my case, having a separate 32 bit is a better option, since I have a
huge external hard disk, and use it mostely as a bootable server for
development and testing. In case I run low on resources on my laptop, I
just plug this usb drive in any PC and I have a fully running server to
deploy and test. After all, I don't that the chroot, is taking a lot of
room on my disk, and I'd rather not to use multilib for bad experience I
had with it, few years ago.

Things are working great for now.


On Tue Mar 16,2010 01:56 am, Duncan wrote:
> Mansour Al Akeel posted on Mon, 15 Mar 2010 15:04:49 -0300 as excerpted:
>
> > Hello Duncan:
> > Pleae read my comments.
> >
> > On Sat Mar 13,2010 10:20 pm, Duncan wrote:
> >> Volker Armin Hemmann posted on Sat, 13 Mar 2010 16:29:06 +0100 as
> >> excerpted:
> >>
> >> > On Samstag 13 M??rz 2010, Mansour Al Akeel wrote:
> >> >> Hello all,
> >> >>
> >> >> I have been looking into installing wine and a cross dev tool chain.
> >> >> I didn't get much luck, since I have amd64 and I use no-multilib. I
> >> >> found this http://bugs.gentoo.org/269439 and I am wondering if any
> >> >> one can provide an advice. Is it be possible to run wine on amd64
> >> >> with no-multilib ?
> >> >
> >> > you won't be able to run any 32bit windows app. Which makes wine
> >> > pretty useless.
> >>
> >> FWIW, I have no-multilib, but with the 32-bit compatibility turned on
> >> in the kernel, I'm able to do the 32-bit chroot thing as in the
> >> gentoo/amd64 documentation.
> >>
> >> In my case, I'm doing a full 32-bit chroot image, which then gets
> >> transferred to my AA1 netbook. (The big machine has far more memory
> >> and power to do the compiles, so it makes more sense to do that and not
> >> even have the gentoo tree on the netbook, just transfer over the
> >> prebuilt, preconfigured image, and rsync it again after every update.
> >> I've never booted the 32-bit image on the big machine, tho, and indeed,
> >> couldn't, as the kernel drivers, etc, are all built-in and configured
> >> for the netbook.)
> >
> > Are you saying that you have another 32bit gentoo image, and you mount
> > it somewhere and chroot to it? If so, what does the memory has to do
> > with this ? Can you please elaborate on this ? The space is not a
> > concern to me, but I'd rather not mix 32 and 64 libs.
>
> Yes. I have a 32-bit chroot image that gets mounted and chrooted into
> (using linux32 chroot ...) as per the gentoo/amd64 32-bit chroot guide.
> That works just fine with no-multilib, and indeed, multilib would
> duplicate functionality to some degree. Just make sure your kernel has
> 32-bit "emulation" turned on (tho it's not really emulation, in the same
> way that wine is not an emulator, amd64/x86_64 is true dual-bitness
> hardware).
>
> I posted the link to the guide in the doomsday thread pretty much
> concurrently to the discussion here, but for convenience, here's the link:
>
> http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=2
>
> That explains the process and covers the step-by-step quite nicely. I
> discuss it in more depth in the doomsday thread, so I'd suggest you read
> it if you're seriously interested in this. Meanwhile...
>
> As mentioned, I use the 32-bit chroot for a somewhat different purpose,
> building a separate 32-bit image to run on my 32-bit-only netbook. As
> such, I have a fully configured and bootable build-out of the 32-bit as if
> it were an entirely separate machine, even if I never boot to it on this
> machine, because it is intended to run on a separate machine. However,
> while that's a reasonably trivial extension from the 32-bit chroot guide,
> it's not why it was written, nor what it directly addresses. But as you
> specify, it's definitely entirely separate, no mixed 32/64-bit as multilib
> does, or it'd be unsuitable for the 32-bit-only machine usage to which I
> put it. So rest assured on that point. The only mixing between the two
> systems are mount-binds setup to expose stuff like a common tempdir
> between the two systems (and of course that you happen to be running on a
> 64-bit host kernel in the first place), and it's relatively trivial to
> simply not mount-bind what you specifically don't need. If you're
> familiar with chroots, mount-binds for access within the chroot are pretty
> standard stuff, and it /is/ a chroot, so it's as entirely separate as a
> chroot normally would be.
>
> As to your specific question "what does the memory have to do with this?",
> I don't quite understand the question, so pardon my not answering it
> specifically.
>
> Unless of course you're referring to the fact that you can't normally
> combine 32-bit apps with 64-bit libs, or the reverse, a typical source of
> newbie confusion (and quite some emerge bugs when the build happens across
> the wrong bitness lib before it sees the correct one) on multilib setups.
>
> That, IMO, is one of the advantages of the separate 32-bit chroot concept,
> particularly with no-multilib. The main 64-bit system basically doesn't
> know it's there, it's just data to it, and the 32-bit chroot of course
> only knows about the parts of the 64-bit system that you've exposed to it
> thru bind-mounts, so there's very little chance of getting things mixed
> up, unless you deliberately mount a 64-bit libdir into the chroot or
> something, and as Gentooers should know by now, Gentoo does specifically
> allow you to (metaphorically) point a loaded gun at yourself and pull the
> trigger if you want, which is about what deliberately mounting a 64-bit
> libdir into the chroot would be doing.
>
> So... read my detailed response in the doomsday thread and the chroot
> guide, and that should give you a far better idea of whether what we're
> talking about is useful for you or not.
>
> Personally, I don't know. Honestly, it's definitely a lot of work,
> perhaps more than you're willing to put into it.
>
> You might be able to do what you want, and would arguably be better off,
> switching to a multilib profile and starting with a standard 64-bit
> stage-3 tarball again, to rebuild your Linux-side toolchain as multilib.
> That'll be some work now, but will definitely be less work maintaining
> than a 32-bit chroot. Unfortunately I don't know enough about the wine
> and MS platform cross-dev toolchain bit to evaluate what problems you
> might or might not have with that. I'm simply assuming it'll "just work"
> with a multilib profile, but that's a best-case assumption.
>
> OTOH, the 32-bit chroot concept, while definitely more work maintaining
> (it's roughly comparable work immediately to switching back to multilib,
> starting again from a standard multilib-compatible amd64 stage-3 tarball,
> but the 32-bit chroot will be more work maintaining over time as you'll be
> having to update stuff both on the main machine and in the chroot), *IS* a
> cleaner, more logically separate, solution. And, installing a 32-bit wine/
> MS-platform cross-dev is much more likely a known quantity with any bug
> you might happen across much more common, than the dual bitness multilib
> concept.
>
> The thought occurs to me that it may hinge on 64-bit MS cross-dev status
> and whether you anticipate doing both 32-bit and 64-bit development, or
> only 32-bit. It's possible multilib would enable both, while you'd very
> likely have to have separate 32-bit and 64-bit cross-dev arrangements too,
> if your Linux host is separate 32-bit and 64-bit, as with the chroot
> solution. If you're not interested in the 64-bit MS side at all, that's
> not an issue. Likewise if your cross-dev solution doesn't include a
> 64-bit MS side at all. But if you are and it does, then going the
> separate 32-bit chroot route on the Linux side probably necessitates a
> separate cross-dev for each as well, thus an even higher continuing
> maintenance burden choosing the separate chroot route.
>
> --
> 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
>
>


mansour.alakeel at gmail

Mar 16, 2010, 7:54 AM

Post #15 of 17 (2123 views)
Permalink
Re: Re: Wine with no-multilib on AMD64 [In reply to]

When you change root, just swith to the user you want. For example,

su mansour.




On Tue Mar 16,2010 10:23 am, Sebastian Be??ler wrote:
> Am 16.03.2010 02:56, schrieb Duncan:
>
> > I posted the link to the guide in the doomsday thread pretty much
> > concurrently to the discussion here, but for convenience, here's the link:
> >
> > http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=2
>
> What I don't like with this guide is that you have to be root to chroot
> into and run the applications as root inside of the chroot.
>
> schroot could be a way to get around this, but I can't test because
> schroot fails to build here. So atm I try something with a sshd running
> inside the chroot.
>
> I think the guide should be extended to cover one way or more. Maybe
> when done with it I write something with my experiences, problems and
> solutions.
>
> Greetings
>
> Sebastian
>


mansour.alakeel at gmail

Mar 16, 2010, 2:18 PM

Post #16 of 17 (2142 views)
Permalink
Re: Re: Wine with no-multilib on AMD64 [In reply to]

One last quesiton related to the cross compiler. I find the documentaion
for this are incomplete, and not very clear, and in many cases links are
broken. I have followed this page to get mingw ready:
http://www.gentoo-wiki.info/MinGW

I am not using any overlay. So things should be simple. I am using the
xmerge script and "export SYSROOT=/usr/i686-mingw32/"

$ cat /etc/make.conf
CFLAGS="-O2 -march=athlon-xp -msse2 -pipe -fomit-frame-pointer"
CXXFLAGS="${CFLAGS}"
CHOST="i686-pc-linux-gnu"
MAKEOPTS="-j2"
PORTDIR_OVERLAY="/usr/local/portage"




$ cat /usr/i686-mingw32/etc/make.conf
ARCH="i686"
CFLAGS="-Os -pipe"
CXXFLAGS="${CFLAGS}"
CHOST="i686-mingw32"
INPUT_DEVICES="keyboard"
MAKEOPTS="-j2"
USE="symlink"


When I try to install dbus, I get this:
$ xmerge dbus

!!! /usr/i686-mingw32/etc/make.profile is not a symlink and will probably prevent most merges.
!!! It should point into a profile within /usr/portage/profiles/
!!! (You can safely ignore this message when syncing. It's harmless.)


!!! If you have just changed your profile configuration, you should revert
!!! back to the previous configuration. Due to your current profile being
!!! invalid, allowed actions are limited to --help, --info, --sync, and
!!! --version.


What does this mean, and what should be the profile to use.
Again, I am running under amd64 (intel i5), and chroot to 32bit
enviroment. I want to compile for windows.

Thank you.


1i5t5.duncan at cox

Mar 16, 2010, 4:47 PM

Post #17 of 17 (2129 views)
Permalink
Re: Wine with no-multilib on AMD64 [In reply to]

Mansour Al Akeel posted on Tue, 16 Mar 2010 18:18:02 -0300 as excerpted:

> One last quesiton related to the cross compiler.

That one's out of my domain. If no one answers it, consider posting as a
new thread, as it's no longer no-multilib related, and for philosophical
reasons I stay as far away from proprietaryware including MS as I can get.

Also note that within the chroot, you're effectively running 32-bit only,
so if necessary you can post to the general user list and/or to the
forums, and x86 user answers will normally apply to you as well.

--
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 RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.