On Wed, Aug 26, 2009 at 2:21 PM, Dylan Smithdylan.ah.smith@gmail.com wrote:
When compiling Wine on windows, the non-script tools will have an .exe extension, but the makefiles assumed that the tools never have an extention. Naturally this caused problems with the build, causing it to fail on Windows.
Please re-run autoconf to update the configure script.
Make.rules.in | 21 +++++++++++---------- configure.ac | 9 +++++++++ 2 files changed, 20 insertions(+), 10 deletions(-)
I've never had a problem building most of Wine with cygwin or msys+mingw before. Is this new behaviour?
On Wed, Aug 26, 2009 at 5:26 PM, Steven Edwards winehacker@gmail.com wrote:
I've never had a problem building most of Wine with cygwin or msys+mingw before. Is this new behaviour?
What do you mean by most of Wine? I am trying to easily build all of Wine from Windows.
I was able to build the whole wine tree on windows by running $ ./configure --without-x --without-freetype && make depend && make once I applied this patch and a previous one I sent: winegcc: Find winebuild.exe instead of winebuild on windows. http://www.winehq.org/pipermail/wine-patches/2009-August/077487.html
I don't know if this is new behaviour. I do remember having trouble building on windows before, so I gave up and tried cross compiling, which now works without errors (no -k option needed for make).
I am using mingw, msysgit, msys, and some GnuWin32 packages, so it is possible that it is a configuration issue. I'll retry with only mingw and msys. I don't think they provide Flex and Bison though.
On Wed, Aug 26, 2009 at 10:52 PM, Dylan Smithdylan.ah.smith@gmail.com wrote:
I don't know if this is new behaviour. I do remember having trouble building on windows before, so I gave up and tried cross compiling, which now works without errors (no -k option needed for make).
I am using mingw, msysgit, msys, and some GnuWin32 packages, so it is possible that it is a configuration issue. I'll retry with only mingw and msys. I don't think they provide Flex and Bison though.
No they don't, I've always had to search for the msys/mingw developer/dtk packages or use the GnuWin32 ports. I'll see if I still have a windows box with a mingw runtime installed to look myself.
Thanks
On Thu, Aug 27, 2009 at 9:01 AM, Steven Edwardswinehacker@gmail.com wrote:
I am using mingw, msysgit, msys, and some GnuWin32 packages, so it is possible that it is a configuration issue. I'll retry with only mingw and msys. I don't think they provide Flex and Bison though.
No they don't, I've always had to search for the msys/mingw developer/dtk packages or use the GnuWin32 ports. I'll see if I still have a windows box with a mingw runtime installed to look myself.
I just checked and can confirm it does seem to require the exe suffix now. I am not sure when that changed. I've not had time to test your patch but it looked good, I'll try to make more time to recheck if Alexandre commits it.
Thanks
Steven Edwards winehacker@gmail.com writes:
On Thu, Aug 27, 2009 at 9:01 AM, Steven Edwardswinehacker@gmail.com wrote:
I am using mingw, msysgit, msys, and some GnuWin32 packages, so it is possible that it is a configuration issue. I'll retry with only mingw and msys. I don't think they provide Flex and Bison though.
No they don't, I've always had to search for the msys/mingw developer/dtk packages or use the GnuWin32 ports. I'll see if I still have a windows box with a mingw runtime installed to look myself.
I just checked and can confirm it does seem to require the exe suffix now. I am not sure when that changed. I've not had time to test your patch but it looked good, I'll try to make more time to recheck if Alexandre commits it.
Any decent shell should be able to run apps without .exe suffix on Windows.
On Thu, Aug 27, 2009 at 10:02 AM, Alexandre Julliardjulliard@winehq.org wrote:
Any decent shell should be able to run apps without .exe suffix on Windows.
There is no problem with running something with an exe suffix, it is the Makefile rules that are causing the trouble.
For instance, when building a program, this seems to be invoked: $ gcc ../../tools/wrc/wrc.o -o ../../tools/wrc/wrc which naturally leads to undefined functions from this type of linking.
This seems to be caused by the rules: $(RC_SRCS:.rc=.res) $(MC_SRCS:.mc=.mc.res) $(RC_SRCS16:.rc=.res): $(WRC) that originates from Make.rules.in.
If this is a regression, then maybe this should be approached differently to return the old behaviour.
Similarly my other patch wasn't created because of a problem with running an .exe, it was the problems with explicit checks for executable file: winegcc: Find winebuild.exe instead of winebuild on windows. http://www.winehq.org/pipermail/wine-patches/2009-August/077487.html
Perhaps the checks in the winegcc's spawn function are the problem in this case, and should be removed or enhanced to deal with this case.
I can do some regression testing to find the commits at fault, which I may be able to identify with git-blame, but will take some testing to be sure.
Dylan Smith dylan.ah.smith@gmail.com writes:
There is no problem with running something with an exe suffix, it is the Makefile rules that are causing the trouble.
For instance, when building a program, this seems to be invoked: $ gcc ../../tools/wrc/wrc.o -o ../../tools/wrc/wrc which naturally leads to undefined functions from this type of linking.
This seems to be caused by the rules: $(RC_SRCS:.rc=.res) $(MC_SRCS:.mc=.mc.res) $(RC_SRCS16:.rc=.res): $(WRC) that originates from Make.rules.in.
If this is a regression, then maybe this should be approached differently to return the old behaviour.
I see. I don't think it's a regression. Your approach should work, except the bit about guessing the extension depending on the existence of the files should be improved.
Similarly my other patch wasn't created because of a problem with running an .exe, it was the problems with explicit checks for executable file: winegcc: Find winebuild.exe instead of winebuild on windows. http://www.winehq.org/pipermail/wine-patches/2009-August/077487.html
Perhaps the checks in the winegcc's spawn function are the problem in this case, and should be removed or enhanced to deal with this case.
Yes, I have some fixes for that.
-
Alexandre Julliard -
Dylan Smith -
Steven Edwards