This is the mail archive of the
cygwin
mailing list for the Cygwin project.
cygexec mounted binaries don't inherit PATH during dynamic loading
- From: Brian Dessent <brian at dessent dot net>
- To: cygwin at cygwin dot com
- Date: Tue, 29 Mar 2005 21:33:49 -0800
- Subject: cygexec mounted binaries don't inherit PATH during dynamic loading
- Organization: My own little world...
- Reply-to: cygwin at cygwin dot com
The last month or so I've been fooling around with using the 'cygexec'
feature of the mount table to tell Cygwin that everything under /usr/bin
is a Cygwin executable (except for strace and cygcheck.)
However, a strange thing started happening recently. With the x11
server running I would try to launch an xterm, and I would get the
windows popup "DLL missing - Can't find cygX11-6.dll". Puzzled, I
check $PATH from the prompt and indeed /usr/X11R6/bin is in my path.
Let me be clear at this point that this particular example involves
xterm and X11 but as you'll see that's just a specific example of a more
general problem.
I figured out that removing the cygexec mounted /usr/bin solves the
problem - an xterm can launch normally.
So I used process explorer to look at the environment of the xterm.exe
process while the error popup was on the screen. The process had the
default, system-wide PATH (as defined in Windows system properties
page.) In my case, I have \cygwin\bin in that PATH but I rely on the
profile scripts to add /usr/X11R6/bin to the path, and thus the
cygX11-6.dll was indeed not in the path at that moment.
I poked around in the source code and sure enough, environ.cc, function
build_env() gets passed a true value for "no_envblock" if the thing
being spawned is mounted cygexec. It proceeds to set envblock to NULL
which I presume means take the default system environment.
Now, I realize that since Cygwin is spawning a Cygwin application it
will pass stuff like the environment and argv[] directly through the
shared memory region and bypass Windows' methods entirely. So I realize
that *eventually* the process will inherit the correct PATH. But my
question/problem is that during the dynamic loading phase, Windows needs
the inherited PATH too - otherwise you get these strange unexplainable
runtime link errors. (I was seeing this before in another way when a
dlopen() kept returning win32 errno 126 even though the damn DLL was
right where it was supposed to be and had the right permissions.)
So my question is simply this: in the case of spawning a cygexec-mounted
binary, shouldn't build_env at least fill in PATH from the calling
process' value, so that Windows can do its runtime DLL loading?
Brian
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/