# Wine on AMD APU A8-5600K with 7560D GPU



## sambucuself (Sep 12, 2015)

Hi,

I've started using FreeBSD again and I'm mostly happy with it, almost everything I need works.

I have a problem with Wine and my GPU, I've narrowed it down to a specific line of code in wine source.

I've tried installing a game (Terraria on Steam in Wine), and I can install it, but I can't start it.
On the same hardware it works on Linux.
I'm using 64bit system and tried using i386-wine, i386-wine-devel and i386-wine-staging with mostly the same effects, only the newer version is more helpful with explaining the problem.

I'm using open source radeon driver, and my gpu is recognized as Gallium 0.4 on AMD ARUBA.
The problem is that (i found out after some digging in wine source code) that AMD ARUBA is set for 7660D and when my GPU which is 7560D which is the wine can not detect (from the hardware standpoint they are almost identical).
I've decided to fill in the enum for device type and compile the wine on my own, but I couldn't use the ports tree easily for that.

If I understand correctly all these wine versions are binary packages and don't get really compiled on my machine. I wanted to do 

```
# cd /usr/ports/emulators/i386-wine-devel
# make depends
```
and to modify the source to install the patched wine.

How should I try to do that ?

Is my way of modifying the source of a port correct ?

I also tried installing 32bit libraries in /compat/i386 and all dependencies, I also compiled "my" modified wine in it, but it's not working, I think that my system (64bit side) is not seeing those compiled wine 32 libraries, although I did do this


```
$ more wine
#!/bin/sh

export LD_32_LIBRARY_PATH=/compat/i386/usr/local/lib
export PATH=/compat/i386/usr/local/bin:$PATH

exec /compat/i386/usr/local/bin/wine "$@"
```
 and followed the building instructions on this page:


```
https://wiki.freebsd.org/i386-Wine
```


----------



## tobik@ (Sep 12, 2015)

sambucuself said:


> If I understand correctly all these wine versions are binary packages and don't get really compiled on my machine.


That's no longer true with emulators/wine-devel AFAIK. Maybe that one will work for you.



sambucuself said:


> Is my way of modifying the source of a port correct ?


Read the porter's handbook for a cleaner way: https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/slow-patch.html
You basically run

`make extract`
`cd work/wine*`
Copy the original source file to file.orig
Make your modifications to file
Go back to the port directory
Run `make makepatch`
This creates a patch in the ports' files/ directory that is applied when it is build.


----------



## sambucuself (Sep 12, 2015)

Thanks, I will try that.
Edit:
You are correct, the wine-devel port can be edited, but it's a 64bit native port, and I need 32 bit wine on a 64 bit system. I'm compiling now and I'll see what happens...


----------



## sambucuself (Sep 12, 2015)

I can't get the port to compile with or without my patch 
It complains about some undefined references to linux system calls I think...
This is the output:

```
cc -o wineserver async.o atom.o change.o class.o clipboard.o completion.o console.o debugger.o device.o directory.o event.o fd.o file.o handle.o hook.o mach.o mailslot.o main.o mapping.o mutex.o named_pipe.o object.o process.o procfs.o ptrace.o queue.o region.o registry.o request.o semaphore.o serial.o signal.o snapshot.o sock.o symlink.o thread.o timer.o token.o trace.o unicode.o user.o window.o winstation.o -L../libs/wine -lwine ../libs/port/libwine_port.a -L/usr/local/lib -fstack-protector  -Wl,--rpath,\$ORIGIN/../libs/wine
change.o: In function `create_dir_obj':
change.c:(.text+0x456): undefined reference to `inotify_add_watch'
change.o: In function `req_read_directory_changes':
change.c:(.text+0x5d2): undefined reference to `inotify_init'
change.c:(.text+0x932): undefined reference to `inotify_add_watch'
change.o: In function `inotify_poll_event':
change.c:(.text+0xf81): undefined reference to `inotify_add_watch'
change.o: In function `free_inode':
change.c:(.text+0x146f): undefined reference to `inotify_rm_watch'
cc: error: linker command failed with exit code 1 (use -v to see invocation)
Makefile:202: recipe for target 'wineserver' failed
gmake[3]: *** [wineserver] Error 1
gmake[3]: Leaving directory '/usr/ports/emulators/wine-devel/work/wine-1.7.51/server'
Makefile:18807: recipe for target 'server' failed
gmake[2]: *** [server] Error 2
gmake[2]: Leaving directory '/usr/ports/emulators/wine-devel/work/wine-1.7.51'
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/emulators/wine-devel
*** Error code 1

