Compilation problems

[Slice]

This is not easy procedure with numerous caveats and will be separate development.

 

1. You may use MacPort

sudo port install wine

but you'll get a version 1.6.2 while latest version is 1.7.44

sudo port install wine-devel

and get 1.7.44

This is good procedure because you'll get all dependences needed for compilation.

But you can't apply patches. You'll get vanilla wine.

 

2. You may get sources from git and compile them

http://wiki.winehq.org/GitWine

Happy hacking! 

 

3. You get obtain dependences from step 1. Then you can get sources from step 2.

Then you can get Wineskin Winery. 

http://wineskin.urgesoftware.com/tiki-index.php?page=Downloads

Launch. Click "+", then choose "Custom build engine"

then fill fields:

Choose sources downloaded from git.

Assign Engine Name. There is a strict rule that name must begin from WS9Wine... Other symbols arbitrary.

Update current engine base.

Now you can go to compile. It will be successful but very slow way and the result will be not very good if any.

 

4. Now look what we have and improve process.

 ~/wine-git contains all sources

~/Library/Application Support/Wineskin contains EngineBase and Engines

/opt/local/ contains include/ and lib/ created by MacPort.

Winery at compilation rename opt/local folder and place a link to EngineBase instead. After compilation it revert changes. Not a good practice.

Then my way.

I corrected config.txt to use my libraries

/Users/slice/Projects/wine
WS9WineXSherry1.7.44-106g
--disable-option-checking --without-oss --with-cms --without-v4l --without-alsa --without-audioio --without-capi --with-coreaudio --without-esd --without-hal --without-jack --with-xcomposite --with-xcursor --with-xinerama --with-xinput --with-xml --with-xrandr --with-xrender --with-xshape --with-xshm --with-xslt --with-xxf86vm --with-x --with-fontconfig --without-gphoto --with-gstreamer --without-dbus --without-opencl --without-sane  --without-pulse  --without-va
W2.5.5s2EngineBase
/Users/slice/Library/Application Support/Wineskin/7za
10.6

I corrected WineskinEngineBuild script

WineskinEngineBuild.zip

But I restrict it for configure only.

Then second script to make after configure.

Build.sh.zip

These scripts expected a folder /opt/WineskinS2 which really is a symlink to EngineBase

sudo ln -s ~/Library/Application\ Support/Wineskin/EngineBase/W2.5.5s2EngineBase /opt/WineskinS2

 

Next I have to update libraries in ..W2.5.5s2EngineBase/lib to more recent version from my collection named WrapperUpdate

WrapperUpdate.zip

Now I can change config.txt to new engine name, change sources and compile Wine.

./Build.sh

 

 

[Slice]

Stage Sources and patches.

 

Our purpose is to make better wine so we want to patch sources.

First of all there is a project wine-stage which exists as a set of patches for vanilla wine.

https://github.com/wine-compholio/wine-staging

We can download those patchset and apply them to our wine folder

One caveat.

Utility "readlink" used in the script is not working properly on Mac. You should install

sudo port install coreutils

and change in the script "readlink" -> "greadlink"

Or download my version greadlink.zip

Then apply patches

cd wine-stage
./patches/patchinstall.sh DESTDIR="../wine-git" --all --no-patchlist

The patchset works only for one wine version. In any change in wine the patching procedure will fail.

If success then you can compile new sources same way. Just remember to change name.

 

All of this are far from perfect so I expected someone give me propositions what to improve.

Hey looks like you may need a WineGrower

I know, you can do this. 

[Slice]

May be yes. I just don't know what to do.

 

 

Next step I did is to make compilation by recent clang from XCode 6.3.

Initially winery assumes compilation by gcc-4.2.1 and SDK10.6. gcc included into winery, SDK you have to download somewhere.

 

But we found that it is not only way.

Clang + SDK10.8 can be used as well.

There are corrected scripts and config.

In my case OSX 10.9.5 gcc == clang

$ gcc -v
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.4.0
Thread model: posix

config.txt-clang.zip

Build.sh-clang.zip

WineskinEngineBuild-clang.zip

 

[Slice]

I am thinking about wine-stage patchset.
The wine obtained from it is much better then vanilla but I have very big difficulties 
1. To apply these patches to wine sources.
2. To apply my patches to modified sources.
3. Keep my patches in sync with both sources.
 
