This has nothing to do with LIB. It's the DLL loader on Windows, not build
time stuff.

Use process hacker 2. Search for DLL handles straight after boot up. See
which processes loaded the zlib DLL. Find alternatives to that software,
maybe MSYS2 has some? Uninstall the offending software. Delete the DLL if
uninstalling didn't do that for you. Install the alternatives. Be happy.
This is entirely at your own risk. If it goes wrong, you won't be happy I'm
afraid.

On Tue, 22 Mar 2016 16:52 ralph engels, <[email protected]> wrote:

> Aye i also have been getting that problem, i got around it by hand
> setting paths in my build script so that the mingw32 directories came
> first before the windows system directories. In most cases this works
> but i have seen a few edge cases that prove that it is not allways
> enough. In those cases i had to manually point the LIB environment
> variable to the file i wanted to link to.
>
> Den 22-03-2016 kl. 16:20 skrev Matt Postiff:
> > 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
>
>
>
> ------------------------------------------------------------------------------
> 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

Reply via email to