Re: WineSkin v0.01

2010-06-18 Thread ryan woodsmall

Hi All,

I just wanted to highlight my new project - WineSkin

http://www.airwebreathe.org.uk/wineskin/


Might want to rethink the name:

http://wineskin.doh123.com/Information.html




Re: too much dynamic loading?

2010-05-22 Thread ryan woodsmall

I'm not convinced direct linking will work better on Mac OS X, unless
you ship libpng and libjpeg with Wine.


And libgnutls (plus prereqs libgpg-error & libgcrypt). And libgphoto2,  
libexif, libtiff, libgsm, libjbig... - there's a laundry list of  
libraries that are required for a full-featured Wine install, and  
prereqs of prereqs, prereqs of THOSE. You get the point. Static  
libraries on Mac OS X/Darwin also misbehave in odd ways that you  
simply don't see with dylibs as well.


I package all of these up with osxwinebuilder, building shared libs  
from source, and it's a bit tricky. Things fail in unforeseen ways if  
a user's modified their environment. I had an issue this morning where  
libghoto2 was failing for version 2.4.9+, but working for anything  
older. Turns out that GD had been installed into /usr from source on  
Leopard, the user upgraded to Snow Leopard (which broke a few of GD's  
reqs), and libgphoto2 2.4.9+ now checks for GD, which it found,  
mysteriously breaking the compile. Had GD been compiled statically, it  
may have worked - or not. But that's not something I (or Wine) check  
for, just something I didn't consider until today when a prereq broke.


Wine really wants to map and use share libraries like they're supposed  
to be used: dynamically, when a module needs them. Pain in getting to  
that point on Macs is one reason there's not a binary Wine package  
available; licensing and binary distribution questions/methods is  
another. Static libraries may be a quick workaround, but ultimately  
full shared library coverage for all prereqs on all supported  
platforms is the way to go.


If you want a bad example, take a look at GSM. configure simply won't  
work with/find a static libgsm on OS X, but a manually-built dylib  
works just fine from what I can glean. The fact that the distributor 
(s) don't include an easy method for building shared GSM libs on OS X  
made this a little tricky to workaround IMO. But it's doable.


Kind of ranting. Let me know if clarification is needed on any point.  
Standard Wine on OS X may not work in a Mac user-friendly way, but it  
works very well if you just forego a GUI, have good prereq coverage  
and use it from the terminal. That's good enough for me! -r





Re: News on Wine 1.1.21/MacOSX/XQuartz 2.3.3

2009-05-17 Thread ryan woodsmall

On May 17, 2009, at 3:45 PM, Austin English wrote:


Ideally, against a more recent wine version.

Shameless plug:
I've got a script to do it, but no one that I know of is testing it on
OS X. If someone could test it, I'll add any needed fixes:
http://winezeug.googlecode.com/svn/trunk/build_script/daily.sh


I have (yet another) build script, but OS X requires a number of deps  
to be compiled and installed as Apple doesn't ship some libraries,  
headers, or ships incomplete packages here and there.  This is all  
pretty bare bones stuff.


I can vouch for functionality with Mac OS X 10.5.7 + XQuartz 2.3.3.1 +  
Wine 1.1.21 (from source).  If and when I can find some time IRL, I  
can get the entire Wine compile and install with deps scripted up.   
This of course depends on free time, which is always somewhat lacking.


Your script looks good, Austin - lots of functionality there!

  ryan woodsmall
rwoodsm...@mac.com


"Be well, do good work, and keep in touch." - Garrison Keillor