Memory Limitations for WINE 1.1.33 under Mac OS Leopard

tpatko · Post by **tpatko** » Sun Nov 29, 2009 12:33 pm

Dear WINE Forum Users:

I have built WINE 1.1.33 from source using the directions at posted at

http://wiki.winehq.org/MacOSX/Building

In particular I did the following:

./configure --disable-win16

make depend && make

Since I do not need any graphical libraries for the application that I wish to run under WINE everything runs fine for me using this build procedure.

My questions is that with earlier version of WINE (such as 1.1.18 and 1.1.21) when I did such a default compile, I was able to allocate up to 1520MB per process. Now using the same build procedure I can only allocate up to 1040MB per process. As my application (command line only with NO GUI components whatsoever) requires the ability to allocate rather large amounts of memory and the recent unstable WINE releases seems to be going in the wrong direction in terms of this issue (I can allocate LESS rather than MORE), I was wondering if there are some flags or options that would enable me to maximize the memory allocation with the newer WINE releases (at the very least to get back to the 1520 that was possible with the earlier releases).

My Mac OS is 10.5.8. Please let me know if any further information is required.

Thanks,

Thomas

vitamin · Post by **vitamin** » Sun Nov 29, 2009 12:44 pm

tpatko wrote:My questions is that with earlier version of WINE (such as 1.1.18 and 1.1.21) when I did such a default compile, I was able to allocate up to 1520MB per process.

Make sure your program is compiled with flag indicating it can support more then 2GB.

Wine can only allocate memory from lover 2GB address space for regular programs. And that's the area used by Wine itself and all the system libraries.

tpatko · Post by **tpatko** » Sun Nov 29, 2009 12:56 pm

Dear vitamin:

Thank you for the reply. I have some replies to your responses below.

Make sure your program is compiled with flag indicating it can support more then 2GB.

This program can indeed allocate more than 2GB of memory and is LARGEADDRESSAWARE. In any event the exact same binary that with a previous version of WINE (1.1.21) could allocate as much as 1520MB per process can now only allocate 1040MB per process with WINE 1.1.33 so in this case the difference cannot actually be the Windows binary itself that is the limiting factor.

Wine can only allocate memory from lover 2GB address space for regular programs. And that's the area used by Wine itself and all the system libraries.

Thank you for the explanation. I understand that there is some overhead due to WINE itself running. Has there been any major changes to the way that memory is allocated between WINE 1.1.21 and 1.1.33? When I used WINE 1.1.21 I was able to allocate up to 1520 per process irrespective of how many processes were called in parallel. In the case of my 8-core machine this meant as much as 12160MB could be called in aggregate for a single parallel MPI job run. A more thorough explanation of the Windows native memory capabilities and limitations for this program are posted at the link below.

http://classic.chem.msu.su/cgi-bin/ceil ... 138+00.htm

Thank you for your reply and assistance. I was hoping that some modification to the source code or some flags could allow me to return to the 1520MB per process memory capability of previous versions of WINE or (in an ideal world) possibly allocate closer to the 2GB limit of the Win32AP (I understand that 64-bit and 32-bit/64-bit multilib WINE builds are not supported on Mac as of yet).

Any assistance would be greatly appreciated.

Cheers,

Thomas

vitamin · Post by **vitamin** » Sun Nov 29, 2009 1:51 pm

tpatko wrote:Has there been any major changes to the way that memory is allocated between WINE 1.1.21 and 1.1.33? When I used WINE 1.1.21 I was able to allocate up to 1520 per process irrespective of how many processes were called in parallel.

There were some changes made, yes. You might want to file bug in Wine's bugzilla. If it worked before (on the same system with the same configuration) this points to a bug in Wine.

However you probably will be asked to perform regression testing as described here: http://wiki.winehq.org/RegressionTesting So you might as well do it now and test old Wine version still allocates 1.5 GB.

James McKenzie · Post by **James McKenzie** » Sun Nov 29, 2009 1:58 pm

tpatko wrote:

Dear vitamin:

Thank you for the reply. I have some replies to your responses below.

Make sure your program is compiled with flag indicating it can support more then 2GB.

