Compiling & running 1.4 on 64bit

layr · Post by **layr** » Sat Mar 10, 2012 5:50 am

I need someone's expertise.
I have compiled wine 1.4-1 in a Xubuntu 12.04 beta, running on virtual machine (obviously a 32bit system, since it's VM).
Steps i took:

Code: Select all

1. installed development packages by running http://winezeug.googlecode.com/svn/trunk/install-wine-deps.sh (as instructed on http://wiki.winehq.org/Wine64)
2. apt-get build-dep wine
3. apt-get install patch libpulse-dev checkinstall
4. ./configure --enable-win64
5. make depend && make
6. checkinstall (which created the .deb package)

Everything compiled correctly and seemd OK; I installed the package on Debian Wheezy, again no errors occured. But the command "wine" can't be run, says the command cannot be found. I guess the problem is in the fact it installed into wrong directory. How to overcome this issue?

Post by **dimesio** » Sat Mar 10, 2012 7:02 am

layr wrote:I have compiled wine 1.4-1 in a Xubuntu 12.04 beta, running on virtual machine (obviously a 32bit system, since it's VM).

Huh? 64 bit VMs are certainly possible.

Code: Select all
4. ./configure --enable-win64

What you built is 64 bit Wine.

layr · Post by **layr** » Sat Mar 10, 2012 7:08 am

I read somewhere, that the 64bit VMs are actually 32bit systems. Bad info i guess.

Indeed the 64bit wine was built, but why can't I run it on Wheezy?

Code: Select all

bash: wine: command not found
laur@debian:/usr/bin$ wine64

Martin Gregorie · Post by **Martin Gregorie** » Sat Mar 10, 2012 9:28 am

On Sat, 2012-03-10 at 06:08 -0600, layr wrote:

I read somewhere, that the 64bit VMs are actually 32bit systems. Bad info i guess.

Indeed the 64bit wine was built, but why can't I run it on Wheezy?

Where did you install it?

Useful to know: "which wine" or "which wine64" shows if its in $PATH

Martin

layr · Post by **layr** » Sat Mar 10, 2012 10:49 am

Martin Gregorie wrote:Useful to know: "which wine" or "which wine64" shows if its in $PATH

Thanks for the tip.

Code: Select all

laur@debian:~$ which wine64
/usr/local/bin/wine64

So I guess the problem is in the fact wine installed into /usr/local/bin instead of /usr/bin/.
Is there any way to change that?

L. Rahyen · Post by **L. Rahyen** » Sat Mar 10, 2012 11:30 am

So I guess the problem is in the fact wine installed into /usr/local/bin
instead of /usr/bin/.
Is there any way to change that?

It looks like you installed it by running "make install". This is bad
practice. I suggest to go to the Wine's build directory and run
"make uninstall". It is good idea to never use "make install" and use
checkinstall instead. Run "apt-get install checkinstall" if you do not have it
installed and run "checkinstall" instead of "make install". Then you can
install generated .deb files. Everything will be installed properly at the
usual paths and will be tracked by the packaging system.

layr · Post by **layr** » Sat Mar 10, 2012 11:44 am

L. Rahyen wrote: It looks like you installed it by running "make install".

Nope, I created the .deb package under virtual machine and installed it on main system via dpkg -i

layr · Post by **layr** » Sat Mar 10, 2012 12:01 pm

Weird. 'which wine' gives no output, yet 'man wine' opens manual page.

Code: Select all

laur@debian:~/Downloads$ wine
bash: wine: command not found
laur@debian:~/Downloads$ wine64
bash: /usr/local/bin/wine64: No such file or directory
laur@debian:~/Downloads$ winecfg
/usr/local/bin/winecfg: 52: exec: wine: not found

L. Rahyen · Post by **L. Rahyen** » Sat Mar 10, 2012 12:05 pm

Nope, I created the .deb package under virtual machine and installed it on
main system via dpkg -i

Try:
./configure --prefix=/usr
...to set the prefix to /usr instead of /usr/local manually.

layr · Post by **layr** » Sat Mar 10, 2012 12:48 pm

L. Rahyen wrote: Try:
./configure --prefix=/usr
...to set the prefix to /usr instead of /usr/local manually.

Just to make sure - I'll compile the .deb again from source by running ./configure --prefix=/usr --enable-win64?

L. Rahyen · Post by **L. Rahyen** » Sat Mar 10, 2012 1:15 pm

I'll compile the .deb again from source by running
./configure --prefix=/usr --enable-win64?

Yes, if you want to build 64-bit Wine.

Martin Gregorie · Post by **Martin Gregorie** » Sat Mar 10, 2012 2:27 pm

On Sat, 2012-03-10 at 09:49 -0600, layr wrote:

Martin Gregorie wrote:
Useful to know: "which wine" or "which wine64" shows if its in $PATH
Thanks for the tip.

Code:
laur@debian:~$ which wine64
/usr/local/bin/wine64

So I guess the problem is in the fact wine installed into /usr/local/bin instead of /usr/bin/.
Is there any way to change that?

Why would you want to? The fact that 'which' can find the 'wine64'
command tells you that it is in your search path, so simply using
'wine64 as a command in any directory under your login will work.

The compilation put Wine in the correct place. The convention is:

- Programs needed during system boot, i.e. those that, if absent, leave
you with a crippled system go in /bin and those intended for root (the
superuser) use go in /sbin

- Programs that are part of your distro go in /usr/bin (and those for
root) go in /usr/sbin

- Programs compiled and installed locally for use by all users should
be in /usr/local/bin and (for root use only) in /usr/local/sbin

- Programs that are for use only by a single user or that are under
development should be in $HOME/bin

As a result $PATH for normal users should include
"/bin:/usr/bin:/usr/local/bin:$HOME/bin". This is the best way to do
things because this arrangement means that you can't screw up /bin
or /usr/bin by compiling and installing programs and scripts. It also
means that bugs in stuff you've created for your own use can't mess up
anybody else.

User-specific changes to $PATH depend on the shell being used, but for
bash you'd edit ~/.bash_profile to include a line like this if you want
to put your own scripts and programs in your own directory:

export PATH=$PATH:$HOME/bin

Martin

Martin Gregorie · Post by **Martin Gregorie** » Sat Mar 10, 2012 2:44 pm

On Sat, 2012-03-10 at 11:01 -0600, layr wrote:

Weird. 'which wine' gives no output, yet 'man wine' opens manual page.

Code:
laur@debian:~/Downloads$ wine
bash: wine: command not found
laur@debian:~/Downloads$ wine64
bash: /usr/local/bin/wine64: No such file or directory
laur@debian:~/Downloads$ winecfg
/usr/local/bin/winecfg: 52: exec: wine: not found

All that means is that the directory containing it isn't in the search
path, $PATH. You have a few choices:

1) use the full pathname of wine64 every time you run it
2) always run it via wrapper script that contains the pathname
3) set the makefile to install wine64 in /usr/local/bin
*and* make sure /usr/local/bin is in your search path
4) as for (3) but use $home/bin rather than /usr/local/bin
5) set the makefile to install wine64 in /usr/bin but be aware that
this is a bad practise because it can clobber vital programs
if the makefile is screwed up.

