Error on libcurl.dll when using GDAL of OSGeo4W in Django - django

I'm trying to install GeoDjango in my Django project and got weird errors with GDAL.
Following Django documentation, I installed GDAL, GEOS, PROJ using OSGeo4W64, for specific, these are packages I selected to install on OSGeo4W64 setup:
gdal v2.3.2-2
geos v3.7.0-1
proj v5.2.0-1
I also set my environment variables as documented.
What error I got
At first when I started my Django project (using runserver), python tried to look for gdal202.dll and raised error Entry Point Not Found:
The procedure entry point sqlite3_column_origin_name could not be
located in the dynamic link library ...\osgeo4w64\bin\gdal202.dll
And one more error Ordinal Not Found with libcurl.dll (installed by OSGeo4W as dependencies):
The ordinal 361 could not be located in the dynamic link library
..\osgeo4w64\bin\libcurl.dll
and python raised error:
[WinError 182] The operating system cannot run %1
What I did
I fixed the first error by downgrade gdal version to gdal201.dll but still can not figure out how to solve the second error.
I tried download the latest Windows binary version of libcurl and replaced with but then I got another error raised by python:
[WinError 126] The specified module could not be found
I also checked for arch of my curl binary is x64 (the same as my python and OSGeo4W).
Hope someone one can help, thanks so much.

On Windows w/ Django and PyCharm, I began to receive the same error as one of your earlier ones, as described below:
The procedure entry point sqlite3_column_origin_name could not be located in the dynamic link library C:\Program Files\GDAL\gdal203.dll
Short-story solution that worked for me
Renamed: "C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python37_64\DLLs\sqlite3.dll" to sqlite3.dll.bak
I used two tools to help me resolve this
Dependencies
Process Explorer 64
Steps used to correct
Use Dependencies to load up gdal203.dll and look for which DLL is used for sqlite3_column_origin_name
Used Process Explorer to determine which sqlite3.dll was being loaded into memory (welcome to DLL-hell). In my case it was in "C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python37_64\DLLs"
Used Dependencies to examine the sqlite3.dll from Visual Studio
Exited PyCharm and renamed the Visual Studio DLL sqlite3.dll.bak to force it to load up the one according to my PATH order. Who knows what else I may have unintentionally broke by doing this. Future-me might hate me for this.
Starting with a new install of Windows 10, followed by installing PyCharm, Django, GeoDjango... it won't work without substantial troubleshooting in my experience. I think partly from DLL-hell and partly due to PyCharm's runnerw64.exe used to hook in the debugger.

Related

VisualStudio: remote lib headers are not downloaded when working with Suse Enterprise Server 12 SP5

Problem
I've got an issue when developing c++ application in Visual Studio using Suse Enterprise Server 12 SP5 distribution as remote build machine. The main problem is caused by libxml2.
Error logs: Errors.img
In the beginning, Visual Studio notified me that it cannot find libxml. I checked directory containing those headers and found out that libxml wasn't downloaded when I tried to load remote headers.
Research
Before SLES, I was working with CentOS without problems. As I understand, Visual Studio loads headers from /usr/lib/, so I compared how those distributions store installed libs. I found out that in CentOS lib files are stored in "/usr/lib" directory, but SLES keep them mostly stored in "/lib or /lib64" directories. So, I downloaded libxml sources from https://gitlab.gnome.org/GNOME/libxml2/ .
NOTE: VS failed when tried to execute "make" command, so I tried just coping “include/libxml” folder from sources to “/usr/lib/ directory”.
After it, Visual Studio downloaded that lib and intellisence has stopped showing error: "Cannot find libxml". But I still get errors of libxml absence: Other errors.img
My question is what are ways to solve this problem? Maybe there exists any way to download /lib/ directory, or install this libxml to /usr/lib at start? Do libxml from CentOS will correctly work in SLES?
Thank you in advance!
After some tries, solution founded.
I installed openSuse instead of SLES, download all necessary libs and successfully get headers. By the way, c++ application which built on openSuse, could launch on SLES without any problem.

Build OpenCV for UWP