Are they needed? Look what they have.
1. Hundreds patches that are obsolete and influence nothing.
2. Tens patches that later will be included in mainstream and will be excluded from stage. We are not hurry. Just excessive work.
3. Linux specific patches that will not be used on Mac: DBus, Mesa, PulseAudio, VA, EAX, Video4Linux etc. As well as all hardware dependent patches because driver model in Mac is quite different from Linux.
4. Added numerous stubs for unimplemented functions.
5. DXTn textures support. It is needed but the realization is Linux specific. I rewrote it to be more appropriate. Some more work is needed here.
6. The main patch why the project exists is CSMT technology. Let speak about it.
 

CSMT

Command Stream Multi Threaded
Initial idea of the patch is to use 2-cores CPU and comes from 2008 when Core2Duo was widely used.
https://bugs.winehq.org/show_bug.cgi?id=11674
Initially developed for wine-1.3.16 then rewritten by Stefan Dösinger to wine-1.7.1. Then the wine-stage was created with this patch while Stefan continue working in WineHQ. Why he droped it?

For my observation the patch sometimes improved performance, sometimes dropped it, sometimes lead to crash.

The idea of the patch is bad because MacOSX can use both CPU cores no matter if application don't do this.

 

The problems with this patch implementation is it doubles sources and other patches can't be properly applied in this place

For example

#if defined(STAGING_CSMT)
    if (wined3d_settings.cs_multithreaded)
        context->gl_info->gl_ops.gl.p_glFinish();
    else if (wined3d_settings.strict_draw_ordering
            || (dst_surface->container->swapchain
            && (dst_surface->container->swapchain->front_buffer == dst_surface->container)))
        context->gl_info->gl_ops.gl.p_glFlush(); /* Flush to ensure ordering across contexts. */

    context_release(context);

    wined3d_resource_validate_location(&dst_surface->resource, dst_surface->container->resource.draw_binding);
    wined3d_resource_invalidate_location(&dst_surface->resource, ~dst_surface->container->resource.draw_binding);
#else  /* STAGING_CSMT */
    if (wined3d_settings.strict_draw_ordering
            || (dst_surface->container->swapchain
            && (dst_surface->container->swapchain->front_buffer == dst_surface->container)))
        context->gl_info->gl_ops.gl.p_glFlush(); /* Flush to ensure ordering across contexts. */

    context_release(context);

    surface_validate_location(dst_surface, dst_surface->container->resource.draw_binding);
    surface_invalidate_location(dst_surface, ~dst_surface->container->resource.draw_binding);
#endif /* STAGING_CSMT */

So maintainers should check both paths for changes. And keep two diifs?

Other problem that the patch is obsolete. The CSMT specific codes related to wine-1.7.1 and poorly updated to recent technologies.

 

So I decided. I will extruct CSMT codes in separate dll and will keep it untouched.

Other part of wine will be CSMT-free so I may keep patches related to wine-hq.

We can also get useful patches from stage keeping their copyrights.

[ErmaC]

________ TO REMOVE __________

 

About the sherry-Wire GitHub repo...

(later I remove all my reply here... to keep the topic clear)

 

this mirror is just fine...

https://github.com/wine-mirror/wine

 

so I clone it (343 MB) and later add and remove the not needed stuff...

 

Fabio

[Slice]

Hi guys,

Something I can't understand here.

Undefined symbols for architecture i386:
  "_RegCloseKey", referenced from:
      _AUDDRV_GetEndpointIDs in mmdevdrv.o
      _AUDDRV_GetAudioEndpoint in mmdevdrv.o
  "_RegCreateKeyExW", referenced from:
      _AUDDRV_GetEndpointIDs in mmdevdrv.o
  "_RegEnumKeyExW", referenced from:
      _AUDDRV_GetAudioEndpoint in mmdevdrv.o
  "_RegOpenKeyExW", referenced from:
      _AUDDRV_GetEndpointIDs in mmdevdrv.o
      _AUDDRV_GetAudioEndpoint in mmdevdrv.o
  "_RegQueryValueExW", referenced from:
      _AUDDRV_GetEndpointIDs in mmdevdrv.o
      _AUDDRV_GetAudioEndpoint in mmdevdrv.o
  "_RegSetValueExW", referenced from:
      _AUDDRV_GetEndpointIDs in mmdevdrv.o
ld: symbol(s) not found for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)
winegcc: gcc failed
make[1]: *** [winecoreaudio.drv.so] Error 2
make: *** [dlls/winecoreaudio.drv] Error 2
make: *** Waiting for unfinished jobs....

But this folder exactly the same as in working project Sherry-1 before we move to git.

I aslo checked includes. All are the same.

What is supposed to be here?

Function RegQueryValueExW() is defined in other dll. I am not famous with Windows programming. What is the error?

Resolved! Makefile.in

 

IMPORTS   = uuid ole32 user32 advapi32