JohnKlehm

John Klehm

Email: <xixsimplicityxixATSPAMFREEgmailDOTcom>

2008 04 04

Well seems the approach I was thinking of last year (auto patching w32api) is the wrong way to go as they won't accept patches based on wine source. So the new improved approach is to cross build using wines headers. After some tricks it appears to work pretty ok. I wrote this script to slay the cross build beast. wine git repo, gcc, and mingw required to use the script.

http://klehm.net/wine/crossbuild_tricks.sh

$crossbuild_tricks.sh 

Usage: ./crossbuild_tricks.sh [options] target [target]
This script cross-builds the specified target using wines headers/libs

Targets:
winetest              build winetest exe, this builds all individual tests as a dep
test DLLNAME          build test exe for given dll
dll DLLNAME           build given dll
d3d                   builds dlls: d3d8,d3d9,wined3d
libs                  builds just the .a import libs. Find them in libs/wine/
alldlls               builds all dlls possible.  Known failures as of 2008 04 03:
                      dbghelp, dnsapi, gdi32, glu32, icmp, iphlpapi, kernel32, msvcrt
                      ntdll, opengl32, rpcrt4, secur32, shell32, winex11.drv, wininet
                      winmm, ws2_32.
                      Creates WINE_PE/binaries dir and copies all dlls to it
distclean             REMOVES pe and native dirs IF they are not the same as source dir.
                      runs make distclean in source dir.

Options:
noconf                tells tricks not to run wine configure script. Must be first in args list

Notes:
In order to use wine's d3d dlls on windows you'll have to copy over libwine.dll
from the libs directory too. Maybe for other dlls to.

2007 06 14 2am UTC-5

Hrmmm now in my random thoughts of pondering I was thinking it would be possible to write up a script which would

  1. grab latest wine source
  2. Scan the .spec files for additions/modifications
  3. Generate new .def files/patches based on the spec files
  4. Grab latest w32api source
  5. Apply patches and files from step 3 to the w32api source

Hrmm it would seem possible. Never having w32api be out of sync with wine? Always being able to build the tests without nonesense? Crazy? Jack Sparrow crazy? =P I'm sure someone will come along and deflate my myopic moment of insight.

2007 06 11 11pm UTC-5

Winetest.exe: Oh yes it shall be mine

Trying to fancy up my testing getup by hacking winetest.exe into a more personal thing. Basically what I want is to have just my test set loaded up, and then run it as I make advances in my code so I'll know exactly when my tests are passing. If you have ever used JUnit you know what I'm talking about.

Winetest.exe cross build gotchas:

First reference this: cross compile winetest.exe howto. It's almost all you need to know for building wine test on your cross compile setup. Much love for this howto Paul!

Errata

  • configure yelled at me and told me I had to specify --build and --host. I used --build=i686-pc-linux-gnu and --host=i386-mingw32

Read up on your gcc configure terms. In this case we're using a crosscompiler to build native win32 binaries.

  • Error 'array type has incomplete element type' on line 279 of include/wine/port.h. Apparently gcc4 got stricter so change it to const struct timeval *tv instead of const struct timeval tv[2] download the port.h patch fixing gcc4 error This was committed on 6/15/2007 =).

  • cd wine-pe/programs/winetest; make bails out with an error: 

cp ../../dlls/ole32/tests/ole32_test.exe ole32_test.exe && i386-mingw32-strip ole32_test.exe
make: *** No rule to make target '../../dlls/oleaut32/tests/oleaut32_test.exe', needed by 'oleaut32_test.exe'. Stop.

So now we $make -C ../../dlls/oleaut32/tests/ but this bails out with 

error: Could not open importlib stdole2.tlb

Humm ok so it needs this stdole2.tlb thing so: make -C ../../dlls/stdole2.tlb $EXTRAINCL="-I../../stdole2.tlb" make -C ../../dlls/oleaut32/tests gives 

../../../../wine-native/tools/widl/widl -I../../../../wine-source/dlls/oleaut32/tests -I. -I../../../../wine-source/include -I../../../include -I../../stdole2.tlb  -t -T tmarshal.tlb ../../../../wine-source/dlls/oleaut32/tests/tmarshal.idl
error: Wrong or unsupported typelib magic 905a4d
make: *** [tmarshal.tlb] Error 2

Hrmm perhaps it needs the native stdole2.tlb since its using native widl make -C ../../../wine-native/dlls/stdole2.tlb/ gives 

../../tools/winegcc -B../../tools/winebuild -shared ../../../wine-source/dlls/stdole2.tlb/stdole2.tlb.spec     rsrc.res    -o stdole2.tlb.so -lkernel32   ../../libs/port/libwine_port.a
/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../../i686-pc-linux-gnu/bin/ld: cannot find -lkernel32
collect2: ld returned 1 exit status
winegcc: gcc failed

*grrr*

New plan we hack out oleaut32_test.exe from winetest.exe. Didn't want to do this but I can't spend all my time on this nonsense. I'll come back to it later, really I will.