Stop.
make: stopped in /usr/ports/emulators/wine-devel
```

Probably the default patch set wasn't being applied. I think I got it this time, fingers crossed


----------



## tobik@ (Sep 12, 2015)

The discussion in PR 202564 suggests you can "solve" this by deinstalling devel/libinotify.


----------



## sambucuself (Sep 12, 2015)

I'm trying it now. The other problem is that I don't really need wine 64 bit, I need 32 bit one to install .NET 4.0. But i386-wine-devel is a binary port...


----------



## sambucuself (Sep 12, 2015)

Well, that fixed the build but I can't start my game in 64bit wine prefix 

Back to the drawing board...

I should patch some of the i386-wine ports with my modification to test everything...

Other solution is to simply put my hard drives containing FreeBSD to a machine that has a supported GPU and be done with it...


----------



## vasili111 (Sep 12, 2015)

Are you sure that emulators/wine-devel can run only x86 code? As I understand it can ran both x86 and x64 code.


----------



## sambucuself (Sep 12, 2015)

I'm not sure. emulators/wine-devel provides only wine64 executable, not wine, even if I link wine to wine64 and try installing dotnet20 using winetricks it says bad exe format...

But, I'll recheck and get back to you on that...


----------



## sambucuself (Sep 12, 2015)

I'm using instructions from https://wiki.freebsd.org/i386-Wine to make package of i386 version of wine-devel, and then try to add it to my amd64 system

EDIT:
That failed miserably:

```
pkg: wrong architecture: FreeBSD:10:i386 instead of FreeBSD:10:amd64
```


----------



## sambucuself (Sep 12, 2015)

Now I'm following the instructions on that page correctly and I've added the cross compile flag  It should work this time


----------



## wblock@ (Sep 12, 2015)

sambucuself said:


> I've decided to fill in the enum for device type and compile the wine on my own, but I couldn't use the ports tree easily for that.


Why not?  Add the changes as patch files, and let the port take care of the rest of the work.  See the Porter's Handbook about patching.


----------



## sambucuself (Sep 12, 2015)

Thanks. I've switched to using the ports command `make patch` and others as suggested by tobik.
I'm currently cross-compiling patched version of wine which I hope will work, but the important thing is that now I have gotten the handle on basic ports workflow, so adding better patches to wine source code should be easy.

Edit: this also produced a i386 package even though I followed the instructions from https://wiki.freebsd.org/i386-Wine. `make -DWINE_CROSS_BUILD package` is the option I used and I hoped that this would create a cross compiled package. The other option is to go to emulators/i386-wine-devel and to do 
	
	



```
#make extract
#make patch
#make install
```

But I can't patch the code because when used on a 64bit machine that port is a binary port that just installs the precompiled wine.


----------



## james122333 (Oct 12, 2015)

I have a 7660d card.

There are two ways to run wine.
1. i386-wine-devel  or  i386-wine-staging (from pkg or build yourself).
2. Install wine-devel or wine-staging in /compat/i386 and set "many" environment variables to run wine and winetricks, etc.

All the two ways run well. If necessary, you can run diff to create patches and place them into /usr/ports/emulators/wine-devel/files (notice no conflict between patches) to build your distribution.
However, the amd open driver contains many problems such as s3tc in some games. League of Legends seems to be OK. The following is an example. (run with gallium nine & staging patch)
https://www.dropbox.com/s/cl6kg741wvxi3mk/2f83277f9e2f0708a847f40def24b899a801f2d7.jpg?dl=0
https://www.dropbox.com/s/1x74aptjujno08y/2015-10-12-181442_1440x900_scrot.png?dl=0


----------