This program can indeed allocate more than 2GB of memory and is LARGEADDRESSAWARE. In any event the exact same binary that with a previous version of WINE (1.1.21) could allocate as much as 1520MB per process can now only allocate 1040MB per process with WINE 1.1.33 so in this case the difference cannot actually be the Windows binary itself that is the limiting factor.

Wine can only allocate memory from lover 2GB address space for regular programs. And that's the area used by Wine itself and all the system libraries.

Thank you for the explanation. I understand that there is some overhead due to WINE itself running. Has there been any major changes to the way that memory is allocated between WINE 1.1.21 and 1.1.33? When I used WINE 1.1.21 I was able to allocate up to 1520 per process irrespective of how many processes were called in parallel. In the case of my 8-core machine this meant as much as 12160MB could be called in aggregate for a single parallel MPI job run. A more thorough explanation of the Windows native memory capabilities and limitations for this program are posted at the link below.

http://classic.chem.msu.su/cgi-bin/ceil ... 138+00.htm

Thank you for your reply and assistance. I was hoping that some modification to the source code or some flags could allow me to return to the 1520MB per process memory capability of previous versions of WINE or (in an ideal world) possibly allocate closer to the 2GB limit of the Win32AP (I understand that 64-bit and 32-bit/64-bit multilib WINE builds are not supported on Mac as of yet).

Any assistance would be greatly appreciated.

Thomas:

If it is permissible can you get me a copy of the program. I am
working, independently on Mike Kronenberg's Wine builds to solve
several outstanding bugs in Wine?

If not, can the program be publically downloaded off the Internet?

Have YOU filed a bug report on this?

Thank you.

James McKenzie

tpatko · Post by **tpatko** » Sun Nov 29, 2009 2:15 pm

Dear James:

Thank you for the offer to assist with this issue. I have NOT filed an official bug report with WINE bugzilla as I am training to ascertain the exact issues involved. I have not done regression testing before, so it would take me a bit of time to review all of these materials.

I have indeed used Mike Kronenberg's WINE binary builds to run this Windows program under Mac (you will see this in the documentation) although I have tested it against numerous WINE builds from source as well. Since there was no improvement to build from source I simply recommended using the precompiled binaries from Mike.

It is indeed possible to get a copy of the Firefly program. It is copyrighted but available free of charge (see download link below). You can download the binary for Mac from the public download page but will need a password to unrar them. Actually if you just complete the registration e-mail form (included in the quick shart guide) and just mention that you are working with Thomas Patko (the lead developer is quite familiar with me).

http://classic.chem.msu.su/gran/gamess/macosx.html

We are also now testing the new 7.1.G binary for Mac now as well (last official release it 7.1.F), and I can give you the download password and links to this directly as soon as you are a registered PC GAMESS / Firefly user.

Thanks,

Thomas

tpatko · Post by **tpatko** » Thu Dec 03, 2009 9:19 am

DEAR WINE DEVELOPERS:

I have a question related to the lowering of the maximum memory allocation per process from version 1.1.21 to 1.1.33 (described in this post).

Are there any plans to release WINE that includes support for 32/64-bit multilib on Snow Leopard? I believe that the Snow Leopard gcc compiler can now support this time of build as well as the Snow Leopard OS itself.

There are now many Windows applications that could greatly take advantage of a 32/64-bit multilib builds (older Win32 API for graphical portions of programs and 64-bit for computational and memory intensive back-end computing) and I believe that there are very many Mac users that use WINE.

Your consideration and comments are appreciated to this related follow-up question.

Thanks,

Thomas

vitamin · Post by **vitamin** » Thu Dec 03, 2009 9:52 am

tpatko wrote:There are now many Windows applications that could greatly take advantage of a 32/64-bit multilib builds (older Win32 API for graphical portions of programs and 64-bit for computational and memory intensive back-end computing) and I believe that there are very many Mac users that use WINE.

Wine's 64-bit support is still highly unstable and it does not work well with 32-bit version. However the 64-bit support is the main target for 1.2 release.

tpatko · Post by **tpatko** » Thu Dec 03, 2009 12:09 pm