I'm currently struggling to build OpenCV for the UWP.
I already googled quite a lot and found Microsoft's OpenCV Github Repo which tecnically should do the magic. However, this repo and pretty much everything else I found in this regard are outdated (Visual Studio 2015, old OpenCV versions etc.). I need to use OpenCV 3.3 because it's a cross platform project and I don't want to recompile everything else solely because of an outdated git repo.
Can anyone explain the process of building OpenCV using CMake from the official repo for the UWP?
My first attempt was to simply use the Windows Dlls, however my application than shouts "Failed to load module" at me. Then, I tried to build OpenCV the Visual Studio Project files as stated here and here. However, this doesn't do it for me as it throws the following error:
CMake Error at cmake/OpenCVUtils.cmake:440 (if):
if given arguments:
"(" "OR" "OFF" ")"
Unknown arguments specified
Call Stack (most recent call first):
CMakeLists.txt:317 (OCV_OPTION)
It also tells me to check the CMakeOutput.log but there it's 0 errors everywhere.
If someone could tell me either how to get rid of this error or what to change in the CMake GUI to build OpenCV for UWP, that'd be great!
Edit:
I also tried to compile OpenCV with a platform specific toolchain for WinRT as found in platforms/winrt. It doesn't really change anything though (I'm not even sure if it should), I still get "Unable to load Dll: The specified module could not be found". Maybe GPPK is right in his assumption that it's more an UWP problem than an OpenCV one. Anyways, if anyone knows anything about this, I'd really love to get some help!
Ok, I didn't get an answer yet, so I managed to do it myself (more or less).
Here's how I did it:
Prerequisites
Visual Studio (2017)
UWP SDK
CMake
OpenCV from official repo
Steps
Create a build folder which you want the UWP libraries to built in.
Start PowerShell in this folder and execute the following command (exchange C:\OpenCV with your local OpenCV path): cmake -G "Visual Studio 15 2017" -DCMAKE_SYSTEM_NAME=WindowsStore -DCMAKE_SYSTEM_VERS
ION="10.0" -DCMAKE_VS_EFFECTIVE_PLATFORMS=x86 -DBUILD_TESTS=OFF -DBUILD_PERF_TESTS=OFF C:\OpenCV
If you get the same error message as I did (see question for more details), go to the root CMakeLists.txt in the OpenCV folder and add a # in front of line 317 (OCV_OPTION(ENABLE_PYLINT)). This should fix it, to check, execute the command from above once more.
Ensure that the output claims "Windows RT support YES" and "Building for Microsoft platform: Windows".
Open OpenCV.sln in the build folder. Ensure that all projects are either of type "Windows Store" or "Universal Windows" and build the ALL_BUILD Project twice: Once in Release configuration, and once in Debug. Then build the INSTALL Project.
That's it, you should find the built Dlls in the install folder. Step 3 is probably a bug in OpenCV and will hopefully be fixed in upcoming versions.

Having trouble getting Python to recognize location of vcvarsall.bat

I was trying to install RandomWords which requires ujson, at some point in the installation I received the following notification: "error: Unable to find vcvarsall.bat" I searched here, on stackoverflow, and came across some answers as the to root of this problem. In this answer https://stackoverflow.com/a/8705722, near the end, the OP pointed out that Microsoft had released a C++ compiler package for Python 2.7 (http://www.microsoft.com/en-us/download/details.aspx?id=44266).
I installed this package but still haven't had any success in installing ujson. So far I've tried the following:
Adding the location of vcvarsall.bat to the path environment variable
Manually tried loading the VC++ compiler's environment into the session by executing vcvars64.bat (aI've tried vcvars32.bat as well) as recommended here: https://stackoverflow.com/a/18045219
I've also tried installing the compilers found in "Windows SDK for Windows 7 and .NET Framework 3.5 SP1" found here: http://www.microsoft.com/en-us/download/details.aspx?id=3138
Not sure where to go from here, any suggestions/help would be greatly appreciated.
For reference here's some relevant specs:
Windows 8.1 (64-bit)
Python 2.7 (64-bit)
I've been trying to install said package using pip from the command prompt (e.g. '> pip install ujson')
I've uninstalled all the C++ compiler packages I've tried except this one: http://www.microsoft.com/en-us/download/details.aspx?id=44266
Really don't feel like installing mingw, but I'll try it if it seems like it's the only solution.
-UPDATE-
I ended up modifying "msvc9compiler.py" and manually setting the location of vcvarsall.bat by setting the value of the vcvarsall variable to the location of that batch file. Everything compiled fine but this is not a recommended solution. I'm pretty sure the compiler version I have matches the one python 2.7 uses, but as mentioned in an answer, in another question on this topic, if these don't match it can cause problems since "the compilers will probably have incompatible C runtime libraries."

