Hello!
The attached script makes it possible to compile many programs from Wine under Windows. The only software needed on Windows is Cygwin with MinGW libraries and some other utilities (flex, bison). Simply run setup.exe from www.cygwin.com and make sure to select MinGW development tools. Then get Wine sources, and run the attached script in the Cygwin shell while in the Wine top-level source directory.
There is one minor fix that needs to be applied to the sources to fix compatibility with MinGW headers (run autoconf and autoheader after applying): http://www.winehq.org/hypermail/wine-patches/2003/09/att-0347/01-spawnvp.dif...
The configure script is rather slow in Cygwin, so it's instructed not to create makefiles, only config.h. Then the necessary libraries are compiled. The next step is to link wrc, the Wine resource compiler.
Once wrc is ready, the script starts compiling programs. I cannot get windres to compile most Wine's resources directly, so there are compiled from *.rc to *.res by wrc and then from *.res to *.o by windres.
Programs currently compiled by the script:
clock.exe cmdlgtst.exe notepad.exe progman.exe regedit.exe start.exe view.exe wcmd.exe winefile.exe winemine.exe winhelp.exe winver.exe
Yes, you can play winemine on Windows now ;-)
On September 23, 2003 11:02 pm, Pavel Roskin wrote:
The attached script makes it possible to compile many programs from Wine under Windows. The only software needed on Windows is Cygwin with MinGW libraries and some other utilities (flex, bison). Simply run setup.exe from www.cygwin.com and make sure to select MinGW development tools. Then get Wine sources, and run the attached script in the Cygwin shell while in the Wine top-level source directory.
Cool, but wouldn't it be even nicer if we could build everything out of our Makefiles directly? It may be a bit trickier to integrate cleanly into our build system, but I think the result is much nicer.
On Tue, 23 Sep 2003, Dimitrie O. Paun wrote:
On September 23, 2003 11:02 pm, Pavel Roskin wrote:
The attached script makes it possible to compile many programs from Wine under Windows. The only software needed on Windows is Cygwin with MinGW libraries and some other utilities (flex, bison). Simply run setup.exe from www.cygwin.com and make sure to select MinGW development tools. Then get Wine sources, and run the attached script in the Cygwin shell while in the Wine top-level source directory.
Cool, but wouldn't it be even nicer if we could build everything out of our Makefiles directly? It may be a bit trickier to integrate cleanly into our build system, but I think the result is much nicer.
I agree. I think it's possible, but I wanted to start with something that works with no changes to the sources. Better integration will require more changes than just spawnvp fix.
For example, winefile.exe needs "-luuid" in MinGW because it provides IID_IDataObject. In Wine, IID_IDataObject is defined in include/objidl.h and a constant number. Wine doesn't have uuid library.
Some resource files refer to icons if __WINE__ is not defined. The icons are missing. Perhaps those references can be removed. Alternatively, icon resources should be converted to the binary format in Wine. I don't know if the reason to use text representations was because of wrc limitations or to avoid binaries in Wine CVS.
Also, some programs overuse WINE_ERR, like winecfg.exe. It should be possible to disable all text messages, even the most important ones, or direct them to some other place.
On September 23, 2003 11:59 pm, Pavel Roskin wrote:
For example, winefile.exe needs "-luuid" in MinGW because it provides IID_IDataObject. In Wine, IID_IDataObject is defined in include/objidl.h and a constant number. Wine doesn't have uuid library.
We have one, and it's called wine_uuid (libs/uuid). If we switch over to winegcc at least for the apps, it will take care of it, you just need to pass it -luuid just like in Windows.
Some resource files refer to icons if __WINE__ is not defined. The icons are missing. Perhaps those references can be removed. Alternatively, icon resources should be converted to the binary format in Wine. I don't know if the reason to use text representations was because of wrc limitations or to avoid binaries in Wine CVS.
Yes, to avoid binaries in CVS. But what is the problem, icons can't be in text format? If no, we'll just have to use wrc, not a problem I guess (even though would be nice to be able to build using windres).
Also, some programs overuse WINE_ERR, like winecfg.exe. It should be possible to disable all text messages, even the most important ones, or direct them to some other place.
winecfg is still in flux/heavy development just ignore it for now.
On Wed, 24 Sep 2003, Dimitrie O. Paun wrote:
On September 23, 2003 11:59 pm, Pavel Roskin wrote:
For example, winefile.exe needs "-luuid" in MinGW because it provides IID_IDataObject. In Wine, IID_IDataObject is defined in include/objidl.h and a constant number. Wine doesn't have uuid library.
We have one, and it's called wine_uuid (libs/uuid). If we switch over to winegcc at least for the apps, it will take care of it, you just need to pass it -luuid just like in Windows.
I have looked at winegcc source and it seems it will greatly improve portability. I think it's a good idea to switch to winegcc first.
Thoose who compile large projects with Wine are not likely to abandon the Windows version, so it's helpful to minimize differences in the code for different platforms. If we consider Wine programs as test examples, they should compile for Windows cleanly and use winegcc when compiled in Wine if we are to recommend winegcc for outside projects.
Some resource files refer to icons if __WINE__ is not defined. The icons are missing. Perhaps those references can be removed. Alternatively, icon resources should be converted to the binary format in Wine. I don't know if the reason to use text representations was because of wrc limitations or to avoid binaries in Wine CVS.
Yes, to avoid binaries in CVS. But what is the problem, icons can't be in text format? If no, we'll just have to use wrc, not a problem I guess (even though would be nice to be able to build using windres).
I just don't like defining __WINE__ in wrc when not compiling for Wine. But it's not a big deal. I'm attaching a patch that shows what I mean. Apply it if you like it.
On September 24, 2003 03:47 am, Pavel Roskin wrote:
I have looked at winegcc source and it seems it will greatly improve portability. I think it's a good idea to switch to winegcc first.
Thoose who compile large projects with Wine are not likely to abandon the Windows version, so it's helpful to minimize differences in the code for different platforms. If we consider Wine programs as test examples, they should compile for Windows cleanly and use winegcc when compiled in Wine if we are to recommend winegcc for outside projects.
Yes, this was my primary motivation for developing winegcc. A build system is a nontrivial thing (sometimes quite complicated/cryptic), and maintaining two of them is just too much to ask. Even if someone invests the time to develop a Wine specific one when porting an app to Wine, it will most likely become obsolete in no time.
To test the winegcc concept, I've already ported a number of app (which had a MinGW build system before) such as wxWindows, visual-mingw, putty, etc. They indeed worked with minimal changes to their Makefiles. The changes that were done were for the sake of portability and actually improved their build process in the MinGW case. So it's now possible to build for Wine and MinGW from the same sources & build systems. We are still lacking DLL generation support though. For more information on this effort, check this out: http://www.winehq.org/site/winelib
I just don't like defining __WINE__ in wrc when not compiling for Wine. But it's not a big deal. I'm attaching a patch that shows what I mean. Apply it if you like it.
I'm not sure why we had those defines in there. In general, we try to avoid defines like the plague in the Wine tree, so your patch is much appreciated. It seems that was some code the initial developers had in there for their own testing, and somehow it slipped in. Please send your patch to wine-patches for inclusion in the tree.
"Dimitrie O. Paun" dpaun@rogers.com writes:
I'm not sure why we had those defines in there. In general, we try to avoid defines like the plague in the Wine tree, so your patch is much appreciated. It seems that was some code the initial developers had in there for their own testing, and somehow it slipped in.
No, it's here so that you can compile with other resource compilers that don't support having binary data inline. It could be changed to #ifdef __WRC__ though.
On Wed, 24 Sep 2003, Alexandre Julliard wrote:
No, it's here so that you can compile with other resource compilers that don't support having binary data inline. It could be changed to #ifdef __WRC__ though.
Are there such beasts? I didn't know this is a Wine extension... But even if it is, one thing we can do is to integrate the bin2res into the build process. We can place the embedded data inside comments, and run bin2res before compiling an .rc file. It is quite fast, it will not add anything significant to the build process, and will get rid of the defines in the process. Plus it will make it a lot more explicit how this bin2res business works, it is not a all clear when you've never worked with it before (and I speak from personal experience :)).
"Dimitrie O. Paun" dimi@intelliware.ca writes:
Are there such beasts? I didn't know this is a Wine extension... But even if it is, one thing we can do is to integrate the bin2res into the build process. We can place the embedded data inside comments, and run bin2res before compiling an .rc file.
Yes that's the right way to do it. The only drawback is that we will need to list the dependencies explicitly in the makefile; but we need that to really support other resource compilers anyway.
On Wed, 24 Sep 2003, Alexandre Julliard wrote:
Yes that's the right way to do it. The only drawback is that we will need to list the dependencies explicitly in the makefile; but we need that to really support other resource compilers anyway.
Well, dependencies are not a problem: I can modify bin2res to output the name of the dependencies, and then 'make depend' can include them just like it does with the others...
Should I send a patch?
"Dimitrie O. Paun" dimi@intelliware.ca writes:
Well, dependencies are not a problem: I can modify bin2res to output the name of the dependencies, and then 'make depend' can include them just like it does with the others...
I don't really see how you would do that, especially not to make it do the right thing on make clean etc. I think we'll just want to list the files manually.
Should I send a patch?
Sure go ahead.
On September 24, 2003 07:02 pm, Alexandre Julliard wrote:
I don't really see how you would do that, especially not to make it do the right thing on make clean etc. I think we'll just want to list the files manually.
I'm definitely missing something here. I figured that if we have a file called rsrc.rc with 3 embedded bitmaps in it called bitmap[123].bmp, we need a rule like so:
bitmap1.bmp bitmap2.bmp bitmap3.bmp: rsrc.rc bin2res !<
That can be generated automatically, but from what you're saying it will not work. Care to elaborate a bit?
"Dimitrie O. Paun" dpaun@rogers.com writes:
I'm definitely missing something here. I figured that if we have a file called rsrc.rc with 3 embedded bitmaps in it called bitmap[123].bmp, we need a rule like so:
bitmap1.bmp bitmap2.bmp bitmap3.bmp: rsrc.rc bin2res !<
That can be generated automatically, but from what you're saying it will not work. Care to elaborate a bit?
I thought you were talking about doing it in make depend, and this won't work. Now if you want to generate it directly into the Makefile.in then of course that's possible, but I don't think we want to generate rules, these belong in Make.rules. What you could do is have bin2res output a simple "RCBINARIES = bitmap1.bmp bitmap2.bmp" that we can then paste into the Makefile.in.
Maybe I missed something here but why do you need bin2res at all? WRC can compile the resources to be linked by windres/MS_VC. We have the #ifdef WINE in regedit because the ReactOS people are lazy and havent merged wrc in to our CVS yet. I build these applications all the time on Windows using MSYS and Cygwin. I really dont think we need to support yet another way to build on Windows when you already have MSYS/Cygwin or MS_VC and none of them work 100% right.
Thanks Steven
--- Alexandre Julliard julliard@winehq.org wrote:
"Dimitrie O. Paun" dpaun@rogers.com writes:
I'm definitely missing something here. I figured that if we have a file called rsrc.rc with 3 embedded bitmaps in it called bitmap[123].bmp, we need a rule like so:
bitmap1.bmp bitmap2.bmp bitmap3.bmp: rsrc.rc bin2res !<
That can be generated automatically, but from what you're saying it will not work. Care to elaborate a bit?
I thought you were talking about doing it in make depend, and this won't work. Now if you want to generate it directly into the Makefile.in then of course that's possible, but I don't think we want to generate rules, these belong in Make.rules. What you could do is have bin2res output a simple "RCBINARIES = bitmap1.bmp bitmap2.bmp" that we can then paste into the Makefile.in.
__________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com
On Thu, 25 Sep 2003, Steven Edwards wrote:
Maybe I missed something here but why do you need bin2res at all? WRC can compile the resources to be linked by windres/MS_VC. We have the #ifdef WINE in regedit because the ReactOS people are lazy and havent merged wrc in to our CVS yet. I build these applications all the time on Windows using MSYS and Cygwin. I really dont think we need to support yet another way to build on Windows when you already have MSYS/Cygwin or MS_VC and none of them work 100% right.
Yes, we could just use wrc, but it would be nice to not depend on that, and just use the resource compiler that comes with the tools we use to do the compilation, just like we use gcc/ld/etc. when we compile on MinGW. Why not also use windres? Or rc on MSVC?
On Thu, 25 Sep 2003, Alexandre Julliard wrote:
I thought you were talking about doing it in make depend, and this won't work. Now if you want to generate it directly into the Makefile.in then of course that's possible, but I don't think we want to generate rules, these belong in Make.rules. What you could do is have bin2res output a simple "RCBINARIES = bitmap1.bmp bitmap2.bmp" that we can then paste into the Makefile.in.
Yeah, but if we do that we'll have to maintain them manually. What about something like this:
In Make.rules
.rc.extract: bin2res $< && touch $@
%.res: %.rc %.extract $(WRC) -o $@ $<
In make depend:
bitmap1.bmp bitmap2.bmp bitmap3.bmp: rsrc.extract
rsrc.res: bitmap1.bmp bitmap2.bmp bitmap3.bmp
rsrc.extract: rsrc.rc
So, if the .rc changes, the .extract will be rebuilt, which means the .bmp will be updated, as well as .res. Similarlly, if the .bmp will change, the .res will rebuild.
The only problem is that if you change the .bmp, then you change the .rc, you will lose the .bmp changes...
"Dimitrie O. Paun" dimi@intelliware.ca writes:
Yeah, but if we do that we'll have to maintain them manually.
I don't think that's a real problem, these files don't change often. It certainly doesn't justify adding a complicated infrastructure to deal with it.
Pavel Roskin wrote:
I have looked at winegcc source and it seems it will greatly improve portability. I think it's a good idea to switch to winegcc first.
Provided you don't care about delay-loading libraries, you can already compile the programs with winegcc. Here's the patch
-- Richard
diff -u -r programs/Makeprog.rules.in programs/Makeprog.rules.in --- programs/Makeprog.rules.in 2003-06-17 08:10:37.000000000 +0100 +++ programs/Makeprog.rules.in 2003-09-24 14:31:34.000000000 +0100 @@ -19,25 +19,24 @@
@MAKE_RULES@
-all: $(MODULE)$(DLLEXT) $(BASEMODULE)$(EXEEXT) +all: $(MODULE)$(DLLEXT)
# Rule for main module spec file +APPTYPE1=$(APPMODE:%gui=windows) +APPTYPE=$(APPTYPE1:%cui=console) +# where we can find winegcc, winewrap, winebuild +TOOLSPATH=$(TOOLSDIR)/tools/winegcc:$(TOOLSDIR)/tools/winebuild +WINEGCC=PATH=$(TOOLSPATH):$(PATH) winegcc
-$(MODULE).spec.c: $(RC_SRCS:.rc=.res) $(ALL_OBJS) $(WINEBUILD) - $(WINEBUILD) $(DEFS) -o $@ --exe $(MODULE) $(APPMODE:%=--exe-mode %) $(RC_SRCS:.rc=.res) $(ALL_OBJS) -L$(DLLDIR) $(DELAYIMPORTS:%=-d%) $(IMPORTS:%=-l%) +.c.o : + $(WINEGCC) $(ALLCFLAGS) -o $@ -c $<
# Rules for .so main module
-$(MODULE).so: $(MODULE).spec.o $(ALL_OBJS) Makefile.in - $(LDSHARED) $(LDDLLFLAGS) $(MODULE).spec.o $(ALL_OBJS) -o $@ $(ALL_LIBS) -lc - -$(BASEMODULE): $(WINEWRAPPER) - $(RM) $@ && $(LN_S) $(WINEWRAPPER) $@ - -# Rules for .exe main module - -$(MODULE): $(ALL_OBJS) $(RCOBJS) Makefile.in - $(CC) $(ALL_OBJS) $(RCOBJS) -o $@ $(DELAYIMPORTS:%=-l%) $(IMPORTS:%=-l%) $(ALL_LIBS) +$(MODULE).so: $(ALL_OBJS) $(RC_SRCS:.rc=.res) Makefile.in $(WINEWRAPPER) + $(RM) $(BASEMODULE) + $(WINEGCC) -m$(APPTYPE) $(ALLCFLAGS) $(ALL_OBJS) $(RC_SRCS:.rc=.res) -o $(MODULE) -L$(DLLDIR) -L$(LIBDIR) $(EXTRALIBS) $(LIBPORT) -Wl $(LDFLAGS) $(DELAYIMPORTS:%=-l%) $(IMPORTS:%=-l%) + $(RM) $(BASEMODULE) && $(LN_S) $(WINEWRAPPER) $(BASEMODULE)
# Rules for testing
On Wed, 24 Sep 2003, Richard Cohen wrote:
Provided you don't care about delay-loading libraries, you can already compile the programs with winegcc. Here's the patch
+$(MODULE).so: $(ALL_OBJS) $(RC_SRCS:.rc=.res) Makefile.in $(WINEWRAPPER) + $(RM) $(BASEMODULE) + $(WINEGCC) -m$(APPTYPE) $(ALLCFLAGS) $(ALL_OBJS) $(RC_SRCS:.rc=.res) -o $(MODULE) -L$(DLLDIR) -L$(LIBDIR) $(EXTRALIBS) $(LIBPORT) -Wl $(LDFLAGS) $(DELAYIMPORTS:%=-l%) $(IMPORTS:%=-l%) + $(RM) $(BASEMODULE) && $(LN_S) $(WINEWRAPPER) $(BASEMODULE)
Maybe we should just drop the WINEWRAPPER thing altogether, it's not that important IMO to run programs out of the tree. There are other things that are a lot more useful, and we can't do them out of the tree.
On Wed 24. September 2003 06:08, Dimitrie O. Paun wrote:
Some resource files refer to icons if __WINE__ is not defined. The icons are missing. Perhaps those references can be removed. Alternatively, icon resources should be converted to the binary format in Wine. I don't know if the reason to use text representations was because of wrc limitations or to avoid binaries in Wine CVS.
Yes, to avoid binaries in CVS. But what is the problem, icons can't be in text format? If no, we'll just have to use wrc, not a problem I guess (even though would be nice to be able to build using windres).
What is that bad with binary data in CVS, as long as used for those small picture files?
I think, we can and should store such files like icons and bitmaps in binary format. There is no point to avoid this. CVS supports it with "-kb". We don't need keyword expansion for this files. And we don't want to change only parts of this files. If we change them, they can be changed as a whole. One more advantage: If you store this binary data inline in text format in the .rc files, they need at least three times more space as really needed.
I tried to compile my explorer as winelib application, and got to this problem: How to compile a resource file, which has no problems with RC or WINDRES with WRC? When inlining all the picture files with bin2res, I get a really huge RC file.
Martin Fuchs martin-fuchs@gmx.net writes:
I tried to compile my explorer as winelib application, and got to this problem: How to compile a resource file, which has no problems with RC or WINDRES with WRC?
If it compiles with rc and windres then it should compile with wrc too. The inline stuff is a wrc extension, but you don't have to use it, the normal mode should work just fine with wrc.
On Sun 28. September 2003 04:23, Alexandre Julliard wrote:
Martin Fuchs martin-fuchs@gmx.net writes:
I tried to compile my explorer as winelib application, and got to this problem: How to compile a resource file, which has no problems with RC or WINDRES with WRC?
If it compiles with rc and windres then it should compile with wrc too. The inline stuff is a wrc extension, but you don't have to use it, the normal mode should work just fine with wrc.
Thanks for the tip. I was not aware of that because I always got WRC error messages like "explorer_intres.rc:337:58: Error: Cannot handle UNICODE filenames" when using IDI_EXPLORER ICON DISCARDABLE "res/explorer.ico"
Now I tried once more and found this works: IDI_EXPLORER ICON DISCARDABLE res/explorer.ico
Why doesn't the standard way with quotation marks work? I think this is a bug and should be corrected in wrc?
Martin Fuchs martin-fuchs@gmx.net writes:
I was not aware of that because I always got WRC error messages like "explorer_intres.rc:337:58: Error: Cannot handle UNICODE filenames" when using IDI_EXPLORER ICON DISCARDABLE "res/explorer.ico"
Now I tried once more and found this works: IDI_EXPLORER ICON DISCARDABLE res/explorer.ico
Why doesn't the standard way with quotation marks work? I think this is a bug and should be corrected in wrc?
Yes that's a bug. I think this should fix it:
Index: tools/wrc/parser.y =================================================================== RCS file: /home/winehq/opt/cvs-commit/wine/tools/wrc/parser.y,v retrieving revision 1.39 diff -u -p -r1.39 parser.y --- tools/wrc/parser.y 18 Sep 2003 04:31:15 -0000 1.39 +++ tools/wrc/parser.y 28 Sep 2003 21:00:02 -0000 @@ -137,6 +137,7 @@ #include "newstruc.h" #include "dumpres.h" #include "wine/wpp.h" +#include "wine/unicode.h" #include "parser.h" #include "windef.h" #include "winbase.h" @@ -202,7 +203,7 @@ static raw_data_t *merge_raw_data(raw_da static raw_data_t *str2raw_data(string_t *str); static raw_data_t *int2raw_data(int i); static raw_data_t *long2raw_data(int i); -static raw_data_t *load_file(string_t *name); +static raw_data_t *load_file(string_t *name, language_t *lang); static itemex_opt_t *new_itemex_opt(int id, int type, int state, int helpid); static event_t *add_string_event(string_t *key, int id, int flags, event_t *prev); static event_t *add_event(int key, int id, int flags, event_t *prev); @@ -1795,10 +1796,7 @@ raw_elements ;
/* File data or raw data */ -file_raw: filename { - $$ = load_file($1); - $$->lvc.language = dup_language(currentlanguage); - } +file_raw: filename { $$ = load_file($1,dup_language(currentlanguage)); } | raw_data { $$ = $1; } ;
@@ -2282,14 +2280,18 @@ static itemex_opt_t *new_itemex_opt(int }
/* Raw data functions */ -static raw_data_t *load_file(string_t *name) +static raw_data_t *load_file(string_t *filename, language_t *lang) { FILE *fp = NULL; char *path; raw_data_t *rd; - if(name->type != str_char) - yyerror("Filename must be ASCII string"); + string_t *name; + int codepage = get_language_codepage(lang->id, lang->sub);
+ /* FIXME: we may want to use utf-8 here */ + if (codepage <= 0 && filename->type != str_char) + yyerror("Cannot convert filename to ASCII string"); + name = convert_string( filename, str_char, codepage ); if (!(path = wpp_find_include(name->str.cstr, 1))) yyerror("Cannot open file %s", name->str.cstr); if (!(fp = fopen( path, "rb" ))) @@ -2302,6 +2304,8 @@ static raw_data_t *load_file(string_t *n rd->data = (char *)xmalloc(rd->size); fread(rd->data, rd->size, 1, fp); fclose(fp); + rd->lvc.language = lang; + free_string(name); return rd; }
@@ -2678,13 +2682,11 @@ static toolbar_item_t *get_tlbr_buttons_
static string_t *make_filename(string_t *str) { + if(str->type == str_char) + { char *cptr;
- if(str->type != str_char) - yyerror("Cannot handle UNICODE filenames"); - /* Remove escaped backslash and convert to forward */ - cptr = str->str.cstr; for(cptr = str->str.cstr; (cptr = strchr(cptr, '\')) != NULL; cptr++) { if(cptr[1] == '\') @@ -2694,8 +2696,23 @@ static string_t *make_filename(string_t } *cptr = '/'; } + } + else + { + WCHAR *wptr;
- return str; + /* Remove escaped backslash and convert to forward */ + for(wptr = str->str.wstr; (wptr = strchrW(wptr, '\')) != NULL; wptr++) + { + if(wptr[1] == '\') + { + memmove(wptr, wptr+1, strlenW(wptr)); + str->size--; + } + *wptr = '/'; + } + } + return str; }
/*
I was not aware of that because I always got WRC error messages like "explorer_intres.rc:337:58: Error: Cannot handle UNICODE filenames" when using IDI_EXPLORER ICON DISCARDABLE "res/explorer.ico"
Now I tried once more and found this works: IDI_EXPLORER ICON DISCARDABLE res/explorer.ico
Why doesn't the standard way with quotation marks work? I think this is a bug and should be corrected in wrc?
Yes that's a bug. I think this should fix it:
Yes - it is now OK. Thanks for the fast fix!
Most of it should already build under Cygwin as cygwin1b apps. just $ ./configure && make tools && cd dlls && make
You will have trouble with kernel32 and ntdll. Also there is a patch to build Wineserver on cygwin floating around.
If you want to build apps that are linked to msvcrt.dll rather than cygwin runtime dont use cygwin. I tried using the -fno-cygwin option in the past but the problem is that some of the other librarys we link to such as -fl and GL are linked to cygwin so you will end up with programs that try to import both msvcrt and cygwin. I would recommend you get Mingw + MSYS from www.sourceforge.net/projects/mingw and follow my directions for doing a WINE build on Windows from here.
http://reactos.wox.org/rosdocs/bk02pt02ch15.html
Thanks Steven
--- "Dimitrie O. Paun" dpaun@rogers.com wrote:
On September 23, 2003 11:02 pm, Pavel Roskin wrote:
The attached script makes it possible to compile many programs from
Wine
under Windows. The only software needed on Windows is Cygwin with
MinGW
libraries and some other utilities (flex, bison). Simply run
setup.exe
from www.cygwin.com and make sure to select MinGW development
tools.
Then get Wine sources, and run the attached script in the Cygwin
shell
while in the Wine top-level source directory.
Cool, but wouldn't it be even nicer if we could build everything out of our Makefiles directly? It may be a bit trickier to integrate cleanly into our build system, but I think the result is much nicer.
-- Dimi.
__________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
On Wed, 24 Sep 2003, Steven Edwards wrote:
Most of it should already build under Cygwin as cygwin1b apps. just $ ./configure && make tools && cd dlls && make
The difference is that I'm compiling Wine programs without Wine libraries, let alone DLLs. Only a very limited set of libraries is compiled in order to build wrc. Other programs are linked against MinGW libraries only.
I would recommend you get Mingw + MSYS from www.sourceforge.net/projects/mingw and follow my directions for doing a WINE build on Windows from here.
Your instructions mention building DLLs. I'm not using any Wine DLLs. It may be another interesting project to compile them for Windows, but I'm dealing with programs only at this point.
Hello Pavel, You can build the programs only also using the makefiles. You dont need to use WINEs dlls or import libs. You can just run make programs or cd to programs and type make.
Thanks Steven
--- Pavel Roskin proski@gnu.org wrote:
Your instructions mention building DLLs. I'm not using any Wine DLLs. It may be another interesting project to compile them for Windows, but I'm dealing with programs only at this point.
__________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
-
Alexandre Julliard -
Dimitrie O. Paun -
Dimitrie O. Paun -
Martin Fuchs -
Pavel Roskin -
Richard Cohen -
Steven Edwards