Re: putenv does not put env into win32?

[Mumit Khan <khan@xraylith.wisc.edu>]

On Tue, 27 Apr 1999, Eugene Kanter wrote:

> 
> I did not find where it says to use dlopen. I replaced LoadLibrary with
> dlopen and received the identical results. The advantage of using dlopen
> over LoadLibrary is that I did not have to convert Unix path to Windows
> path. I did not look at the actuall cygwin code (where?). I guess dlopen
> calls LoadLibrary eventually. However I must call CoFreeLibrary() at the
> end (OLE requires) so I guess I must use LoadLibrary.
> 
> Still in magic why mingw32 application allows me to change PATH so all
> DLLs could be loaded and cygwin does not. You mentinoed that putenv
> modifies only current process environment. Which process does the dll
> loader belongs to?
> 
> I solved the problem eventually by doing chdir(). However what if more
> then one directory is required to be added to the path??

Hi Eugene,

I haven't followed the thread, but adding to PATH using putenv() should
and does work with B20.1, at least on NT where I tested it. I'm attaching
a small testcase. Here's what it does when you run make:
  
  - create a subdirectory called "foo"
  - create a small DLL in "foo"
  - create a dll caller that uses dlopen after adding "foo" to PATH.

Please let me know if this helps (or if it doesn't work).

This is code from the time when I was testing dlopen implementation prior
to b20.1, so hopefully it's still working ... In theory, LoadLibrary
should work just as well.

There should be no issue for parent process and so on here, since PATH
belongs to the current, which is looking for the DLL.

Regards,
Mumit

dlopen test code

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com