So to just chop it out one simply: Searches for all references to oleaut and removes the lines (as well as the one cp line below one of the lines) in programs/winetest/Makefile AND deletes this line oleaut32_test.exe TESTRES "oleaut32_test.exe" from wine-source/programs/winetest/winetest.rc

now in wine-pe $make -C programs/winetest will succeed

2007 06 09 10pm UTC-5

Ran across this error after I tried to build cross tests on a 64bit box. This machine supposedly had a cross tool chain for i386-mingw32. Not sure wether it is a bug in bin2res, i386-mingw32-windres, or a bug in the compiler setup. The tinier the details the more human skin they keep in jars in their rooms =/. Maybe when I actually have a few more tablet pc patches under my belt I'll come back and look into this. Back to work on the slow x86 box =/

$./configure; make crosstest 

i386-mingw32-gcc -c -I. -I. -I../../../include -I../../../include   -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith  -g -O2  -o updown.cross.o updown.c
updown.c:1: warning: -fPIC ignored for target (all code is position independent)
../../../tools/bin2res -f -o bmp128x15.bmp ./rsrc.rc
../../../tools/bin2res -f -o bmp80x15.bmp ./rsrc.rc
LD_LIBRARY_PATH="../../../libs/wine:$LD_LIBRARY_PATH" ../../../tools/wrc/wrc --nostdinc -I. -I. -I../../../include -I../../../include    -forsrc.res rsrc.rc
i386-mingw32-windres -i rsrc.res -o rsrc.res.cross.o
i386-mingw32-windres: rsrc.res: Not a valid WIN32 resource file
make[2]: *** [rsrc.res.cross.o] Error 1
make[2]: Leaving directory `/home/john/wine-git/dlls/comctl32/tests'
make[1]: *** [comctl32/tests/__crosstest__] Error 2
make[1]: Leaving directory `/home/john/wine-git/dlls'
make: *** [dlls/__crosstest__] Error 2

Google may have a clue here, 64 bit related? http://www.reactos.org/forum/viewtopic.php?t=1915&highlight=

I'm not alone in this CoolBeer has also confirmed this on Gentoo amd64. More evidence for 64bit troubles

If anyone feels like testing on amd64...

Here are the steps to reproduce:

  1. Get wine source code

    • $git clone git://source.winehq.org/git/wine.git wine-git

  2. Setup cross compile environ (This is on Gentoo, on your own for other setups)

    • #emerge crossdev && crossdev i386-mingw32

  3. build win32 versions of wines tests

    • $cd wine-git; ./configure && make crosstest

2007 06 08 6am UTC-5

My linux box is down at the moment (big storm). So where I am (or was) at:

  • Setup the cross environment
  • wrote an ebuild to greatly simplify the process of building on gentoo (and hopefully get Han's patches committed to gentoo)
  • Written about 5 tests (Dan expect to see these soon)

Most difficult things so far:

  • patching a generated makefile is annoying
  • understanding how to setup a cross compiling environment is similar in enjoyment to a kick in the teeth

Most fun so far:

  • seeing tests built on linux run on windows to help tests run on linux =)

Hopefully I'll actually be able to kick out some patches soon.

2007 06 03 12pm UTC-5

Well Hans emailed me back and said he'd be happy to have the patches comitted to mingw. So I submitted them to sourceforge mingw as bug 1730319 and patch request 1730314. So hopefully they'll go through in a not infinite amount of time.

2007 06 02 8pm UTC-5

Well the for part of today and parts of the days past I have been slowly understanding what it means to cross compile and the different parts of the system that need to be reconfigured in order to do this. Now part of the reason is Gentoo, but not for the reason you'd think =P

Now it's taken me this long to figure out what was going down because I didn't know enough to know that I had configured the cross tool chain correctly the first time I did it. Gentoo actually makes that really easy. The tricky part is when the tests fail to build with "./configure; make crosstest" as described here: http://www.winehq.org/site/docs/winedev-guide/cross-compiling-tests.

I'm going to make a page probably tomorrow describing what needs to be done tomorrow and I'll try and link to it in the appropriate spots on the wiki but for sure it will be linked here. It's not even that difficult but there are some gotchas that led me far afield and I guess I spent overall about 6 hours trying to figure this out. So to save ya'll the trouble if you were as confused as I, I will write a little guide.

This is not the final guide just some notes and the general description for cross compiling wine on gentoo. DO NOT follow this. This is more of what I did with annotations on what worked and why. Skip to the end and I'll sum up the general steps.

To start:

Crossdev is a gentoo tool that helps you have a slotted cross toolchain, youll be able to have many different configurations with this tool all handily setup

#emerge crossdev

Next you need to emerge a toolchain suitable for cross compiling wine. This is the mingw32 target in crossdev. So you can also specify the cpu arch here too. One gotcha is that the wine configure script does NOT detect i686-mingw32. I lost a bit of time on this because I was trying to use i686-mingw32, doh!

Cross tool chains it does detect are

  • i386-mingw32msvc
  • i586-mingw32msvc
  • i386-mingw32
  • mingw32
  • mingw

So lets choose i586-mingw32msvc

#crossdev i586-mingw32msvc