DEAR WINE DEVELOPERS:

Using the following very simple memory test program (written by the lead PC GAMESS / Firefly developer Professor Alex Granovsky) I am able to reproduce the same memory limitations as reported for my computational chemistry program between WINE 1.1.21 and 1.1.33. The memory limitations are actually the same when running under LEOPARD AND SNOW LEOPARD and are irrespective of what OS it was compiled under.

#include <stdlib.h>
#include <stdio.h>
#include <windows.h>

void main (int argc, char* argv[]) {
unsigned int size;
void *ptr;

if (argc != 2) exit(1);

size = atoi(argv[1]);

if (size > 4095) exit(1);

ptr = VirtualAlloc(NULL,size<<20,MEM_RESERVE|MEM_COMMIT,PAGE_READWRITE);

if (!ptr) {
printf("Failed to allocate memory!");
exit(2);
}

printf("%d MB of virtual memory successfully allocated.",size);
exit(0);

}

Building this source and linking it as LARGEADDRESSAWARE should yield a suitable memory test binary. If necessary, I can send a precompiled binary.

This simple memory test program takes in a single argument in units of MB. For WINE 1.1.21 I get 1530MB as the limit (1540MB fails) and for WINE 1.1.33 I get 1010MB as the limit (1020MB fails). Any ideas and explanation for the deterioration in the ability to allocate memory between the older and newer versions?

Your assistance would be greatly appreciated!

Thanks,

Thomas

Alexandre Julliard · Post by **Alexandre Julliard** » Thu Dec 03, 2009 1:03 pm

"tpatko" <[email protected]> writes:

This simple memory test program takes in a single argument in units of
MB. For WINE 1.1.21 I get 1530MB as the limit (1540MB fails) and for
WINE 1.1.33 I get 1010MB as the limit (1020MB fails). Any ideas and
explanation for the deterioration in the ability to allocate memory
between the older and newer versions?

There is less contiguous address space because of the need to leave more
space available for OpenGL. The total amount available is still the
same, you should fix your code to allocate in smaller chunks.

--
Alexandre Julliard
[email protected]

tpatko · Post by **tpatko** » Thu Dec 03, 2009 1:18 pm

Dear Alexandre:

Thank you for the response. Well it seems that this particular bug (performance reduction in memory allocation from 1.1.21 to 1.1.33) is a Mac specific issue as best as I can tell. Building the same 1.1.33 source code under CentOS 64-bit in 32-bit mode does not yield this reduction in memory allocation limits that I have described.

For a variety of reasons it is not really possible to allocate this memory in smaller chunks as you suggest (in fact for these type of programs it is actually quite literally impossible). In terms of OpenGL this is completely unnecessary for my program to run through WINE. The program is a console only application (No GUI components whatsoever). Is it possible to build the current version of WINE (1.1.33 or newer) WITHOUT any OpenGL support and to help raise the memory limit back to where it was in the 1.1.21 version (or higher) by freeing up this memory that appears to be reserved for OpenGL in the Mac build.

Your thoughts and suggestions are appreciated.

Regards,

Thomas

Alexandre Julliard · Post by **Alexandre Julliard** » Thu Dec 03, 2009 2:01 pm

"tpatko" <[email protected]> writes:

Thank you for the response. Well it seems that this particular bug
(performance reduction in memory allocation from 1.1.21 to 1.1.33) is
a Mac specific issue as best as I can tell. Building the same 1.1.33
source code under CentOS 64-bit in 32-bit mode does not yield this
reduction in memory allocation limits that I have described.

Memory allocation on Linux is smarter so we can avoid the hardcoded
limit.

For a variety of reasons it is not really possible to allocate this
memory in smaller chunks as you suggest (in fact for these type of
programs it is actually quite literally impossible). In terms of
OpenGL this is completely unnecessary for my program to run through
WINE. The program is a console only application (No GUI components
whatsoever). Is it possible to build the current version of WINE
(1.1.33 or newer) WITHOUT any OpenGL support and to help raise the
memory limit back to where it was in the 1.1.21 version (or higher) by
freeing up this memory that appears to be reserved for OpenGL in the
Mac build.