(1) to (3) are preferable if you'll be doing a lot of compilations
and/or playing with patches

(4) is preferable if you're compiling your self but fairly infrequently.

If tarball that you download, compile and install puts itself in
either /bin or /usr/bin this shows ignorance on the part of its
packager. Quite apart from anything else, it can get clobbered by a
distro update: these can and do change the contents of these directories
but should never affect programs or scripts in /usr/local/bin or
$HOME/bin

Martin

layr · Post by **layr** » Sat Mar 10, 2012 5:48 pm

Martin Gregorie, appreciate your input, but I'm afraid I'm not quite following you.
etc/profile already contains /usr/local/bin as a PATH variable, so that shouldn't be a problem.
Just tried with the modified .deb - it installed wine into usr/bin, but nothing changed for that matter.

Code: Select all

laur@debian:/$ type wine64
wine64 is hashed (/usr/local/bin/wine64)

What would this mean?

(PS if anyone happens to have an amd64 architecture .deb package, let me know

)

Martin Gregorie · Post by **Martin Gregorie** » Sat Mar 10, 2012 6:43 pm

On Sat, 2012-03-10 at 16:48 -0600, layr wrote:

Martin Gregorie, appreciate your input, but I'm afraid I'm not quite
following you. etc/profile already contains /usr/local/bin as a PATH
variable, so that shouldn't be a problem.

