Hello,
Just installed mingw make.exe and the two requisite DLLs such that I could compile a MS VC++ project using GNU make. Everything is fine until it tries to link, at which point, 'make -d' returns the following (relevant) information:
link /nologo /subsystem:console /incremental:no /nodefaultlib:libcd /out:gapexe.exe rdtsc_time.obj gapexe.obj libconf.lib
CreateProcess(C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\BIN\link.exe,link /nologo /subsystem:console /incremental:no /nodefaultlib:libcd /out:gapexe.exe rdtsc_time.obj gapexe.obj libconf.lib,...)
...
LINK : fatal error LNK1181: cannot open input file 'link.obj'
Close examination of the CreateProcess() debug line, it seems that the linker interprets the 'link' as 'link.obj' in the 2nd param and tries to find the file. When it cannot, it fails. This is with the latest version of MingW32 make, that is, ver 3.81-1.
My workaround hack includes adding a valid link.obj file in the directory where I link, at which point it works, but I thought someone should know about this.
Thanks,
Marek
Logged In: YES
user_id=15438
Originator: NO
Link is not a binutils binary.
Which version of make are you using; i.e. what is the output of ``make --version''?
This appears to be an environment issue.
Logged In: YES
user_id=1687182
Originator: YES
Hello,
Apologies for mis-categorizing the report. Version:
C:\> make --version
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
This program built for i686-pc-mingw32
Thanks again,
Marek
Logged In: YES
user_id=15438
Originator: NO
I suggest that you take your issue to make-w32@gnu.org. Perhaps someone with more knowledge of the inner workings of the windows port can help. It appears that perhaps the spaces in the path to link.exe is perhaps an issue based on your CreateProcess output.
Logged In: YES
user_id=1312539
Originator: NO
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 30 days (the time period specified by
the administrator of this Tracker).
Logged In: YES
user_id=1723996
Originator: NO
Hi,
Some additional information, as I have a related problem!
This is due to the fact that all expressions starting with a "/" are interpreted as path values by the shell. For windows compliance they are converted to absolute paths containing "\". A workaround for the above specified is to specify options using double slashes "//".
My problem is somehow more difficult, but also comes out of the "/" to "\" conversion.
Example Makefile:
test:
@echo building $@ ;\
echo 1. OTHER_OBJ="$(OTHER_OBJ)" ;\
$(MAKE) --no-print-directory test2
test2:
@echo building $@;\
echo 2. OTHER_OBJ="$(OTHER_OBJ)";\
$(MAKE) --no-print-directory test3
test3:
@echo building $@;\
echo 3. OTHER_OBJ="$(OTHER_OBJ)"
Output:
c:/tmp/mktest> make OTHER_OBJ="c:/tmp/z.z"
building test
1. OTHER_OBJ=c:/tmp/z.z
building test2
2. OTHER_OBJ=c:/tmp/z.z
building test3
3. OTHER_OBJ=c;c:tmpz.z
If you then create a rule using the macro OTHER_OBJ make will fail.