You can change the memory sizes in loader/main.c to reserve more space
for WINE_DOS.

--
Alexandre Julliard
[email protected]

tpatko · Post by **tpatko** » Thu Dec 03, 2009 2:38 pm

Dear Alexandre:

Would the changing the memory sizes in loader/main.c to reserve more space for WINE_DOS as you have recommended as be correct if my program is a Win32 console application? It is not actually a legacy DOS application but rather a very modern Win32 console app (built with modern Intel Windows compilers) but without any graphical components (which is why I asked about building WINE without any graphical support).

Thanks,

Thomas

Alexandre Julliard · Post by **Alexandre Julliard** » Thu Dec 03, 2009 5:15 pm

"tpatko" <[email protected]> writes:

Dear Alexandre:

Would the changing the memory sizes in loader/main.c to reserve more
space for WINE_DOS as you have recommended as be correct if my program
is a Win32 console application?

Yes, it applies to all apps, the actual DOS part is only the first 1Mb
of the memory reservation.

--
Alexandre Julliard
[email protected]

tpatko · Post by **tpatko** » Sat Dec 05, 2009 5:40 pm

Dear WINE Developers and Users:

Thank you very much for your assistance about my question related to maximum memory allocation for WINE 1.1.33 build under Mac OS X Leopard and Snow Leopard. Indeed modification the __wine__dos variable in loader/main.c to a larger value did exactly what my project required. Using this modification I was able to successfully allocate up to ~ 1838MB per process (using a real world parallel 8-core MPI test job for a total of 14,704MB in aggregate) when built under Snow Leopard and up to ~ 1655MB per process when built under Leopard (also using this same real world parallel 8-core MPI test job for a total of 13,240MB in aggregate). I just thought that I would report my results in case they are useful for any other Mac users that need to use WINE for HPC type applications.

I do have two follow-up questions if you would be so kind as to assist me once again:

1) How can I package the custom binary that were built with the modified loader/main.c? All I need is for this WINE binary to be portable for use on other Mac Users machine. I plan to distribute separate WINE binaries for Leopard and Snow Leopard packages. I just want to make sure that there are no path of library dependency issues that I should be concerned with.

I know that I can do a "make install" but this will drop everything into my /usr/local/bin directory. I need to have all of the custom build WINE binaries (and dependencies if necessary) drop into a single directory which I can then include with my own Windows binaries and call to run my Windows programs. Is there an easy way to do this? I know that there are way to build WINE into a more robust application (as with Winebottler,...etc) but I do not need anything this complex. Since this WINE binary will be intended for use ONLY with this one program, I just need all of the WINE binaries delivered into a single directory without path or dependencies issue so that it the Windows binary can be run on any user's machine simply by calling this WINE binary to whatever location it will ultimately end up getting installed.

I hope that this request makes sense. I suppose that I could just copy the directory where I built WINE, but this directory is HUGE at over 400MB. I would like to make it as small as possible while ensuring that it still functions properly.

2) Is there anything special that I need to do to comply with the WINE license to distribute binary packages only? I made ONLY the change to the __wine_dos memory allocation variable (that is it). Is it sufficient for me to document my single change when redistributing binary package only or must all of the source code be distributed as well.

Thank you for all of the assistance to date and I look forward to finishing this project with your continued patience and help.

Cheers,

Thomas

Gert van den Berg · Post by **Gert van den Berg** » Sat Dec 05, 2009 5:55 pm

On Sun, Dec 6, 2009 at 00:40, tpatko <[email protected]> wrote:

2) Is there anything special that I need to do to comply with the WINE license to distribute binary packages only? Â I made ONLY the change to the __wine_dos memory allocation variable (that is it). Â Is it sufficient for me to document my single change when redistributing binary package only or must all of the source code be distributed as well.

First, I'm NOT a lawyer.... Asking one is probably a better idea. For
a start you should at least read the license...

As far as I understand the LGPL, you should have the source code (Wine
part with your modification to it, as used to build) available and
give it to anyone that has a copy of the program. (main difference
here between GPL and the LGPL here is that things using Wine/winelib
is not subject to it as well, as they would have been under the GPL)
You won't need to include it in the same package..

