Reply
Thread Tools
Posts: 2 | Thanked: 0 times | Joined on Dec 2011
#181
Hi Friend

I did it. It's my mistake on some operation. Thank you very much!

Best
 
Posts: 43 | Thanked: 18 times | Joined on May 2010 @ Sydney
#182
Originally Posted by orokusaki View Post
what to do with wine.tar.gz www.onsitedentalsystems.com/wine.tar.gz
Hi.

Thanks for the tarball.

It works quite well for me as well.

Do you mind telling us how you built this wine? Is there any special options that has to be enabled or disabled? Or is it just a simple ./configure && make?

Also, any special patches needed? And is that a straight x86 build?

And what about versions of wine? The version from you is 0.9.14. I'm interested in trying a different version of wine too.

Thanks!

Last edited by pigeond; 02-28-2012 at 05:13 PM.
 

The Following User Says Thank You to pigeond For This Useful Post:
Posts: 43 | Thanked: 18 times | Joined on May 2010 @ Sydney
#183
FWIW, I've successfully built my own wine, using 0.9.14 source. Plain x86 native build, and managed to run it with the qemu-i386 you provided.

The only extra bit is I had to update my libs (things like X libs, gtk, etc) from my build tree
 
Posts: 43 | Thanked: 18 times | Joined on May 2010 @ Sydney
#184
Got a question regarding wine versions.

While 0.9.14 kinda works, it's pretty old. I tried using newer versions, but they don't split the binaries into wine and wine-pthread anymore. Looking at the changelog, the default should be using pthread, but then when I try to run it, it seems to behave like the "wine" binary of 0.9.14, which doesn't run at all.

Perhaps I haven't been following this thread completely, was there a reason why only wine-pthread works, but not wine?

Thanks.

(Am I the only one still playing with i386 + wine now?)

Last edited by pigeond; 03-03-2012 at 07:57 PM.
 
Posts: 184 | Thanked: 149 times | Joined on Jul 2011
#185
Originally Posted by pigeond View Post
Got a question regarding wine versions.

While 0.9.14 kinda works, it's pretty old. I tried using newer versions, but they don't split the binaries into wine and wine-pthread anymore. Looking at the changelog, the default should be using pthread, but then when I try to run it, it seems to behave like the "wine" binary of 0.9.14, which doesn't run at all.

Perhaps I haven't been following this thread completely, was there a reason why only wine-pthread works, but not wine?

Thanks.

(Am I the only one still playing with i386 + wine now?)
You probably are buddy This is pretty old I still play with it each time in a while but no too much.
If I am not wrong a newer version of wine requires NPTL which doesnt work with qemu (it apparently does with newer versions such as 1.0 or 1.0.1 of qemu where you can force it in the configuration but they dont compile good with the old C compiler/library, havn't looked into it much though, if you compile tell me). Take into account the new wine executable has the wine-pthread shoved into it so running an old wine-pthread is like running an old wine executable which with newer libraries might go all crazy on you.
wine executable is a whole loader that has a way of launching the other apps that qemu doesn't like (just as wine-pthread will not launch wineserver wine will not launch the other). Of course i am no expert at this, just thought it might help .
If one digs into the wine-pthread code of wine 1.0.18 or 17 (the last version with wine-pthread) and the new wine they might be able to recode it so that launching it with a new parameter (such as --do-pthread or something shorter) it acts as an old wine-pthread but with new features. I am just speculating as I have not looked into the code of any.

So basically if you compile a newer version of qemu against the old N900 glibc then newer wine and the wine command might work, if not one needs to edit the source of the wine executable to get it to work. Does this make any sense or have I made it more confusing??

Last edited by pablocrossa; 03-05-2012 at 02:25 PM.
 
Posts: 1,376 | Thanked: 2,073 times | Joined on Nov 2009 @ Dublin, Ireland
#186
Originally Posted by szopin View Post
Relevant:

http://www.youtube.com/watch?v=bVYlrv0kbdA
Well that video is indeed very interesting and promising. Is there any more information of such a project anywhere else?
 
Posts: 184 | Thanked: 149 times | Joined on Jul 2011
#187
Originally Posted by ivgalvez View Post
Well that video is indeed very interesting and promising. Is there any more information of such a project anywhere else?
I am mailing them, probably a newer or patched QEMU, that's all
 
Posts: 1,376 | Thanked: 2,073 times | Joined on Nov 2009 @ Dublin, Ireland
#188
Originally Posted by pablocrossa View Post
I am mailing them, probably a newer or patched QEMU, that's all
I would say it's not the same, it says to be using binary translation, which means that the x86 binary has been converted to ARMv7 code previously and thus, execution speed is much higher.
 

The Following User Says Thank You to ivgalvez For This Useful Post:
Posts: 184 | Thanked: 149 times | Joined on Jul 2011
#189
Originally Posted by ivgalvez View Post
I would say it's not the same, it says to be using binary translation, which means that the x86 binary has been converted to ARMv7 code previously and thus, execution speed is much higher.
I believe Wine for ARM is available on the repositories and is not something new, I believed they were running real x86 apps without conversion or recompilation or whatnot. If I am mistaken then if they use some cool binary translation then, if it works, it would give higher speeds than the QEMU patchy hack we use
 
Posts: 44 | Thanked: 28 times | Joined on Sep 2011
#190
Hey guys.. I got an email from One Laptop For a Child over this and told them to go here!

We actually did help someone!
 
Reply

Thread Tools

 
Forum Jump


All times are GMT -4. The time now is 05:28 AM.