True. This was something I ran into and couldn't account for myself and is probably not very frequently documented because most (proper) Windows applications install their libraries into their own directories rather than dirtying up the system directories.
Alan, The msys2 runtime, like cygwin is what provides the implementation for the dlopen call (Windows native applications use LoadLibrary) so the implementation is different. Here's a reference discussing the problem: http://comments.gmane.org/gmane.comp.gnu.libtool.general/7379 Most likely, the only way to ensure you won't pick up extraneous dlls from other paths is with version suffixes when the import libraries are build to prevent any naming collisions. Most shared libraries built within the msys2 environment, however, already do this which can be seen if you browse to the /mingw64/bin directory and look at the dll names. The name collision situation doesn't come up terribly often and keep in mind, this is only an issue when the executable is run from a directory that doesn't contain the dll that it is supposed to rely and a conflicting version exists in the system directory which typically only happens when the build configuration is taking place to check for dependencies. Most windows programs install their own dlls within their own program directory as its bad form to install them into the system directories when unnecessary (the case I ran into was for openssl for a driver and even that was unnecessary). This is just one of the Windows gotcha's that seems to occur too infrequently to be widely known. On Fri, Mar 25, 2016 at 7:34 PM, Óscar Fuentes <[email protected]> wrote: > Matt Breedlove <[email protected]> > writes: > >> DLLs load from the system32/wow64 directory first *regardless* of any >> PATH variables. This was a prior problem I experienced with python >> being built and there having been openssl dlls within my system >> directories. It has nothing to do with the path variable. This is >> documented behavior on MSDN and requires a system call to change the >> search paths. Ray is correct, although I typically use procmon from >> the SysInternals Microsoft suite and just filter for dll paths. If >> you have a dll with the same name as the one a process is trying to >> load within system32/SysWOW64, it will override any dlls that might be >> present within PATH. >> >> Here's the URL that describes the behavior: >> >> https://msdn.microsoft.com/en-us/library/7d83bc18.aspx >> >> Because his zlib.dll file for msys2 doesn't reside in the same >> directory that conftest.exe is being compiled in, Windows will search >> the system directories first and then progress along the PATH >> directories. This is unless a specific call is made to change that >> behavior (which it is not). > > My point was that Ray's comment could be interpreted as saying that > having *any* foo.dll on your system and a process that uses it implies > that you will have problems if your application comes with its own > foo.dll. > > If you place your foo.dll along the rest of the binaries of your > application, you are safe, no matter how many other foo.dlls you have > around on your system. > > I'm sure that Ray knows this, but as the discussion progressed some > context was lost and on the final messages it is not obvious that the > problem is related to relying on PATH for locating zlib.dll and having > other zlib.dll on the Windows system directory. > > There is much confussion with dlls on Windows and I've met many > programmers who hold the weirdest ideas about it (as demonstrated by the > other response to your message.) > > > ------------------------------------------------------------------------------ > Transform Data into Opportunity. > Accelerate data analysis in your applications with > Intel Data Analytics Acceleration Library. > Click to learn more. > http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140 > _______________________________________________ > Msys2-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/msys2-users ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140 _______________________________________________ Msys2-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/msys2-users