tpatko · Post by **tpatko** » Sat Dec 05, 2009 6:05 pm

Dear Gert:

Thank you for the reply. There is no problem for me to make the modified source available for download. Thank you for the suggestions. I will read the GPL and LGPL before distribute the WINE binaries that I have built to ensure that I am in compliance.

If anyone can assist with my question # 1 then I will be off an running

1) How can I package the custom binary that were built with the modified loader/main.c? All I need is for this WINE binary to be portable for use on other Mac Users machine. I plan to distribute separate WINE binaries for Leopard and Snow Leopard packages. I just want to make sure that there are no path of library dependency issues that I should be concerned with.

I know that I can do a "make install" but this will drop everything into my /usr/local/bin directory. I need to have all of the custom build WINE binaries (and dependencies if necessary) drop into a single directory which I can then include with my own Windows binaries and call to run my Windows programs. Is there an easy way to do this? I know that there are way to build WINE into a more robust application (as with Winebottler,...etc) but I do not need anything this complex. Since this WINE binary will be intended for use ONLY with this one program, I just need all of the WINE binaries delivered into a single directory without path or dependencies issue so that it the Windows binary can be run on any user's machine simply by calling this WINE binary to whatever location it will ultimately end up getting installed.

I hope that this request makes sense. I suppose that I could just copy the directory where I built WINE, but this directory is HUGE at over 400MB. I would like to make it as small as possible while ensuring that it still functions properly.

DaVince · Post by **DaVince** » Sat Dec 05, 2009 6:43 pm

There is no problem for me to make the modified source available for download.