Good. I'm uncertain whether that is the case out of the box for all
distros. In any case, other people will be reading this thread so I
thought it was worthwhile to set out the program placement conventions
and the reasons for deciding where to put a program.

Just tried with the modified .deb - it installed wine into usr/bin,
but nothing changed for that matter.

That's ended up where I'd expect packaged programs to be put.

Code:
laur@debian:/$ type wine64
wine64 is hashed (/usr/local/bin/wine64)

What would this mean?

Not a clue. The version of type in my distro (Fedora 16) is a builtin
part of bash 4.2.20 and it does this:

$ type wine
wine is /usr/bin/wine

and its manpage doesn't say anything about an 'is hashed' output, though
it might be describing the organisation of either $PATH (unlikely) or
the directory containing it (which is a filing system specific thing.
What does "man type" tell you about it?

I'm running 32bit versions of Linux and wine: since I've got just 4GB of
RAM installed I see no reason to run 64bit versions of anything.

Martin

layr · Post by **layr** » Sun Mar 11, 2012 3:36 am

Martin Gregorie wrote: What does "man type" tell you about it?

Code: Select all

laur@debian:~$ man type
No manual entry for type

Martin Gregorie wrote:I'm running 32bit versions of Linux and wine: since I've got just 4GB of
RAM installed I see no reason to run 64bit versions of anything.

I have only 3GB of ram. The reason I want the 64bit version is when I tried installing 32bit 1.2.3 package I had compiled for other system, the installer said it was of a wrong architecture.

Martin Gregorie · Post by **Martin Gregorie** » Sun Mar 11, 2012 8:35 am

On Sun, 2012-03-11 at 03:36 -0500, layr wrote:

Martin Gregorie wrote:
What does "man type" tell you about it?
Code:
laur@debian:~$ man type
No manual entry for type

OK. You could try "man builtins", which also works here.

Failing that, try "apropos builtin", which should give you the name(s)
of manpages with the 'builtin' keyword in their header lines.

I have only 3GB of ram. The reason I want the 64bit version is when I
tried installing 32bit 1.2.3 package I had compiled for other system,
the installer said it was of a wrong architecture.

Odd. I though 32 bits would run on all hardware - time to raise the
issue with your distro or try a different one?

Martin

layr · Post by **layr** » Sun Mar 11, 2012 12:15 pm

What is the type manpage for? Can's see it's relevance to this issue.
Anyway, man builtins returned this for type:

Code: Select all

type [-aftpP] name [name ...]
              With  no options, indicate how each name would be interpreted if
              used as a command name.  If the -t option is used, type prints a
              string  which  is  one  of alias, keyword, function, builtin, or
              file if  name  is  an  alias,  shell  reserved  word,  function,
              builtin,  or disk file, respectively.  If the name is not found,
              then nothing  is  printed,  and  an  exit  status  of  false  is
              returned.   If  the  -p  option is used, type either returns the
              name of the disk file that would be executed if name were speci‐
              fied as a command name, or nothing if ``type -t name'' would not
              return file.  The -P option forces a PATH search for each  name,
              even if ``type -t name'' would not return file.  If a command is
              hashed, -p and -P print the hashed value,  not  necessarily  the
              file that appears first in PATH.  If the -a option is used, type
              prints all of the places that contain an executable named  name.
              This  includes  aliases  and  functions,  if  and only if the -p
              option is not also used.  The table of hashed  commands  is  not
              consulted  when  using -a.  The -f option suppresses shell func‐
              tion lookup, as with the command builtin.  type returns true  if
              all of the arguments are found, false if any are not found.

Martin, could you share your .deb package? Perhaps the fault lies simply in my compilations.

vitamin · Post by **vitamin** » Mon Mar 12, 2012 12:10 am

layr wrote:bash: wine: command not found
laur@debian:/usr/bin$ wine64

You need both wine-64bit and wine-32bit installed. Otherwise Wine and most windows programs will not work properly.

And no, you can run 32-bit Wine on 64-bit system.

Martin Gregorie · Post by **Martin Gregorie** » Mon Mar 12, 2012 8:41 am

On Sun, 2012-03-11 at 12:15 -0500, layr wrote:

What is the type manpage for? Can's see it's relevance to this issue.
Anyway, man builtins returned this for type:

Martin, could you share your .deb package? Perhaps the fault lies
simply in my compilations.

That's impossible: I run Fedora distros, which use .rpm packages.

Martin

qwest · Post by **qwest** » Mon Mar 12, 2012 7:23 pm

Your issue is that you are never compiling the 32-bit component of wine which is required for a vast majority of software that is run in wine.

This is what I got out of a conversation with Scott Ritchie (package maintainer of wine in Ubuntu) a few weeks ago and how I build wine.

~/wine-git - git source
~/wine32 - out-of-tree build directory for 32 bit components
~/wine64 - out-of-tree build directory for 64 bit components

# Compile the 64 bit components
cd ~/wine64
../wine-git/configure --enable-win64
make

# Compile the 32 bit components
# Do this from a separate amd64 chroot since multiarch isn't mature enough in the current Pangolin beta to allow all the dev packages for wine in both archs to be installed simultaneously
cd ~/wine32
../wine-git/configure --with-wine64=../wine64
make

If you would like to go one step further and build packages, you should package the 32 bit components and 64 bit components separately and then create a dependency between the two packages.

tarasper · Post by **tarasper** » Tue Mar 13, 2012 7:01 am

I have builded a shared WoW64 setup as described here http://wiki.winehq.org/Wine64.

When I try to install windows application ()

Code: Select all

/opt/wine64/wine /home/taras/Downloads/CiscoIPCommunicatorSetup.exe

I get an error:

"The minimum supported processor tu run Cisco IP Communicator is a P3 Pentium-level or compactible processor. The setup will now abort.

Code: Select all

/opt/wine32/wine /home/taras/Downloads/IE8-WindowsXP-x86-ENU.exe

The installation does not support your system architecture (32/64bits)

How can I run application in 32bit mode?

layr · Post by **layr** » Wed Mar 14, 2012 11:39 am

Thanks vitamin and qwest. I've followed the instructions given, but the last, 32bit part, failed to install. Everything compiled without problems, but 'checkinstall --install=no' yielded in

Code: Select all

Building Debian package... FAILED!

*** Failed to build the package

Do you want to see the log file?  [y]: y

Log file contained:

Code: Select all

dpkg-deb: error: parsing file '/var/tmp/tmp.RbzZbtWFP6/package/DEBIAN/control' near line 14 package 'wine32':
 empty value for version

What version does it mean? When i ran 'checkinstall --install=no', the first thing was creating some kind of documention, which included short description, architecture, version nr etc. I certainly edited that part and entered ver number. It probably isn't it, is it?

qwest · Post by **qwest** » Wed Mar 14, 2012 6:02 pm

It seems like you are having issues with Debian packaging more so than wine now, so you might be able to find better help on an Ubuntu or Debian forum. I would suggest, however, that you download the official Ubuntu wine package and observe the differences between your debian/control and the official debian/control on line 14.

layr · Post by **layr** » Thu Mar 15, 2012 3:41 am

I've given up on the 64bit. Finally found a way to get the 32-bit installed:

Code: Select all

dpkg --force-architecture -i FILE.deb

Second solution would be marking architecture as 'all' when creating .deb package, but I personally haven't tried that out.
Case closed for me, thanks for help everyone.