This'll chew for a bit as it's compiling a tool chain. It'll finish without error after gcc-stage2. Oh, you thought the default was stage 4? Don't worry the stages listed in the output are just for gcc so stage 3 is gcc-stage1 and stage 4 is gcc-stage2. Great naming scheme I know. As long as it exits without error you're cool.

Ok we've got the cross tool chain let's try to get wine compiled up

$cd ~/winesrc $./configure; make crosstest;

'Cannot find -lcabinet

Ermm ok so what happened: Missing libraries and undefined symbols?! So it would seem that MinGW headers are are missing a few libraries by default so according to this page http://mirzam.it.vu.nl/mingw/ Hans Leidekker and Stefan Leichter made a set patches and put them into RPM form. Awesome! One is curious as to why they aren't committed to the w32api project (I emailed Hans hopefully he'll have time to tell me).

What does this mean for Gentoo? We need to patch the w32api ebuild. To do this we need to clone the existing w32api ebuild and put it in a portage overlay. In the real page I write up I'll fully reference how to do that but here is mainly for me so you'll have to wait a bit.

So for my own convenience I extracted the patches in a more universal format and hosted them here: http://klehm.net/w32api-3.9-patches.tar.bz2

So make a copy of the ebuild and bump it one revision. For instance in my portage tree the latest w32api ebuild is w32api-3.9.ebuild. Since we want portage to grab the ones with our revisions we're gonna give it a version higher than the latest, in this case that'd be w32api-3.9-r9.ebuild. You can download the w32api ebuild.

Following this http://devmanual.gentoo.org/ebuild-writing/functions/src_unpack/epatch/index.html you can see how to modify the ebuild to iterate through the pack of patches and apply them. I'll post my modified ebuild on the new page when I write that up tomorrow.

Where are we at now:

  • emerged crossdev i586-mingw32msvc
  • "./configure; make crosstest" failed because we we're missing libaries
  • dropped an w32api ebuild into our local overlay that apply patches and add the missing libraries

So we need to emerge our fixed ebuild now. We never emerged w32api directly true, but crossdev does as a dependency. So we need to reintall that rememebering that new ebuilds don't get picked up by emerge until you do an emerge --sync. So we:

#emerge --sync; emerge crossdev;

This should pull in our modified ebuild as an updated dep for crossdev.

Now we can emerge our toolchain using the the working set of libaries but first we'll remove the old one (-C for clean).

#crossdev -C i586-mingw32msvc

#crossdev i586-mingw32msvc

And now we can cross compile the wine tests no problem =)

#cd ~/winesrc #./configure; make crosstest

So concisely stated to cross compile the regression tests on gentoo one needs to:

  1. make a new version of the dev-util/w32api ebuild with the Hans and Stefan patches from http://klehm.net/

  2. pull in your new ebuild and emerge cross dev: #emerge --sync; emerge crossdev;
  3. use crossdev to build a crosstool chain that is supported by wines configure script (no i686!)#crossdev i586-mingw32
  4. Acutally make the tests with $./configure; make crosstest

Sooo hopefully this process will be simplified in the future by a Good Gentoo Howto and the modified ebuild that people can dump into their overlay. Maybe it'll be possible for Han's and Stefan's patchset to get committed upstream to mingw and then the modified ebuild could be committed directly to the portage tree. If not I guess maybe some kind of use flag could be conjured up "wine-compat" or something for the w32api package. We'll see. I'm sure if Dan is reading this he's wondering if my project is actually Tablet PC support or if it's Gentoo and Wine support. I guess all I'm gonna say is that this whole setup was confusing to me and hopefully this write is somewhat helpful to the confused souls out there, not like anyone will read this though =P

Gentoo bug 181875

2007 05 29 7pm UTC-5

Guess I'm here due to Google's SummerOfCode 2007. My project is to work on Tablet PC support. Here's the abstract I submitted detailing what my plan is http://code.google.com/soc/2007/wine/appinfo.html?csaid=D9C1840E56F19B91

I'll briefly review it here to save people some time.

  1. Make a ton of tests for InkObj.dll and then implement it.

  2. Even more tests for wisptis.exe and then implement it.
  3. Test the Sample applications from the Tablet PC SDK
  4. Get xThink calculator working
  5. Test and implement RTSCom.dll
  6. Clean and polish (documentation etc.)

  7. Time permitting Test and implement helper libraries: IACom.dll, InkDiv.dll, InkEd.dll, PIPanel.dll

For some reason this seems like my plate is full to me but maybe it will all be really easy...maybe.

So far I've been getting my self more coordinated with Git and such making sure I understand what it's doing. My goal is to get some basic tests of InkObj.dll in my tree by tonight. I'm also hoping to look into Maarten's suggestion of a public git repo or what not. Makes sense to me I just don't know anything about it at the moment so...yup.

Checklists, we love them so let's another! By tonight I'll:

  • Have some basic tests compiling, running, and dancing.
  • Have a public git repo via Mr Lankhorsts modest proposal
  • Not have eaten overly much chocolate. Doh!

CategoryHomepage

JohnKlehm (last edited 2008-04-04 10:37:06 by JohnKlehm)