How to point pyinstaller to the right versions of MSVC?90.dll?

I have a python application that I am trying to build as a pyinstaller distributable. A similar script builds successfully on Linux.
I am building it on Windows 7 x64, but want to build 32-bit binary for better compatibility, so I am using 32-bit python-2.7. Among my dependencies are matplotlib and pyside which require MSVC. I install a package called VCForPython27 from Microsoft.
I run into an error when I run my pyinstaller script. I get the following message:
1250 INFO: Adding Microsoft.VC90.CRT to dependent assemblies of final executable
7428 INFO: Searching for assembly x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_none ...
7428 WARNING: Assembly not found
7428 ERROR: Assembly x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_none not found
7475 WARNING: lib not found: MSVCR90.dll dependency of C:\Python27\python.exe
7553 INFO: Searching for assembly x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_none ...
7553 WARNING: Assembly not found
7553 ERROR: Assembly x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_none not found
7662 WARNING: lib not found: MSVCR90.dll dependency of C:\Windows\system32\python27.dll
7662 INFO: Analyzing C:\Python27\lib\site-packages\PyInstaller\loader\_pyi_boots
There are multiple messages like that about both the files MSVCP90.dll and MSVCR90.dll
I can see that I have a folder C:\Windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4148_none_5090ab56bcba71c2 that contains versions of both files.
This mismatch occurs both when I install my python packages from Christoph Gohlke's page and with pip (except for matplotlib, which I can't install with pip because of missing dependencies).
Strangely enough pyinstaller makes a binary. Yet, when I try to run it I get a popup saying:
WARNING: file already exists but should not:
C:\Users\Martin\AppData\Local\Temp\_MEI34922\Include\pyconfig.h
Does anyone know how I can do any of the following:
Install the precious x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_none assembly? Where can I take this specific version from?
Tell python to look for the other version (x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4148_none_5090ab56bcba71c2)?
Solve the pyconfig.h unwanted presence issue? Doesn't seem to lead anywhere, but I thought I should try it too.
Find another way to build my code to a binary? It's a complicated code, running external binaries, but if I have to I will try py2exe, not sure that it would be any better though.
The redistributable package that contains version 9.0.21022.8 of msvcr90.dll and msvcp90.dll can be downloaded from the Microsoft website here. This will help PyInstaller to find the versions it wants and include them with the resulting executable.
Interestingly enough, I'm able to run the executable compiled by PyInstaller with redistributable version 9.0.30729.6161 installed, it just won't package these dlls. I tried to copy the msvc*90.dll's into the dist directory, even tried creating and modifying manifest files, but I would still get an error from python27.dll in the end. Installing any version of VC++ redistributable would fix the issue, but then my package wouldn't be self-containing. I wish I understood what exactly is going on here better...

The procedure entry point _gxx_personality_v0 could not be located in the dynamic link library libstdc++-6.dll

I have installed Codeblocks 13.12 with MinGW and I try to run an OpenCV application. I compiled it with no problems but when I try to run it throws the following error:
The procedure entry point _gxx_personality_v0 could not be located in the dynamic link library libstdc++-6.dll
I checked on stackoverflow questions with similar problems and everyone was pointing to copying the MinGW dll file to the application folder. I did that and then I had this error:
This application has failed to start because libgcc_s_dw2-1.dll was not found. Reinstalling the application may fix this problem.
So I copied that dll too. And then I had the following error:
This application has failed to start because libgcc_s_sjij-1.dll was not found. Reinstalling the application may fix this problem.
I copied this dll too and then I had the first error about the missing __gxx_personality_v0 entry point all over again.
This is an ABI incompatibility. You are linking code built with two different toolchains (one with dw2 exception handling and one with sjlj).
Either rebuild everything with the same toolchain, or find yourself a matching toolchain:
MinGW-w64 installer is located here. You can select various variants when you run it.
Use MSYS2, which comes with a repository containing a variety of packages already compiled for you (including OpenCV). It comes with the pacman package manager (ported from Arch Linux). It provides a Unix shell environment for your convenience, but the toolchains can be used outside of the shell itself.