[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: wrong link command called

From: Jonathan Baccash
Subject: RE: wrong link command called
Date: Tue, 29 Mar 2005 17:08:07 -0800

> -----Original Message-----
> From: Earnie Boyd [mailto:address@hidden
> Sent: Tuesday, March 29, 2005 3:46 PM
> To: Jonathan Baccash
> Cc: address@hidden
> Subject: RE: wrong link command called
> You're posting to the make_w32 list which doesn't support Cygwin make.
> You stated that you have built the beta version of make.  Is that
> dependent on Cygwin or is it native?
> The PATH variable of the parent make will not propagate to the child
> unless you explicitly export it.  This is a new feature of the beta.
> you have a native make and if the PATH of the Cygwin shell is
> that the PATH of the Win32 system, it is possible that your child
> processes do not have the same PATH as the parent.  If you have a
> make, then please post to the address@hidden list for support.

I am using GNU make 3.81 beta 2, and I built it myself.  I used the
version produced in the WinDebug directory to track down what was going
on within the GNU make source code.  I am not modifying any variable
during the make session at all, not even Path or PATH or path or
anything like that.  I carefully constructed a simple test case to
reproduce the problem, and I included it in my original posting
(although it was all mangled and garbled, sorry!).

My PATH was exported from the shell from which I invoked make, and the
PATH is as I expect for all of the following command lines:

        @echo "\$$(PATH)=$(PATH)"
        @echo "\$$(Path)=$(Path)"
        @echo "\$$PATH=$$PATH"
        @echo "\$$Path=$$Path"

When I run the command "link" from my shell, it runs
c:/PF/MSVS2003/VC7/BIN/link.exe, because that appears first in the PATH.
When I run the command "link" from GNU make, it runs
c:/cygwin/bin/link.exe because that is the directory where make.exe
exists.  The problem is that GNU make for Win32 does some sort of
trickery in certain situations, and decides to not spawn a shell and
instead create the process to run the program directly.  And I searched
through the code and found out why this codepath is behaving weirdly.
If you would please open up your editor in the GNU make source code to
line 330 of w32/subproc/sub_proc.c (in the function find_file, it calls
the Win32 API function OpenFile) -- this is where make discovers where
in my PATH my program is located.  According to the MSDN Library (you
can google it and access it online), this function will search in the
directory from which the application loaded (and a succession of other
directories) before even caring about or looking at the PATH.  Please,
THIS is the problem, it has nothing to do with my PATH.

Now, if my shell would have done the same thing to lookup the program,
this would be fine.  But apparently, the Cygwin bash shell does not.  It
works like I want and does the lookup based on my PATH.  I think it's
trickery that GNU make doesn't spawn a shell to run my command--isn't it
supposed to delegate this operation to the shell of my choice?



If you have received this e-mail in error, please delete it and notify the 
sender as soon as possible. The contents of this e-mail may be confidential and 
the unauthorized use, copying, or dissemination of it and any attachments to 
it, is prohibited. 

Internet communications are not secure and Hyperion does not, therefore, accept 
legal responsibility for the contents of this message nor for any damage caused 
by viruses.  The views expressed here do not necessarily represent those of 

For more information about Hyperion, please visit our Web site at

reply via email to

[Prev in Thread] Current Thread [Next in Thread]