For convenience, I think you can also just provide the patches that modify the original source code in the appropiate manner. That would save a lot of space on your server for those actually wanting the source (though you'd need to specify what Wine version the patch is for).

doh123 · Post by **doh123** » Sat Dec 05, 2009 8:52 pm

tpatko wrote: I know that there are way to build WINE into a more robust application (as with Winebottler,...etc) but I do not need anything this complex. Since this WINE binary will be intended for use ONLY with this one program, I just need all of the WINE binaries delivered into a single directory without path or dependencies issue so that it the Windows binary can be run on any user's machine simply by calling this WINE binary to whatever location it will ultimately end up getting installed.

If you want, I could help you get it working right with Wineskin... thats basically what Wineskin is made for, taking a single Windows app and porting it over as a normal Mac app with Wine and X11 and everything bundled up in the .app, so nothing extra has to be installed to the machine. It uses unmodified Wine source code, but I could make you a Wineskin compatible Wine compile with modified source if you'd like me too, just gimme the source or patch file and I can compile it.... it would be easier than you trying to replicate my whole environment. It would allow you to bundle up the Windows app inside the Wineskin wrapper, and it would act like a normal Mac app at that point, and run on 10.4 - 10.6. Once you see how it works, its actually pretty easy.

If you want to see more info on Wineskin... I listed it on 3rd party applications on the Wiki... or you can look here
http://wiki.winehq.org/Wineskin

if you get to the blog and look at the forums link, you'll have to register on the forums, but I have threads about custom Wine compiles and such.

tpatko · Post by **tpatko** » Sun Dec 06, 2009 9:34 am

Dear doh123:

Thank you for the reply. I have looked at Wineskin and am I now sure that this is exactly what I would need. I ONLY need to package the compiled wine binaries into a portable single directory (it actually does not need to be a native Mac .app at all unless this is for some reason truly necessary). My slightly custom build of WINE runs perfectly from where I built it and I can copy it to different directory locations and this seems to run just fine as well. What I am concerned about it whether it will run fine on user's machine as well or whether there are some runtime dependency issues with just copying it to a different machine as is. The other issue is to try and make it as SMALL as humanly possible, as the current size at over 400MB (uncompressed) is just really, really big.

Essentially I would hoping that there was a tool to do what Mike Kronenberg does to make just the Wine.app type distribution (although again for me a regular directory rather than a *.app type structure is just fine). For my application I do not care at all about any graphical compatibility issues (my single Windows program is wine32 console app so the graphical issues are completely irrelevant).

http://winebottler.kronenberg.org/

In terms of my modification, it is only a single change to the loader/main.c file as follows:

#ifdef __APPLE__

__asm__(".zerofill WINE_DOS, WINE_DOS, ___wine_dos, 0x78000000");
__asm__(".zerofill WINE_SHAREDHEAP, WINE_SHAREDHEAP, ___wine_shared_heap, 0x03000000");
extern char __wine_dos[0x78000000], __wine_shared_heap[0x03000000];

That is it. Everything else is build in a purely default way. Essentially just changed the "0x40000000" to "0x78000000" to limit the upper memory allocation bound. I have done some rather extensive testing and this works in a stable way for my application of interest (and my WINE package distribution would NOT be intended for use with any other Windows applications). I do build separately for Leopard and Snow Leopard as I get better performance in Snow Leopard when I build it in SL. I have no plans to support Tiger any longer (user that need Tiger support can still use the previous release).

Does my questions make more sense now?

Sorry if I was not clear.

Thanks,

Thomas

doh123 · Post by **doh123** » Mon Dec 07, 2009 11:30 am

The app structure is the best for OSX, and easy to move around and work, just throw it on any machine in any folder and double click and run the app, just like its a native OSX app.... but if you just want a folder with wine in it, that works too.

if you build it on the same OS version you want to run it on, and just move it and run it under X11.app... thats not hard at all.

Any library missing on the other machine that is needed, that Wine was compiled against, you will figure out pretty easy when you actually try to move it and run it, it will give errors about missing libraries... then you know to add those libraries in.

build wine to a custom prefix... when you build it, so you get just the files you need for wine, not a bunch of extra junk... you can do this with the --prefix command on ./configure. if yours is 400mb your getting a bunch of extra stuff. full wine build should be around 100mb... less if you disable a bunch of stuff in configure you don't need. If it complains about not being able to find certain libraries, just make a launch script that adds in DYLD_FALLBACK_LIBRARY_PATH to the folders of any libraries it complains about... so if it doesn't find them, it will check where you told it to check.

tpatko · Post by **tpatko** » Mon Dec 07, 2009 11:49 am

Dear doh123:

Thank you for the response. I do have some follow-up questions and comments if you please.

The app structure is the best for OSX, and easy to move around and work, just throw it on any machine in any folder and double click and run the app, just like its a native OSX app.... but if you just want a folder with wine in it, that works too.

OK. For me it does not make any difference to have it as a .app or just an ordinary directory except if this improves portability across different OS versions and machines. How do I convert my WINE build into a .app?

if you build it on the same OS version you want to run it on, and just move it and run it under X11.app... thats not hard at all.

I do not care about X11 compatibility as my application is a win32 console only application. Even none of the graphical components work at all, my application will none the worse for this. So far it seems OK, to just copy and paste the build directory to different machines, I was just more concerned about how BIG the complete build directory was.

Any library missing on the other machine that is needed, that Wine was compiled against, you will figure out pretty easy when you actually try to move it and run it, it will give errors about missing libraries... then you know to add those libraries in.

I would hope that there are not any missing libraries as I have just done a default build with few if any modules enabled (the --verbose configure lists lots of things that were in fact not built).

build wine to a custom prefix... when you build it, so you get just the files you need for wine, not a bunch of extra junk... you can do this with the --prefix command on ./configure. if yours is 400mb your getting a bunch of extra stuff. full wine build should be around 100mb... less if you disable a bunch of stuff in configure you don't need. If it complains about not being able to find certain libraries, just make a launch script that adds in DYLD_FALLBACK_LIBRARY_PATH to the folders of any libraries it complains about... so if it doesn't find them, it will check where you told it to check.

Can you please provide me _EXACTLY_ the configure options that I should use for example to build to the ultimate directory path /Applications/Firefly/WINE for example such that it will have maximum portaibility across OS and difference machines? My default build just using ./configure --disable-win16 is what yielded the 400MB+ total directory size (this include the original source code and the resulting binaries). I would indeed very much like this to shrink to the ~100MB size that you indicate (this seems to tractable).

I thank you very much for your assistance.

Best Regards,

Thomas Patko

doh123 · Post by **doh123** » Mon Dec 07, 2009 12:47 pm

tpatko wrote: I do not care about X11 compatibility as my application is a win32 console only application. Even none of the graphical components work at all, my application will none the worse for this. So far it seems OK, to just copy and paste the build directory to different machines, I was just more concerned about how BIG the complete build directory was.

Wine requires X11, it will be compiled against X11 installed on the machine.... you have little choice in that. You could add in the winequartz.drv driver for OSX to the source code and modify it to use that instead... but its very far from good, and wont run most things, but it might work if you don't need graphical stuff, but it would probably be waaaay too much of a headache.... much better to stick with the winex11.drv

tpatko wrote: Can you please provide me _EXACTLY_ the configure options that I should use for example to build to the ultimate directory path /Applications/Firefly/WINE for example such that it will have maximum portaibility across OS and difference machines? My default build just using ./configure --disable-win16 is what yielded the 400MB+ total directory size (this include the original source code and the resulting binaries). I would indeed very much like this to shrink to the ~100MB size that you indicate (this seems to tractable).

Are you not installing it? maybe your just building it and ending with the "make" command and running it out of the source folder? Thats a ton of wasted space as well.

to install you first do the ./configure, then a make depend, then a make, then a make install .... if you left off the make install and run it from the source folder, you will have a huge folder.

when you go to configure, do a

Code: Select all

./configure --help

and look at all the options you have... you can specify MANY things. I have no idea which all ones will suit your needs because I just don't have enough information... you can put many many flags on a ./configure though. I'd recommend at minimum to set a prefix on it, and to do a "make install" at the end to install to that prefix... something like this.

Code: Select all

./configure --prefix=/Applications/Wine --disable-win16
make depend
make
make install

this will make Wine build for, and install to running in /Applications/Wine
There are also many other --without commands you can see o the help, to build without things you don't need.

Gert van den Berg · Post by **Gert van den Berg** » Mon Dec 07, 2009 2:04 pm

On Mon, Dec 7, 2009 at 19:47, doh123 <[email protected]> wrote:

and look at all the options you have... you can specify MANY things. Â I have no idea which all ones will suit your needs because I just don't have enough information... you can put many many flags on a ./configure though. Â I'd recommend at minimum to set a prefix on it, and to do a "make install" at the end to install to that prefix... something like this.

Code:

./configure --prefix=/Applications/Wine --disable-win16
make depend
make
make install

this will make Wine build for, and install to running in /Applications/Wine
There are also many other --without commands you can see o the help, to build without things you don't need.

he wants to package it... So just installing it is probably not the
best method. (configuring for a custom directory and the installing it
might work though....) (--prefix=~/my_wine for example)
(a 'make tarball' kind of command would have been handy...)

doh123 · Post by **doh123** » Mon Dec 07, 2009 2:59 pm

Gert van den Berg wrote:On Mon, Dec 7, 2009 at 19:47, doh123 <[email protected]> wrote:
and look at all the options you have... you can specify MANY things. Â I have no idea which all ones will suit your needs because I just don't have enough information... you can put many many flags on a ./configure though. Â I'd recommend at minimum to set a prefix on it, and to do a "make install" at the end to install to that prefix... something like this.

Code:

./configure --prefix=/Applications/Wine --disable-win16
make depend
make
make install

this will make Wine build for, and install to running in /Applications/Wine
There are also many other --without commands you can see o the help, to build without things you don't need.
he wants to package it... So just installing it is probably not the
best method. (configuring for a custom directory and the installing it
might work though....) (--prefix=~/my_wine for example)
(a 'make tarball' kind of command would have been handy...)

except he can easily right click the Wine folder here and hit "compress" makes a transportable zip, throw it on any other Mac's /Applications folder, double click the zip... and its there on the other machine...

not totalyl sure there wont be permission problems though, which is why I like using things in .apps, they get special permissions, helps make it more transportable.

if he wants a full install program, he can use the package maker that comes with Xcode, and make an installer from the install....