Based on what you have said, is this right thinking: In other words, ldd in particular and run-time loading of libs in general inside mingw is not "hermetically sealed off" from any influence by Windows. Its behavior is affected not only by what the msys/mingw environment wants to do with DLLs, but also what Windows "underneath" decides to do with DLLs.
What I'm trying to get at is this: is there no way that I could have fixed my problem other than deleting the offending zlib1.dll file? Could I have changed a path or flipped a switch or changed any setting in msys that would have prevented this problem? On 3/22/2016 9:42 AM, Ray Donnelly wrote: > On Tue, Mar 22, 2016 at 11:58 AM, Alexpux <[email protected]> wrote: >> 22 марта 2016 г., в 13:45, Matthew A. Postiff <[email protected]> >> написал(а): >> >> Thanks all for the ideas. >> >> I was not as clear as I could be when I showed the very short PATH. Indeed >> that may be overdoing it, but zlib1.dll was loaded from the wrong place even >> though my path was that short. Apparently, something in Windows is choosing >> to find zlib1.dll in its own system directories instead of in /mingw32/… >> >> >> Well it can be only if you don’t have /mingw32/bin/zlib1.dll and/or windows >> folder in PATH is earlier then mingw32 >> > Also, Windows will use a DLL that's already loaded in memory in > preference to any other in your PATH. So some selfish programmer has > decided that their zlib dll was more important than anyone else's and > they took this extreme measure to make sure that they didn't get > usurped. This is the reason I never recommend people to put MSYS2 into > their Windows PATH. Anyway, you've installed some software written by > someone who doesn't care about any other software working right I'm > afraid. > >> Regards, >> Alexey. >> >> >> On 3/22/2016 12:11 AM, Greg Jung wrote: >> >> >> >> On Mon, Mar 21, 2016 at 6:41 PM, Matthew A. Postiff <[email protected]> >> wrote: >>> Do you mean more clean than >>> >>> $ printenv | grep PATH >>> PATH=/mingw32/bin:/usr/local/bin:/usr/bin:/bin >> That may be overdoing it, you might find yourself running some windows >> utilities >> that will need /c/windows. In /etc/profile I use the following >>> >>> >>> C=`/usr/bin/cygpath $SYSTEMDRIVE` >>> >>> wpath="$C/Windows:$C/Windows/system32:$C/Windows/system32/Wbem" >>> >>> MSYS2_PATH="/usr/local/bin:/usr/bin:/bin" >> >> and then have variations built with these, depending on MSYSTEM. Because of >> perl, >> more gets added at the end so for MINGW32 >> >>> PATH=/mingw32/bin:/opt32/bin:/usr/local/bin:/usr/bin:/bin:/c/Windows:/c/Windows/system32:/c/Windows/system32/Wbem:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl >>> >>> >>> For the record...I had a zlib1.dll in C:\Windows\SysWOW64\ on two >>> different >>> computers. On the one, it caused a libxml check in configure to fail. The >>> check returned 127--library missing--but it wasn't libxml2-2 that was >>> missing! On the other, it caused gcc to be unable to write output. It >>> returned 1 and did not give any output. When I deleted zlib1.dll, these >>> odd >>> problems disappeared. >>> >> I have 0 zlib* files anywhere beneath c:/windows, 67 of them beneath >> c:/msys64, >> including C:/msys64/mingw32/bin/zlib1.dll >> C:/msys64/mingw32/lib/pkgconfig/zlib.pc C:/msys64/mingw32/include/zlib.h >> C:/msys64/mingw64/bin/zlib1.dll C:/msys64/mingw64/include/zlib.h >> .. >> >>>>> Digging around I found another problem with conftest.exe: >>>>> >>>>> $ ldd conftest.exe | grep zlib >>>>> zlib1.dll => /c/Windows/system32/zlib1.dll (0x10000000) >>>>> >>>>> There are two problems with zlib1.dll: >>>>> >>>>> 1. /c/Windows/system32/zlib1.dll DOES NOT EXIST on my system. I found >>>>> the DLL instead at /c/Windows/SysWOW64/zlib1.dll >>>>> 2. That library shouldn't have been linked. It should have linked to >>>>> /mingw32/bin/zlib1.dll >>>>> >>>>> Any ideas on what is wrong, or what I'm doing wrong? >>>>> >> Somebody at sometime has decided that zlib1.dll needed to be linked via >> the WOW system. >> That seems really sick to me, maybe its a virus. If zlib1 is needed then it >> should be included in the >> directory containing the .exe; if you have installed a program that doesn't >> want its own directory (i.e. a virus) >> and yet remain as small and insignificant as possible (i.e. a virus) then >> it might install such support >> files in obscure locations such as that. >> >> You asked for ideas, that's all it is. >> >> >> ------------------------------------------------------------------------------ >> 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 >> ------------------------------------------------------------------------------ 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
