I'm building my application and when I try to run it on the emulator, I get this error.
Creation Time Description Resource Path Location Type
1254339868582 BLDMAKE ERROR: Directory "\S60\devices\Nokia_N97_SDK_v1.0\epoc32\" does not exist ZeFirst Unknown C/C++ Problem
The folder does exist and does have the necessary rights.
The console has the following set of warning messages
warning: "C:\S60\devices\Nokia_N97_SDK_v1.0\epoc32\tools\GCCEV6.bsf" Invalid BSF specification - customization restricted to ARMV5, ABIv2 and valid BSF platforms
warning: "C:\S60\devices\Nokia_N97_SDK_v1.0\epoc32\tools\GCCEV6T2.bsf" Invalid BSF specification - customization restricted to ARMV5, ABIv2 and valid BSF platforms
warning: "C:\S60\devices\Nokia_N97_SDK_v1.0\epoc32\tools\GCCEV7A.bsf" Invalid BSF specification - customization restricted to ARMV5, ABIv2 and valid BSF platforms
What other development tools do you have installed on your computer?
Is there a chance your path environment variable is in the wrong order and you're not using the correct version of the compiler, for example?
Feel free to post your path, it can only provide more information.
I'm not sure if this will work, but try this:
Subst a drive to C:\S60\devices\Nokia_N97_SDK_v1.0\
Start, Run...
subst x: C:\S60\devices\Nokia_N97_SDK_v1.0\
Then in carbide, set your SDK to point to this subst location.
Window, Preferences, Carbide C++, SDK ..
Change the paths to use "x:\" rather than C:\...
Delete any imported projects in Carbide
Select project, right-click, delete.
(Do NOT click the tick box that is displayed).
Re-import your project
File, Import, x:\.....\bld.inf
I have faced a similar problem once.
If you have been able to build and launch the eumlator on earlier occasions, then the only solution that worked for me was to re-install the SDK.
Techeretic,
make sure that your workspace is located in the same driver partition (C:) of your Symbian SDK installation. If don't try changing it.
Sometimes I solved that problem by changing .pkg file's content to use a relative path. For example:
;Files to install
;You should change the source paths to match that of your environment
;<source> <destination>
"$(EPOCROOT)Epoc32\release\$(PLATFORM)\$(TARGET)\MyApp.exe" -"!:\sys\bin\MyApp.exe"
"$(EPOCROOT)Epoc32\data\z\resource\apps\MyApp.r01" -"!:\resource\apps\MyApp.r01"
"$(EPOCROOT)Epoc32\data\z\private\10003a3f\apps\MyApp_reg.r01" -"!:\private\10003a3f\import\apps\MyApp_reg.r01"
"$(EPOCROOT)epoc32\data\z\resource\apps\MyApp_aif.mif" -"!:\resource\apps\MyApp_aif.mif"
"$(EPOCROOT)epoc32\data\z\resource\apps\MyApp.mbm" -"!:\resource\apps\MyApp.mbm"
Hope it helps.
Related
I'm trying to debug a memory dump, using Visual Studio, as managed, but this fails with following error message:
Managed debugging is not available for this minidump.
A required library for managed minidump debugging,'mscordbi.dll', version '4.0.30319.0', could not be located.
Restart your debug session after trying one of more of the following steps:
If this computer is not currently connected to the internet, connect so the dll can be downloaded from Microsoft.
Specify the path to 'mscordbi.dll' in Symbol Settings under Debugger options.
Select 'Debug with Native Only'.
While checking my Symbol Settings, there are following Symbol file (.pdb) locations (all are checked):
Environment Variable: _NT_SYMBOL_PATH
Microsoft Symbol Servers
C:\Dump_Repository\... (not relevant for this question)
A cache directory is foreseen, and the automatic loading preference is set to Load all modules, unless excluded. The only excluded one is user32.dll.
The value of the _NT_SYMBOL_PATH environment variable is the following:
cache*;srv*C:\Dump_Analyse*C:\build_machine1;cache*;srv*C:\Dump_Analyse*\\build_machine2\Development\Symbols;cache*;srv*C:\Dump_Analyse*\\build_machine1\Symbols;cache*;srv*https://msdl.microsoft.com/download/symbols;cache*;srv*C:\ProgramData\dbg\sym
In the mentioned directory C:\Dump_Analyse, there is a directory mscordbi.dll, with three subdirectories, each containing the mentioned mscordbi.dll DLL:
Prompt>find ./ -name "mscordbi.dll" 2>/dev/null
./Dump_Analyse/mscordbi.dll (this is a directory)
./Dump_Analyse/mscordbi.dll/4BA1DA2Deb000/mscordbi.dll
./Dump_Analyse/mscordbi.dll/563C0E8E10b000/mscordbi.dll
./Dump_Analyse/mscordbi.dll/583E5AAD10b000/mscordbi.dll
The two last ones seem not that relevant, but the first one has file version 4.0.30319.1 (which is very near to the requested version).
My computer is connected to the internet, my account seems to be ok (I have recently modified the password of my Windows account, but I'm logged in on Visual Studio under another account).
Does anybody know what might be happening here and how I can solve this issue?
The problem is solved:
While trying further, I wanted to clear the symbol cache, which did not work (a user permission was said not to be correct).
That cache symbols was a directory, containing a tilde character: ~ (something like C:\Users\Dominique~1\AppData\Local\Temp\SymbolCache).
I've replaced this by the real directory name (by clicking the Browse button):
C:\Users\DominiqueDS\AppData\Local\Temp\SymbolCache
In other words (for searching purposes): in Visual Studio Symbol settings, the symbols cache directory should not contain a ~ (tilde) character.
Whenever I try to run my app in Xcode 6 Beta 4 I am getting the error:
The file "MyApp.app" couldn't be opened because you don't have permission to view it.
This error appears no matter what simulator or device I target.
I have tried:
Deleting all Derived Data from Organizer in Xcode
Repairing permissions on my drive
Manually elevating the permissions of the built MyApp.app
Restarting my computer
Has anyone else run into this problem and found a solution?
I use Xcode6 GM. I encountered the same problem. What I did was to go to Build Settings -> Build Options. Then I changed the value of the "Compiler for C/C++/Objective-C" to Default Compiler.
Having the problem on DEVICE too (not just simulator)?
The other solutions only fixed it for me on simulator, not device.
For me this problem occurred (in Xcode 6) when I would try to change the main info.plist properties whilst trying to change my app name.
In info.plist I had changed Executable File name to something other than the default ${EXECUTABLE_NAME}...
I had mistaken this field for the field that changes the name of the app under the icon on the springboard.
In Xcode do the following
Window --> Organiser --> Projects --> The app with the issue --> delete button in Derived Data.
I then cleaned the project and voila
works
For me, a simple Product -> Clean worked great
I've fixed it by cleaning a build folder. Just went to 'Product' menu and Option+Click 'Clean'. After that a problem was resolved.
There was a problem with the Info.plist of the project. I created a new project with the same name in Xcode 6 beta 4 and then replaced the real project's Info.plist with the new one. The project then built and ran fine.
Look at the diff, it appears like the plist might have somehow gotten mixed up with a playground's plist. The bundle identifier was "com.apple.dt.playground.iOS-18300-13" and the executable and bundle names were "iOS" along with some other oddities.
This is the full diff in case anyone needs it for reference:
<key>CFBundleDevelopmentRegion</key>
<string>en</string>
<key>CFBundleExecutable</key>
- <string>iOS</string>
+ <string>${EXECUTABLE_NAME}</string>
<key>CFBundleIdentifier</key>
- <string>com.apple.dt.playground.iOS-18300-13</string>
+ <string>com.myCompany.${PRODUCT_NAME:rfc1034identifier}</string>
<key>CFBundleInfoDictionaryVersion</key>
<string>6.0</string>
<key>CFBundleName</key>
- <string>iOS</string>
+ <string>${PRODUCT_NAME}</string>
<key>CFBundlePackageType</key>
- <string>AAPL</string>
+ <string>APPL</string>
<key>CFBundleShortVersionString</key>
<string>1.0</string>
- <key>CFBundleSupportedPlatforms</key>
- <array>
- <string>iPhoneSimulator</string>
- </array>
+ <key>CFBundleSignature</key>
+ <string>????</string>
<key>CFBundleVersion</key>
<string>1</string>
- <key>DTPlatformName</key>
- <string>iphonesimulator</string>
- <key>DTSDKName</key>
- <string>iphonesimulator8.0</string>
- <key>LSBackgroundOnly</key>
- <true/>
<key>LSRequiresIPhoneOS</key>
<true/>
+ <key>UIMainStoryboardFile</key>
+ <string>Main</string>
<key>UIRequiredDeviceCapabilities</key>
<array>
<string>armv7</string>
</array>
+ <key>UISupportedInterfaceOrientations</key>
+ <array>
+ <string>UIInterfaceOrientationPortrait</string>
+ <string>UIInterfaceOrientationLandscapeLeft</string>
+ <string>UIInterfaceOrientationLandscapeRight</string>
+ </array>
</dict>
</plist>
I've had same this error in Xcode 8.2. The reason I found out for me, another Info.plist is added in my project while adding library (manually copy).
So that Xcode is getting confused for selecting correct Info.plist.
I just removed that Info.plist from the added library.
Then it is working fine without any permission alert.
Please check if you have changed Executable file => $(EXECUTABLE_NAME) to any other name. If you have changed this name then it shows this error. Please replace it with $(EXECUTABLE_NAME).
Product -> Clean (command shift K) fixed it for me
My goodness!! I spent hours to resolve this issue.
On XCode 7.3 I was having project with no issues.
Mistake I did
I just Added physical folders and moved my files into them, problem started.
I tried everything
Default compiler
Clean and build
Reset simulator and reboot simulator, Xcode, iPhone even mac
Updated Info.plist
Deleting Derived Data
Editing the permission on the folder of the project
Checking my architectures
nothing worked :(
How I resolved
I was about create new project and then I just deleted those physical
folders I added, clean build and YESS!!
It works!!
Try "cmd+shift+k" to clean the project and rebuild. At least it worked for me
Sometimes opening old project in new version Xcode will get this message.
Go to Issue navigator and follow the warning hint 'Upate to reconmmented settings'.
Boom, magic!
I had similar issue (xCode 6.2) for sample code downloaded. I tried to set Executable Name to Default in Info.plist but this didn't worked.
Instead change Compiler for C/C++/Objective-C to Default compiler (Apple LLVM 6.0) instead of Unsupported Compiler(com.apple.compilers.llvmgcc42) for project.
My Application was working fine on XCode 9.4, but when I opened my project in XCode 10 I was experiencing this issue. For me the issue was the build setting. I found the answer in this page https://forums.developer.apple.com/thread/112141.
In short go to File > Workspace Settings… > Build System and change it to "Legacy Build System"
1) Go Firstly Build Options.
2) Then changed the value of the "Compiler for C/C++/Objective-C" to Default Compiler.
clean and working :-)
I found that changing my compiler to LLVM 6.0 in the Build Options was enough for me (xcode 6.1)
I got same error on my Xcode 6.1.1 for a project downloaded from gitHub which was committed 4 years ago.
For me, setting Architectures to the default value Standard architectures(armv7,arm64) and Compiler for C/C++/Objective-C to Default Compiler in Building Settings worked.
I had the same issue in my project. Later on found that third-party (fmdb for SQLite) file used in project contained Info.plist.
Simply deleting the Info.plist file worked for me!
I recently meet the same problem for running an old project (initially created in Xcode 4.x) in Xcode 6.0.1.
I fixed the problem by changing the Architectures in Building Settings to the default value, which is "Standard architectures(armv7,arm64)".
Hope this could help anyone who got similar problems :)
I've had this error with a number of my older projects that I am getting out of the cupboard to update. It seems that using Xcode 6 with older code seems to bring this about for some reason.
I have fixed this in all projects that I have done this with by:
Delete Derived Data
in Product: do a clean
go to Build Settings in the project Target and go to Build Options and change the value of the "Compiler for C/C++/Objective-C" to 'Default
Compiler'.
I tried all of the listed answers and none of them was useful. The problem was due to existence of an another plist file linked from a submodule via cocoapods. Luckily this was my own module, so I just deleted this plist from the submodule project and reinstalled pods.
solution
Later on I understood that the key of the problem was in the name of that second plist: simply info.plist. You may rename the file and relink it via a sources section of a submodule
That second plist file had a unique name, so Xcode was not supposed to become frustrated. Even my target settings pointed on a main plist, not on a info.plist. Looks like Xcode takes special consideraions about that name
The bug reproduced in Xcode 6.4 and Xcode 7.0
Well in my case, I just rename the Bundle Name and Executable file values in info.plist same as project name. It worked for me.
What I did is here:
I deleted VALIDARCHS from Project
I deleted VALIDARCHS from Target
Build Active Architecture Only = YES (for Debug) Architectures
Standard Architectures $(ARCHS_STANDARD)
Also, File -> Project/Workspace Settings == New Build System
Xcode Version 12.0 (12A7209)
I had this similar problem. Somehow my value for the key Executable File got mixed up. Just change it back to ${EXECUTABLE_NAME} (Under your project > Info). Worked for me!
If you google the text of this error message you will find maybe 20 threads across StackOverflow, Apple dev forums, Reddit, etc. about Xcode failing to be able to run a compiled executable with this error message.
In these threads you will find many people offering various suggestions about how to fix the problem: changing product name to match project name, changing build phase options, something with info.plist, changing compilers to or from Clang, etc. Presumably the suggestions are offered in good faith because they solved the problem for someone, but the answers are so varied that it is clear that the error message is generic and this is an important point if you are receiving it: this error seems to mean that something is wrong with the binary. Ignore its actual text: it may have nothing to do with permissions.
There is no general solution to this error. The error message is totally generic; assume it means "bad binary file". The solution if you are receiving it depends on what you are trying to do, what has changed, why you are seeing this error all of a sudden. Google the specifics of your situation rather than this error message.
In my case, and I have a feeling this is a common case, what I was trying to do was build an old iOS project, nine years old I think, on modern Xcode. The solution was to switch to the legacy build system which led to a compilation error because in the old project there were not modern architecture targets, which could be fixed by manually adding them.
In my case main.m containing the main(...) function was not contained in the list of "Compile Sources" in "Build Phases". To check if this is the case, enter into Build Phases and look, if your main.m appears in the "Compile Sources" list.
Don't know if the problem is related but maybe it can be a solution for anyone pulling the hairs like me.
In my case, I have a project with a lot of targets. Each target is a customisation of that base project which is a Cocoa Touch Static Library and the targets, Applications. Even if the main file is added into the library compilation, but not in each target, that error message appears. So what I did? Manually added the main file to each target in the Compile Sources section and bingo, all fine.
For me the error was in the .plist file at the key CFBundleExecutable.
I had renamed the executable removing a space that was between two words. (Eg: from "Wild Racer" to "WildRacer"). Took 1 day to spot it!!
Xcode is soooo unhelpful in the debugging!
What solved it for me was setting Build Active Architecture Only from No to Yes.
with X-code 6.3.2
[Build Settings] Options.
[All]-[Build Options]-[Compiler for C/C++/Objective-C]-[Default compiler (Apple LLVM 6.1)]
Then rebuild the project, and it runs ok.
We are using an environment variable to specify a path to a library we use. Most of the time it points to the released version but sometimes to a development version.
Anyway, it works ok when I use $(MyLib)/path;%(AdditionalIncludeDirectories) for building the C++ application but I can not open the project resources. However, when I use %(MyLib)/path;%(AdditionalIncludeDirectories) it works.
Now, what is the difference?
I thought the correct way is to use $(EnvVar) but for the resource editor it doesn't seems to work. And if $(EnvVar) is the correct way then why does Visual Studio use %(AdditionalIncludeDirectories) and not $(AdditionalIncludeDirectories)
The error I get is: fatal error RC1015: cannot open include file 'afxres.h'.
You use %(item) to refer to an MSBuild metadata item. Using $(AdditionalIncludeDirectories) would not work well if you also had an environment variable by that name. So %(MyLib)/path ought to resolve to just /path.
You can put echo %(MyLib)/path in a prebuild event to verify this.
Which is probably enough to stop confusing rc.exe, the resource compiler. Which is a stone-cold-old SDK utility, going back all the way to Windows version 1.0. It is pretty temperamental, very picky about command line options and .rc script file text encoding. Do keep in mind that it dates from an era long before Windows started to support a forward slash as a path separator, everybody had to use a backslash back in 1986.
So use "$(MyLib)\path" instead, including the double quotes so you don't confuzzle it when MyLib contains embedded spaces. And do favor using a project property sheet instead so there are some odds that somebody can still figure out how to get the project built correctly 2+ years from now.
I've downloaded Chromium Embedded Framework r306 for Windows and built it. Unfortunately, it shows, that it doesn't support mp3:
<script>
var a = document.createElement("audio");
document.write(a.canPlayType('audio/mpeg'));
</script>
Output is empty and when I try to open an mp3 file, it can't be played (ogg is playable).
The same time Google Chrome writes "maybe" (and it actually plays).
How can I add support for MP3 in CEF?
Marshall Greenblatt (the maintainer of the Chromium Embedded Framework) addresses the lack of support for MP3 (and AAC) in Chromium and CEF in this bug report (see comment #7, copied below):
Codecs like MP3 and AAC are included in Google Chrome releases but not Chromium builds. This is because these formats are not open and require licensing. Distributing these codecs with your application without a licensing agreement may violate the law in certain countries. You should discuss with a lawyer if appropriate.
NOTE: PLEASE CONSIDER LEGAL ISSUES BEFORE PROCEEDING
There is a way to enable MP3 support in CEF, but you'll have to modify the cef.gypi in the source distribution, regenerate the visual studio projects and rebuild.
Step by step instructions:
a
a
There is a way to enable MP3 support in CEF, but you'll have to modify the cef.gypi in the source distribution, regenerate the visual studio projects and rebuild.
Detailed build instructions:
https://bitbucket.org/chromiumembedded/cef/wiki/BranchesAndBuilding
Enabling proprietary codecs support:
http://code.google.com/p/chromiumembedded/issues/detail?id=371
Add 'proprietary_codecs': 1 to your cef.gypi configuration so that USE_PROPRIETARY_CODECS will be defined as required by net/base/mime_util.cc.
You'll also need proper builds of the avcodec, avformat and avutil DLLs. Luckily, you can just get these from the installation directory of Google Chrome itself ($User/AppData/Local/Google/Chrome/$Version).
the options to enable proprietary codecs (i.e. H.264 and MP3) have been moved since the last answer.
you can read my answer with all the details on how to compile CEF with enabled proprietary codecs
the magic now happens here:
set GN_DEFINES=is_official_build=true proprietary_codecs=true ffmpeg_branding=Chrome
there is 2 batch files that you should update/create (as found here):
c:\code\chromium_git\update.bat:
set CEF_USE_GN=1
set GN_DEFINES=is_official_build=true proprietary_codecs=true ffmpeg_branding=Chrome
set GN_ARGUMENTS=--ide=vs2015 --sln=cef --filters=//cef/*
python ..\automate\automate-git.py --download-dir=C:\code\chromium_git --depot-tools-dir=C:\code\depot_tools --no-distrib --no-build
c:\code\chromium_git\chromium\src\cef\create.bat:
set CEF_USE_GN=1
set GN_DEFINES=is_win_fastlink=true proprietary_codecs=true ffmpeg_branding=Chrome
set GN_ARGUMENTS=--ide=vs2015 --sln=cef --filters=//cef/*
call cef_create_projects.bat
There is 2 wiki articles that explain how to build CEF/Chromium:
https://bitbucket.org/chromiumembedded/cef/wiki/MasterBuildQuickStart.md
and BranchesAndBuilding in the same wiki
MP3 codec only be supported When build to Google Chrome, check chromium's Codec Support.
On client side, the compatible way may be Flash, check google translate's code.
I followed the steps in null1941's answer and they worked great save a few caveats having to do with modifying the build.ps1 script
step 16 e. search for any instances of 3.y.z and replace them with the current version you are building (from the folder name containing the builds ex. 3.2272.32.gbda8dc7).
in function DownloadNuget it is trying to see if you have nuget in a specific place and if it isn't there it tries to go get it. Problem is DownloadFile would fail if the save directory didn't already exist. so you can manualy create or add this to the function:
$Nuget_dir = Join-Path $env:LOCALAPPDATA .\nuget
if(-not (Test-Path $Nuget_dir))
{
mkdir $Nuget_dir
}
change line: "Copy-Item $Cef64\include $CefInclude -Recurse | Out-Null" to use $Cef32 if you don't have 64bit cef folders
I am attempting to put together a simple c++ test project that uses an embedded python 3.2 interpreter. The project builds fine but Py_Initialize raises a fatal error:
Fatal Python error: Py_Initialize: unable to load the file system codec
LookupError: no codec search functions registered: can't find encoding
Minimal code:
#include <Python.h>
int main (int, char**)
{
Py_Initialize ();
Py_Finalize ();
return 0;
}
The OS is 32bit Vista.
The python version used is a python 3.2 debug build, built from sources using VC++ 10.
The python_d.exe file from the same build runs without any problems.
Could someone explain the problem and how to fix it? My own google-fu fails me.
EDIT 1
After going through the python source code I've found that, as the error says, no codec search functions have been registered. Both codec_register and PyCodec_Register are as they should be. It's just that nowhere in the code are any of these functions called.
I don't really know what this means as I still have no idea when and from where these functions should have been called. The code that raises the error is entirely missing from the source of my other python build (3.1.3).
EDIT 2
Answered my own question below.
Check the PYTHONPATH and PYTHONHOME environment variables and make sure they don't point to Python 2.x.
http://bugs.python.org/issue11288
Parts of this have been mentioned before, but in a nutshell this is what worked for my environment where I have multiple Python installs and my global OS environment set-up to point to a different install than the one I attempt to work with when encountering the problem.
Make sure your (local or global) environment is fully set-up to point to the install you aim to work with, e.g. you have two (or more) installs of, let's say a python27 and python33 (sorry these are windows paths but the following should be valid for equivalent UNIX-style paths just as well, please let me know about anything I'm missing here (probably the DLLs path might differ)):
C:\python27_x86
C:\python33_x64
Now, if you intend to work with your python33 install but your global environment is pointing to python27, make sure you update your environment as such (while PATH and PYTHONHOME may be optional (e.g. if you temporarily work in a local shell)):
PATH="C:\python33_x64;%PATH%"
PYTHONPATH="C:\python33_x64\DLLs;C:\python33_x64\Lib;C:\python33_x64\Lib\site-packages"
PYTHONHOME=C:\python33_x64
Note, that you might need/want to append any other library paths to your PYTHONPATH if required by your development environment, but having your DLLs, Lib and site-packages properly set-up is of prime importance.
Hope this helps.
The core reason is quite simple: Python does not find its modules directory, so it can of course not load encodings, too
Python doc on embedding says "Py_Initialize() calculates the module search path based upon its best guess" ... "In particular, it looks for a directory named lib/pythonX.Y"
Yet, if the modules are installed in (just) lib - relative to the python binary - above guess is wrong.
Although docs says that PYTHONHOME and PYTHONPATH are regarded, we observed that this was not the case; their actual presence or content was completely irrelevant.
The only thing that had an effect was a call to Py_SetPath() with e.g. [path-to]\lib as argument before Py_Initialize().
Sure this is only an option for an embedding scenario where one has direct access and control over the code; with a ready-made solution, special steps may be necessary to solve the issue.
Ran into the same thing trying to install brew's python3 under Mac OS! The issue here is that in Mac OS, homebrew puts the "real" python a whole layer deeper than you think. You would think from the homebrew output that
$ echo $PYTHONHOME
/usr/local/Cellar/python3/3.6.2/
$ echo $PYTHONPATH
/usr/local/Cellar/python3/3.6.2/bin
would be correct, but invoking $PYTHONPATH/python3 immediately crashes with the abort 6 "can't find encodings." This is because although that $PYTHONHOME looks like a complete installation, having a bin, lib etc, it is NOT the actual Python, which is in a Mac OS "Framework". Do this:
PYTHONHOME=/usr/local/Cellar/python3/3.x.y/Frameworks/Python.framework/Versions/3.x
PYTHONPATH=$PYTHONHOME/bin
(substituting version numbers as appropriate) and it will work fine.
From python3k, the startup need the encodings module, which can be found in PYTHONHOME\Lib directory.
In fact, the API Py_Initialize () do the init and import the encodings module.
Make sure PYTHONHOME\Lib is in sys.path and check the encodings module is there.
I had this issue with python 3.5, anaconda 3, windows 7 32 bit. I solved it by moving my pythonX.lib and pythonX.dll files into my working directory and calling
Py_SetPythonHome(L"C:\\Path\\To\\My\\Python\\Installation");
before initialize so that it could find the headers that it needed, where my path was to "...\Anaconda3\". The extra step of calling Py_SetPythonHome was required for me or else I'd end up getting other strange errors where python import files.
I just ran into the exact same problem (same Python version, OS, code, etc).
You just have to copy Python's Lib/ directory in your program's working directory ( on VC it's the directory where the .vcproj is )
There appears to be something going wrong with the release build either failing to include the appropriate codecs or else misidentifying the codec to use for system APIs. Since the python_d executable is working, what does that return for os.getfsencoding()? (Use the C API to call that between your Initialize/Finalize calls)
I had the same issue and found this question. However from the answers here I was not able to solve my problem. I started debugging the cpython code and thought that I might be discovered a bug. Therefore I opened a issue on the python issue tracker.
My mistake was that I did not understand that Py_SetPath clears all inferred paths.
So one needs to set all paths when calling this function.
Link to the issue conversation
For completion I also copied the most important part of the conversation below.
My original issue text
I compiled the source of CPython 3.7.3 myself on Windows with Visual Studio 2017 together with some packages like e.g numpy. When I start the Python Interpreter I am able to import and use numpy. However when I am running the same script via the C-API I get an ModuleNotFoundError.
So the first thing I did, was to check if numpy is in my site-packages directory and indeed there is a folder named numpy-1.16.2-py3.7-win-amd64.egg. (Makes sense because the python interpreter can find numpy)
The next thing I did was to get some information about the sys.path variable created when running the script via the C-API.
#### sys.path content ####
C:\Work\build\product\python37.zip
C:\Work\build\product\DLLs
C:\Work\build\product\lib
C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2017\PROFESSIONAL\COMMON7\IDE\EXTENSIONS\TESTPLATFORM
C:\Users\rvq\AppData\Roaming\Python\Python37\site-packages
Examining the content of sys.path I noticed two things.
C:\Work\build\product\python37.zip has the correct path 'C:\Work\build\product\'. There was just no zip file. All my files and directory were unpacked. So I zipped the files to an archive named python37.zip and this resolved the import error.
C:\Users\rvq\AppData\Roaming\Python\Python37\site-packages is wrong it should be C:\Work\build\product\Lib\site-packages but I dont know how this wrong path is created.
The next thing I tried was to use Py_SetPath(L"C:/Work/build/product/Lib/site-packages") before calling Py_Initialize(). This led to
Fatal Python Error 'unable to load the file system encoding'
ModuleNotFoundError: No module named 'encodings'
I created a minimal c++ project with exact these two calls and started to debug Cpython.
int main()
{
Py_SetPath(L"C:/Work/build/product/Lib/site-packages");
Py_Initialize();
}
I tracked the call of Py_Initialize() down to the call of
static int
zipimport_zipimporter___init___impl(ZipImporter *self, PyObject *path)
inside of zipimport.c
The comment above this function states the following:
Create a new zipimporter instance. 'archivepath' must be a path-like
object to a zipfile, or to a specific path inside a zipfile. For
example, it can be '/tmp/myimport.zip', or
'/tmp/myimport.zip/mydirectory', if mydirectory is a valid directory
inside the archive. 'ZipImportError' is raised if 'archivepath'
doesn't point to a valid Zip archive. The 'archive' attribute of the
zipimporter object contains the name of the zipfile targeted.
So for me it seems that the C-API expects the path set with Py_SetPath to be a path to a zipfile. Is this expected behaviour or is it a bug?
If it is not a bug is there a way to changes this so that it can also detect directories?
PS: The ModuleNotFoundError did not occur for me when using Python 3.5.2+, which was the version I used in my project before. I also checked if I had set any PYTHONHOME or PYTHONPATH environment variables but I did not see one of them on my system.
Answer
This is probably a documentation failure more than anything else. We're in the middle of redesigning initialization though, so it's good timing to contribute this feedback.
The short answer is that you need to make sure Python can find the Lib/encodings directory, typically by putting the standard library in sys.path. Py_SetPath clears all inferred paths, so you need to specify all the places Python should look. (The rules for where Python looks automatically are complicated and vary by platform, which is something I'm keen to fix.)
Paths that don't exist are okay, and that's the zip file. You can choose to put the stdlib into a zip, and it will be found automatically if you name it the default path, but you can also leave it unzipped and reference the directory.
A full walk through on embedding is more than I'm prepared to type on my phone. Hopefully that's enough to get you going for now.
I had the problem and was tinkering with different solutions mentioned here. Since I was running my project from Visual Studio, apparently, I needed to set the environment path inside Visual Studio and not the system path.
Adding a simple PYTHONHOME=PATH\TO\PYTHON\DIR in the project solution\properties\environment solved the problem.
For me this happened when I updated Python 64 bit from 3.6.4 to 3.6.5. It threw some error like "unable to extract python.dll. Do you have permissions."
Pycharm also failed to load interpreter, even though I reloaded it in settings. Running python command gave same error, with and without administrator mode.
Reason
There was error in installation of Python, include folder in python installation directory C:\Users\USERNAME\AppData\Local\Programs\Python\Python36 was missing
Reinstalling Python also dint solve the issue.(Not removal and install)
Solution
Uninstall Python and Install of Python again.
Because running installer was just extracting same files excluding include folder
In my cases, for windows, if you have multiple python versions installed, if PYTHONPATH is pointing to one version the other ones didn't work. I found that if you just remove PYTHONPATH, they all work fine
For those working in Visual Studio simply add the include, Lib and libs directories to the Include Directories and Library Directories under
Projects Properties -> Configuration Properties > VC++ Directories :
For example I have Anaconda3 on my system and working with Visual Studio 2015 This is how the settings looks like (note the Include and Library directories) :
Edit:
As also pointed out by bossi setting PYTHONPATH in your user Environment Variables section seems necessary.
a sample input can be like this (in my case):
C:\Users\Master\Anaconda3\Lib;C:\Users\Master\Anaconda3\libs;C:\Users\Master\Anaconda3\Lib\site-packages;C:\Users\Master\Anaconda3\DLLs
is necessary it seems.
Also, you need to restart Visual Studio after you set up the PYTHONPATH in your user Environment Variables for the changes to take effect.
Also note that :
Make sure the PYTHONHOME environment variable is set to the Python
interpreter you want to use. The C++ projects in Visual Studio rely on
this variable to locate files such as python.h, which are used when
creating a Python extension.
So, for some reason the python dll fails to locate the encodings module. The python.exe executable apparently finds it because it has the expected relative path. Modifying the search path works.
The reason for all of this? Don't know but at least it works. I highly suspect a typo on my part somewhere, that's usually the reason for odd bugs it seems.