Hi Manu,
I got around getting Visual-MinGW to compile under Winelib. This patch touches only your makefile, and I hope the changes are not controversial: -- Use forward slash instead of backslash -- Explicitly list the DLLs you link against (shell32, comdlg32, advapi32) -- It make sense to specify -mno-cygwin For some reason, the code seems to require it. Please check that it works under Windows as well. If it does, if makes sense to have it as Visual-MinGW should not have a dependency on Cygwin, as far as I can tell. -- Do not use -pedantic, the code does not compile with gcc 3.2 on Linux with that flag. -- Do not use -fvtable-thunks, it is deprecated in gcc 3.2
Please apply this patch with 'patch -p1 < winelib.diff'.
Note that I still need to get some changes integrated into the official Wine tree before you can actually compile Visual-MinGW under Winelib. The changes are not controversial, and I hope to get them in real soon. I will let you know when that happens.
Regardless, I think the changes I'm proposing are logical in and of themselves, so I figured they can be integrated regardless.
Enjoy!
--- Visual-MinGW.orig/Projects/vmingw/src/makefile 2002-06-08 06:07:10.000000000 -0400 +++ Visual-MinGW/Projects/vmingw/src/makefile 2002-12-31 01:43:29.000000000 -0500 @@ -1,25 +1,25 @@ # Generated automatically by Visual-MinGW. # http://visual-mingw.sourceforge.net/
-CC = g++ +CXX = g++ WRES = windres DLLWRAP = dllwrap CPPFLAGS = -D_WIN32_IE=0x0400 -LDBASEFLAGS = -mwindows -lcomctl32 -lole32 +LDBASEFLAGS = -mwindows -mno-cygwin -lcomctl32 -lole32 -lshell32 -lcomdlg32 -ladvapi32 INCDIRS = -I ../include OPTIMIZ = -O2 STRIP = -s
ifeq ($(MAKECMDGOALS),debug) -CXXFLAGS = -W -Wall -pedantic $(INCDIRS) -g -fvtable-thunks -fno-rtti +CXXFLAGS = -W -Wall $(INCDIRS) -g -mno-cygwin -fno-rtti LDFLAGS = $(LDBASEFLAGS) else -CXXFLAGS = -W -Wall -pedantic $(INCDIRS) $(OPTIMIZ) -fvtable-thunks -fno-rtti +CXXFLAGS = -W -Wall $(INCDIRS) $(OPTIMIZ) -mno-cygwin -fno-rtti LDFLAGS = $(STRIP) $(LDBASEFLAGS) endif
-SRCDIR = .\src -BINDIR = ..\bin +SRCDIR = ./src +BINDIR = ../bin LIBDIRS =
%.o : %.rc @@ -51,7 +51,7 @@
# Dependency rules $(TARGET): $(OBJS) - $(CXX) -o $(BINDIR)\visual-mingw.exe $(OBJS) $(INCDIRS) $(LIBDIRS) $(LDFLAGS) + $(CXX) -o $(BINDIR)/visual-mingw.exe $(OBJS) $(INCDIRS) $(LIBDIRS) $(LDFLAGS)
rsrc.o: rsrc.rc
Dimitrie O. Paun:
Hi Manu,
I got around getting Visual-MinGW to compile under Winelib. This patch touches only your makefile, and I hope the changes are not controversial: -- Use forward slash instead of backslash
Yes, logical.
-- Explicitly list the DLLs you link against (shell32, comdlg32, advapi32) -- It make sense to specify -mno-cygwin For some reason, the code seems to require it. Please check that it works under Windows as well. If it does, if makes sense to have it as Visual-MinGW should not have a dependency on Cygwin, as far as I can tell.
-mno-cygwin don't have much sense, since Visual-MinGW is built with MinGW, under Windows, not Cygwin.
-- Do not use -pedantic, the code does not compile with gcc 3.2 on Linux with that flag. -- Do not use -fvtable-thunks, it is deprecated in gcc 3.2
Please apply this patch with 'patch -p1 < winelib.diff'.
Apparently, the patch refuses to be applied, probably due to the fact that I changed a few things in makefiles formating. BTW, makefiles are generated by Visual-MinGW, so I suggest to add dedicated makefiles for Winelib. eg: "makefile.wine". That way, makefiles for Winelib won't be overwritten by Visual-MinGW, and it will be more convenient to do some changes in these.
Indeed, the best way would be to use a configure script. Anyway, send me your makefiles, I'll commit these to cvs. Then, you'll have full control on these.
Note that I still need to get some changes integrated into the official Wine tree before you can actually compile Visual-MinGW under Winelib. The changes are not controversial, and I hope to get them in real soon. I will let you know when that happens.
Ok, thanks.
Regardless, I think the changes I'm proposing are logical in and of themselves, so I figured they can be integrated regardless.
I applied your patch against src/rsrc.rc.
Manu.
On December 31, 2002 01:52 pm, Manu wrote:
-mno-cygwin don't have much sense, since Visual-MinGW is built with MinGW, under Windows, not Cygwin.
Yes, I know, but -mno-cygwin should be a noop in that case. And if someone has cygwin installed, it will ensure that Visual-MinGW is not linked against the cygwin libs. I think we are in agreement here that Visual-MinGW should not depend on cygwin, no? If so, it makes sense to make this explicit with -mno-cygwin.
-- Do not use -pedantic, the code does not compile with gcc 3.2 on Linux with that flag. -- Do not use -fvtable-thunks, it is deprecated in gcc 3.2
Please apply this patch with 'patch -p1 < winelib.diff'.
Apparently, the patch refuses to be applied, probably due to the fact that I changed a few things in makefiles formating.
OK, I can create a new patch for you.
BTW, makefiles are generated by Visual-MinGW, so I suggest to add dedicated makefiles for Winelib. eg: "makefile.wine".
I can certainly do that, but then they will drift appart. The ideal situation is to support both mingw and wine out of the same makefile, so that everything "just works". If makefile is generated by Visual-MinGW, I think it's worth modifying Visual-MinGW so that it generates the right makefile for both mingw and wine, don't you think so? This way, all programs that use Visual-MinGW can benefit from this support.
Dimitrie O. Paun wrote:
On December 31, 2002 01:52 pm, Manu wrote:
-mno-cygwin don't have much sense, since Visual-MinGW is built with MinGW, under Windows, not Cygwin.
Yes, I know, but -mno-cygwin should be a noop in that case. And if someone has cygwin installed, it will ensure that Visual-MinGW is not linked against the cygwin libs. I think we are in agreement here that Visual-MinGW should not depend on cygwin, no? If so, it makes sense to make this explicit with -mno-cygwin.
If MinGW doesn't complain, I agree.
-- Do not use -pedantic, the code does not compile with gcc 3.2 on Linux with that flag. -- Do not use -fvtable-thunks, it is deprecated in gcc 3.2
-fvtable-thunks is problematic. I use gcc version 2.95.3-6 (mingw special), (faster, smaller binaries) -fvtable-thunks is required with gcc 2, but gcc 3 outputs a warning. Any workaround?
Please apply this patch with 'patch -p1 < winelib.diff'.
Apparently, the patch refuses to be applied, probably due to the fact that I changed a few things in makefiles formating.
OK, I can create a new patch for you.
BTW, makefiles are generated by Visual-MinGW, so I suggest to add dedicated makefiles for Winelib. eg: "makefile.wine".
I can certainly do that, but then they will drift appart. The ideal situation is to support both mingw and wine out of the same makefile, so that everything "just works". If makefile is generated by Visual-MinGW, I think it's worth modifying Visual-MinGW so that it generates the right makefile for both mingw and wine, don't you think so?
Visual-MinGW generates the right makefile indeed, from user parameters in the ".prj" file. There is three possibilities:
- makefile.wine - configure.in/Makefile.am > configure script. - modifying params in ".prj" files.
I will change the parameters in ".prj" files, then generated makefiles should work for both MinGW and Wine. Though, I don't have a solution for -fvtable-thunks.
About configuration files, I started a new project called MSYS Here, which is a MSYS loader. With it, MSYS can be launched from Windows Explorer, the same way than the "DOS Prompt Here" power toy. The sources are in the MinGW CVS: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mingw/utils/msys-here/ I'll have to write configuration files for it, as well as for WinUI, which both Visual-MinGW and MSYS Here use. I'm not an Autotools guru, but if it works, I'll also commit configuration files to visual-mingw/winui. Then, I'll maybe write configuration files for Visual-MinGW as well.
Currently, I'm not very good with Auto-stuff :(
Manu.
On December 31, 2002 03:43 pm, Manu wrote:
that Visual-MinGW should not depend on cygwin, no? If so, it makes sense to make this explicit with -mno-cygwin.
If MinGW doesn't complain, I agree.
It shouldn't, it's documented to do so, try it out.
-fvtable-thunks is problematic. I use gcc version 2.95.3-6 (mingw special), (faster, smaller binaries) -fvtable-thunks is required with gcc 2, but gcc 3 outputs a warning. Any workaround?
The best thing would be to determine the version of gcc dynamically in the makefile, like so:
GCC_VER_2 := 'gcc version 2.' CFLAGS = -mno-cygwin -W -Wall -fno-exceptions -fno-rtti ifeq ($(findstring $(GCC_VER_2), $(shell gcc -v)),$(GCC_VER_2)) CFLAGS += -fvtable-thunks endif ifeq ($(MAKECMDGOALS),debug) CFLAGS += -g else CFLAGS += $(OPTIMIZ) else
This would require GNU make, but your current makefile requires GNU make anyway, so... In this case, it would be better to rename makefile -> Makefile, it's more standard for GNU make files.
Visual-MinGW generates the right makefile indeed, from user parameters in the ".prj" file. There is three possibilities:
- makefile.wine
- configure.in/Makefile.am > configure script.
- modifying params in ".prj" files.
I will change the parameters in ".prj" files, then generated makefiles should work for both MinGW and Wine. Though, I don't have a solution for -fvtable-thunks.
There shouldn't be a any need for modifying parameters in .prj files. Look, what we can do is this:
ifdef WINE CC = winegcc CXX = winegcc -xc++ WRES = wrc else CC = g++ WRES = windres endif
And then, to compile on Wine you just make sure you define WINE before invoking make, like so: WINE=1 make or make WINE=1
About configuration files, I started a new project called MSYS Here, which is a MSYS loader. With it, MSYS can be launched from Windows Explorer, the same way than the "DOS Prompt Here" power toy.
Having a configure script can help, but let's get this one fixed first. Once this works, we can look at the configuration stuff.
Dimitrie O. Paun wrote:
On December 31, 2002 03:43 pm, Manu wrote:
that Visual-MinGW should not depend on cygwin, no? If so, it makes sense to make this explicit with -mno-cygwin.
If MinGW doesn't complain, I agree.
It shouldn't, it's documented to do so, try it out.
It works.
-fvtable-thunks is problematic. I use gcc version 2.95.3-6 (mingw special), (faster, smaller binaries) -fvtable-thunks is required with gcc 2, but gcc 3 outputs a warning. Any workaround?
The best thing would be to determine the version of gcc dynamically in the makefile, like so:
GCC_VER_2 := 'gcc version 2.' CFLAGS = -mno-cygwin -W -Wall -fno-exceptions -fno-rtti ifeq ($(findstring $(GCC_VER_2), $(shell gcc -v)),$(GCC_VER_2)) CFLAGS += -fvtable-thunks endif ifeq ($(MAKECMDGOALS),debug) CFLAGS += -g else CFLAGS += $(OPTIMIZ) else
This would require GNU make, but your current makefile requires GNU make anyway, so...
I tried -Wno-deprecated, but it doesn't suppress warnings. Annoying :(
In this case, it would be better to rename makefile -> Makefile, it's more standard for GNU make files.
Ok, added to /Todo.
Visual-MinGW generates the right makefile indeed, from user parameters in the ".prj" file. There is three possibilities:
- makefile.wine
- configure.in/Makefile.am > configure script.
- modifying params in ".prj" files.
I will change the parameters in ".prj" files, then generated makefiles should work for both MinGW and Wine. Though, I don't have a solution for -fvtable-thunks.
There shouldn't be a any need for modifying parameters in .prj files. Look, what we can do is this:
ifdef WINE CC = winegcc CXX = winegcc -xc++ WRES = wrc else CC = g++ WRES = windres endif
And then, to compile on Wine you just make sure you define WINE before invoking make, like so: WINE=1 make or make WINE=1
Makefiles are standard Visual-MinGW generated makefiles, meanwhile configure.in, Makefile.am are available, I suggest "cvs add Makefile.wine".
About configuration files, I started a new project called MSYS Here, which is a MSYS loader. With it, MSYS can be launched from Windows Explorer, the same way than the "DOS Prompt Here" power toy.
Having a configure script can help, but let's get this one fixed first. Once this works, we can look at the configuration stuff.
Manu.
On January 2, 2003 09:33 am, Manu wrote:
Makefiles are standard Visual-MinGW generated makefiles, meanwhile configure.in, Makefile.am are available, I suggest "cvs add Makefile.wine".
I don't understand what you mean. I wasn't suggesting anything non-standard. As for "cvs add Makefile.wine", it's clearly not the way to go. Since the makefiles are generated, we need to support things in the code that generates them, so that _all_ projects benefit from it. I will not track all the rapid changes manually to a Makefile.wine file, that's for sure.
-
Dimitrie O. Paun -
Manu