Yesterday I built gvim (7.4.552, 32-bit) on Windows XP with +tcl +lua +python, MinGW make gave a few error messages about tcl lib (I'm using ActiveTcl8.6.3), but still gvim.exe was created.
I tried lua and tcl and everything worked as expected. But today gvim said it could not load library tcl86.dll. I had not changed anything to the system, and tcl86.dll is on search path. This is so confusing I don't even know where to look at.
This is my build command:
mingw32-make.exe -f Make_ming.mak LUA="d:/Lua/5.1" LUA_VER=52 TCL="D:/Tcl" TCL_VER=86 PYTHON="D:/Python27" PYTHON_VER=27 DYNAMIC_PYTHON=yes PYTHON3="D:/Python33" PYTHON3_VER=33 DYNAMIC_PYTHON3=yes FEATURES=HUGE GUI=yes gvim.exe
From os_win32.c, I built a tiny exe to load tcl86.dll, the error message pointed to zlib1.dll. A search showed there was a copy in c:\windows\system32, it was of lower version and smaller size than the one in tcl/bin.
Copying tcl/bin/zlib1.dll to $VIMRUNTIME solved the problem. Or, even better I thought, just delete the one in windows/system32.
Related
I am attempting to set up GTK3 for development on Windows 10 following the instructions on tarnyko.net
using the 64bit 3.6.4 bundle from here. The test program currently builds without errors, using the generated options. When I run the program a dialog appears displaying the error message:
Procedure entry point deflateSetHeader could not be located in the
synamic link library C:\Gtk\bin\libgio-2.0.0.dll
From what I can tell so far, deflateSetHeader is a function in zlib that was not present in older versions - a possible cause for the error. Looking in the header file of zlib that came with Gtk, it lists the function.
I have copies of zlib1 in my Gtk bin dir and MinGW (GCC v7.2.0) bin dir.
I tried swapping the versions between directories, but no joy. Don't have much else in my environment path variable, except for a vanilla Python 3.6 install. Don't have zlib1 in SysWOW64. I tried adding -lzlib1 to my gcc compiler options, but that didn't seem to make a difference. I'm running out of ideas now.
Anyone know what might be causing this?
Found the cause by searching my C drive for zlib and found a copy in
C:\Program Files\Intel\WiFi\bin that was causing the problem.
I have been using MinGW and the GNU Fortran compiler for a while in order to compile Fortran programs on Windows, which has always been a successful method. However, I have been getting the following error for the past 4 days:
The application was unable to start correctly (0xc000007b). Click OK to close the application.
The error only happens when running applications that I wrote myself, and that I compiled using the MinGW/gfortran combo. When compiling using Visual Studio and iFort, I have no problem running the applications. The error seems retroactive: applications that were compiled using gfortran a long time ago and ran perfectly until now also break, even though I didn't recompile them. This leads me to think that it is a dynamic library problem. Online searches show that it probably is a compatibility problem between a 64-bit dll and a 32-bit application
I am using Windows 7. One of the latest things I remember doing before starting to get the problem was trying to update MinGW ; I used the mingw-get update and mingw-get upgrade command lines.
After looking around online, I have tried the following fixes:
- reinstalled the Visual C++ Runtime Environment
- reinstalled the .NET framework
- downloaded and replaced a bunch of .dlls like mscvr100.dll, mscvr100d.dll, etc...
- uninstalled and reinstalled MinGW in order to make sure I had the latest gcc version
- run Dependency Walker on a simple application ("Hello World!" type program)
Dependency Walker tells me that a number of .dlls cannot be found (full list: API-MS-WIN-APPMODEL-RUNTIME-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL, API-MS-WIN-SHCORE-SCALING-L1-1-1.DLL, DCOMP.DLL, GPSVC.DLL, IESHIMS.DLL).
It also highlights in red the libquadmath-0.dll (on which libgfortran-3.dll seems to depend). Indeed, it seems that libquadmath-0.dll is a 64-bit DLL in the middle of a 32-bit program. When opening said .dll with Dependency Walker, I can see that all the modules in this library are x86 except the library itself which is x64 (CPU column of DW). I am not exactly sure how this is possible / how to fix it. The library is found in the Python/Anaconda folder (I installed Python and Anaconda a few weeks ago, the problem did NOT appear at that time).
If anybody has an idea of how to get my environment to work again without reinstalling Windows, I would greatly appreciate it! Thanks!!
I had a similar problem. Looking at Dependency Walker I wasn't loading API-MS-WIN-CORE entries. However, when I went to edit my path it turned out that by bin folder wasn't on the path. Adding, in my case the mingw64 bin folder to the path fixed this issue for me. I only mention the API-MS-WIN-CORE entries since I thought it might be the problem, but in reality it wasn't causing my issue.
I was getting this same error code, and used Dependency Walker to discover that, in my case, the 64-bit version of libwinpthread-1.dll was not being found. This helped me resolve my issue.
So, the solution is to determine the missing dll, track it down on your system and reference its location in your path variable, or find out how to install it if you don't have it.
That said, I also came across the following caveat that's important to know about when using Dependency Walker. It's currently out of date and will actually show false results for WIN-CORE dlls: https://stackoverflow.com/a/36244483/4438237
To work around this, there's a newer program called Dependencies by lucasg, that properly interprets these and won't mistakenly tell you about these falsely missing dlls.
I was getting same Error, as mentioned in above answers the problem is "path not being set" aside from setting path you can alternatively Do this; if u don't want to set the path for some reason:
Open CMD
cd C:\MinGW\bin to navigate to the bin directory of mingw
now u can compile the code as following Gcc (dir of ur .c file) -o (ur output dir) for ex : gcc I:\dir\Hello.c -o I:\dir\output.exe
alternatively if u want to automate the process u can make a batch file to automatically do it for you.
here's the batch file if anyone needs it
#echo off
C:
cd \MinGW\bin\
gcc I:\dir\*.c -o "I:\dir\Output.exe" Rem Replace "dir" with your own directory and * with ur own FileName!
pause
I had a similar error but over came it by editing my environment variables.
I had g77 as part of my path variables and by removing it and leaving gfortran alone, the error disappeared
I was on Windows 10 using cmake-gui to generate a MinGW-w64 project and meet same problem.
My solution: go to start windows, search and open MinGW-w64 terminal, then in terminal call cmake with specifiying cmake options.
Yes the old posts got it right. It is the environmental parameters messed up. I got the same error. It is solved by putting the msys64 path to the first:
Path=c:\msys64\mingw64\bin;%PATH%
The msys64 path was the last, now it is the first. Type it once at the command line after Windows started, or edit the Path environmental parameter if you have the admin right.
I am trying to use chromedriver on a 64-bit mac, but haven't been successful yet. I keep getting error "Cannot execute binary file". The permissions are all correct and I don't see any other missing piece either. I am not sure if the available 32-bit version for mac would actually work on 64-bit mac.
Any help on this would be appreciable.
I had the same problem on my 64 bit MacOS. Turns out when I downloaded the zip file (mac_32.zip) from download page, and extracted the file from it, and then moved to the the directory where I wanted it to be... MacOS had created shortcut for me. Once I killed shortcut and made sure the target directory contains the real file, the problem went away.
I've successfully built a demo app using opencv on windows with the MSYS shell environment.
I did NOT use the prebuilt opencv installer, I downloaded and compiled the source locally (this is the recommended method).
After building opencv and running make install, all the files are happily in:
/e/deps/libopencv/build/install/
I can successfully build a sample application against this using cmake directives along the lines of:
find_package(OPENCV REQUIRED)
link_directory(${OpenCV_LIB_DIR})
include_directories(${OpenCV_INCLUDE_DIRS})
target_link_libraries(target ${OpenCV_LIBS})
To be completely clear here: building the binary is successful.
Now, when I run it from the shell I get the message:
The program can't start because libopencv_core231.dll is missing from your computer.
Try reinstalling the program to fix this problem.
So... I know where the libraries are:
$ ls /e/deps/libopencv/build/install/lib/
libopencv_calib3d231.dll.a libopencv_features2d231.dll.a libopencv_highgui231.dll.a libopencv_ml231.dll.a libopencv_video231.dll.a
libopencv_contrib231.dll.a libopencv_flann231.dll.a libopencv_imgproc231.dll.a libopencv_objdetect231.dll.a
libopencv_core231.dll.a libopencv_gpu231.dll.a libopencv_legacy231.dll.a libopencv_ts231.a
What now?
I guess I could try to make cmake build a static binary, but that seems pretty extreme.
How can I somehow make either 1) windows, or 2) the MSYS environment happy. Something like LD_LIBRARY_PATH on windows?
Or is this not the problem, and I've actually (despite appearances) somehow messed up the way the binary was compiled?
Edit:
NB. For whatever reason it seems that my libraries are .dll.a files, not .dlls (see the ls result) if that's remotely relevant.
windows searches the same directory as the exe, any directory in the %PATH% (Windows) or $PATH (msys) directories, as well as a few special ones in the windows folder
You could add /e/deps/libopencv/build/install/lib to your $PATH. I am not sure if this will work for msys, you may need to add E:\deps\libopencv\build\install\lib to %PATH% in windows instead.
The typical solution for this if you are giving the program to others is to include a copy of the DLL in the same directory as the EXE. you can get this same effect by making a symbolic link to it with the command
ln -s /e/deps/libopencv/build/install/lib/libopencv_core231.dll libopencv_core231.dll
while in the /e/deps/libopencv/build/install/ directory
I'm reinstalling everything on my machine, and amongst those is Cygwin. I'm trying to avoid reinstallation, partly because I don't even know what it is that I've installed. Can I just move the Cygwin directory from one machine to another and expect everything to work, or are there some other important settings that I need to move as well?
As far as I saw, it's pretty self-contained, but one never knows.
Yep! Go for it. You won't encounter any problems.
You can just copy the entire cygwin directory to your new machine, open up the cygwin shell and everything (as long as you are only calling cygwin-internal programs and stuff that's within the path) will just work as if you you are working on your old machine.
The only thing you'll loose is the directory where the "already downloaded and compressed" packages for a possible re-installation are stored. Fortunately this directory is optional, so no problem for migration to another platform. You could copy that directory as well, but most likely all the packages that you have are outdated anyways and a run of setup.exe would fetch the new versions anyway...
Btw - since someone said exactly the opposite some real-life experience: I use this feature quite often with success. I've copied my cygwin dir to USB-sticks and used it on friends computers. I also copied it to the laptop of my fiance when we go to holidays and take a laptop with us.
It always worked without any problems....
The short answer is: No, you can't copy the whole Cygwin folder. You just copy the configuration files(bash files, vim file, etc.) you need.
The long answer is: If you copy the whole Cygwin folder, it may work in some case, and may not in some other case.
The reason is: you will lose linux file mode when copying files on Windows. And that will cause a lot of troubles. However, you may not have the troubles when you use Cygwin just like a common Windows Program(which means you don't care file mode and anything related), and run it as Windows Administrator(which is not required when Cygwin is installed as usual).
BTW: you can export the packages you installed by cygcheck.exe -c and install them on the new Cygwin. You can also install/update Cygwin packages by Cygwin's setup-x86_64.exe in command line like:
setup-x86_64.exe -q -P package1,package2,package3
No, you have to reinstall it from the cygwin installer, sorry!
Most importantly you'll want to copy everything from your home directory (default is c:/cygwin/home/) especially anything w/ a "." in front of the filename.
As for individual application preferences, etc., you may lose those -- but if you do the reinstall while you still have access to your old machine -- you can probably get to 90% of your previous install without too much trouble.
My experience with copying from one cygwin64 (I don't think there is a difference) to another machine is that all of the symbolic links got crushed:
As an example:
What used to be /usr/bin/cc -> /usr/bin/gcc.exe (or something like that)
After the copy /usr/bin/cc became a text file containing the string:
!<symlink>/usr/bin/gcc.exe
My method of copy was merely cp -r /cygwin/c/cygwin64 <dest>
My dest was a FAT32 FS, but I don't think that had anything to do with it.
There were also characters 0x00 and 0xFF sprinkled among many of these 'text' files so that they appeared to be binary.