On my Windows 10 system, I set up Haskell using GHCup. I installed ghc, cabal and stack. Now I am trying to install a package depending on network. Network needs msys for building, but it is obviously not detected:
C:\Users\Michael\source\repos\dummy>stack install network
network> configure
network> [1 of 2] Compiling Main ( C:\Users\Michael\AppData\Local\Temp\stack-c2e699ee2698c622\network-3.1.1.1\Setup.hs, C:\Users\Michael\AppData\Local\Temp\stack-c2e699ee2698c622\network-3.1.1.1\.stack-work\dist\274b403a\setup\Main.o )
network> [2 of 2] Compiling StackSetupShim ( C:\Users\Michael\AppData\Roaming\stack\setup-exe-src\setup-shim-Z6RU0evB.hs, C:\Users\Michael\AppData\Local\Temp\stack-c2e699ee2698c622\network-3.1.1.1\.stack-work\dist\274b403a\setup\StackSetupShim.o )
network> Linking C:\Users\Michael\AppData\Local\Temp\stack-c2e699ee2698c622\network-3.1.1.1\.stack-work\dist\274b403a\setup\setup.exe ...
network> Configuring network-3.1.1.1...
network> setup.EXE: The package has a './configure' script. If you are on Windows, This
network> requires a Unix compatibility toolchain such as MinGW+MSYS or Cygwin. If you
network> are not on Windows, ensure that an 'sh' command is discoverable in your path.
network>
Although documentation seems sparse on it ("you might want to look into extra-path"), I configured stack seemingly correct to have the Shell provided by MSys2 in the path:
C:\Users\Michael\source\repos\dummy>type c:\Users\Michael\AppData\Roaming\stack\config.yaml
templates:
params: null
system-ghc: true
install-ghc: false
skip-msys: true
extra-path:
- 'C:\ghcup\msys64\usr\bin'
- 'C:\ghcup\msys64\mingw64\bin'
extra-include-dirs:
- 'C:\ghcup\msys64\mingw64\include'
extra-lib-dirs:
- 'C:\ghcup\msys64\mingw64\lib'
The MingW path is correct. A more direct test of stack shows that the path isn't applied:
C:\Users\Michael\source\repos\dummy>stack exec sh
Executable named sh not found on path: [".","C:\\Users\\Michael\\source\\repos\\dummy\\.stack-work\\install\\38482417\\bin","C:\\Users\\Michael\\AppData\\Roaming\\stack\\snapshots\\6c93f868\\bin","C:\\Users\\Michael\\AppData\\Roaming\\stack\\compiler-tools\\x86_64-windows\\ghc-8.10.7\\bin","C:\\ghcup\\bin",...,"C:\\WINDOWS\\system32","C:\\WINDOWS","C:\\WINDOWS\\System32\\Wbem","C:\\WINDOWS\\System32\\WindowsPowerShell\\v1.0\\",...,"C:\\Program Files\\Git\\cmd",...,"C:\\ghcup\\bin"]
I redacted parts of the path output that are unrelated to the problem. Obviously, no mention of the MSys directory here. Also obviously, sh.exe is not found, although it is where I expect it:
C:\Users\Michael\source\repos\xilinx>dir c:\ghcup\msys64\usr\bin\sh.exe
Datenträger in Laufwerk C: ist Windows
Volumeseriennummer: xxxx-xxxx
Verzeichnis von c:\ghcup\msys64\usr\bin
19.05.2021 07:47 2.201.842 sh.exe
1 Datei(en), 2.201.842 Bytes
0 Verzeichnis(se), ??.???.???.??? Bytes frei
This is a known issue with Stack. In windows, environt variable names are case-insensitive, but the base library "rio" used by stack doesn't ignore case when looking up environment variables. Under certain circumstances, the program path environment variable is called Path, not PATH. This is the case on the system the issue was observed on:
C:\Users\Michael\source\repos\dummy>set | findstr /i path
HOMEPATH=\Users\Michael
Path=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;...;C:\ghcup\bin
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
PSModulePath=C:\Program Files\WindowsPowerShell\Modules;C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules
In this case, stack fails to expand the PATH variable, so the correct extra-path entries in config.yaml are ignored.
To fix the problem, use the windows environment variables dialog to adjust the spelling of the systemwide path variable. The spelling of the per-user path variable doesn't matter, as the system path is applied first, and merging the user path entries into that variable keeps the spelling set up by applying the system path.
Related
When trying to use octeract with pyomo, I uncounter the following error.
2022-06-22 15:48:44,451 [ WARNING][pyomo.opt] Failed to create solver with name 'octeract-engine':
Failed to set executable for solver asl. File with name=octeract-engine either does not exist or it is not executable. To skip this validation, call set_executable with validate=False.
[...]
The SolverFactory was unable to create the solver "octeract-engine"
and returned an UnknownSolver object. This error is raised at the point
where the UnknownSolver object was used as if it were valid (by calling
method "solve").
The original solver was created with the following parameters:
executable: octeract-engine
type: octeract-engine
_args: ()
options: {}
I've tried following both octerat doc and this doc unsuccessfully.
This is the classic Pyomo message when the binary it's told to invoke (in this case octeract-engine) is not in the system PATH.
You can fix this by adding the engine to the PATH. The way to verify that this was done correctly is to start up the terminal that you use to invoke Pyomo (e.g. linux terminal or powershell), and type octeract-engine (linux) or octeract-engine.exe (windows). If the engine is in the PATH, this will print the engine's help menu, otherwise the system will complain that the binary was not found.
What's actually happening here is that Octeract Engine connects to Pyomo through an ASL interface. Pyomo simply looks for a binary in the system PATH with the "name" specified in the command. As long as that binary has an ASL interface, it will just work, however Pyomo leaves it up to the user to ensure that the binary is visible in the PATH.
Our installers actually add the binary to the PATH on all platforms by default for this reason, so try a clean reinstall and see if that fixes your issue. Otherwise, it's likely that you don't have the right permissions set up on your machine i.e., the Python version that runs Pyomo doesn't see the right PATH (e.g. if you use octeract-engine.exe on powershell but run Pyomo from cmd.exe).
error: failed to write bytecode to F:\substrate-node-template\substrate-node-template-master\target\release\wbuild\node-template-runtime\target\wasm32-unknown-unknown\release\deps\pallet_transaction_payment_rpc_runtime_api-927dd9f7f5859937.pallet_transaction_payment_rpc_runtime_api.a5dcb31e-cgu.0.rcgu.bc: The system cannot find the path specified. (os error 3)
enter image description here
Note that Windows systems have a restriction on path length, and sometimes substrate runs into this! Better to put your build folder closer to your root dir to minimize path length. More in this issue(https://github.com/substrate-developer-hub/substrate-node-template/issues/185)
it's a dup question, though.
I'm running into a problem where python is unable to see folders or files which do exist on the computer. I have already ensured the path has no symbolic links in it and that I have full control on the NTFS file permissions. I have even removed any hidden attributes. Below is the script I am using and its output:
import os
path = 'C:\\Windows\\System32\\GroupPolicy\\Machine'
print path
test = os.path.exists(path)
print test
C:\Windows\System32\GroupPolicy\Machine
False
I am unsure why it is returning False when I have ensured the folder does exist. If I remove "\Machine" from the path, it returns True. I have verified the following command works from a command prompt:
if exist c:\Windows\System32\GroupPolicy\Machine echo found
Any advice on how to get this working in python would be appreciated. Here is the version of python I am using:
Python 2.7.6 (default, Nov 10 2013, 19:24:18) [MSC v.1500 32 bit (Intel)] on win32
Alright, after some digging, found it is nothing to do with permissions but has to do with File System Redirection. As I am using the x86 version of python on a Windows x64 (using x86 as I am using py2exe), Windows is redirecting any queries on System32 and subdirectories to SysWOW64. This means I was actually querying "C:\Windows\SysWOW64\GroupPolicy\Machine" which did not exist.
To fix this, I found how to disable the File System redirection using the recipe found here: http://code.activestate.com/recipes/578035-disable-file-system-redirector/
Here is my final code which now works to disable the redirection and allows opening and querying of files in System32 on a 64 bit machine.
import ctypes
class disable_file_system_redirection:
_disable = ctypes.windll.kernel32.Wow64DisableWow64FsRedirection
_revert = ctypes.windll.kernel32.Wow64RevertWow64FsRedirection
def __enter__(self):
self.old_value = ctypes.c_long()
self.success = self._disable(ctypes.byref(self.old_value))
def __exit__(self, type, value, traceback):
if self.success:
self._revert(self.old_value)
disable_file_system_redirection().__enter__()
import os
path = 'C:\\Windows\\System32\\GroupPolicy\\Machine'
print path
test = os.path.exists(path)
print test
I followed all the instruction mentioned in https://github.com/cisco/openh264 but I am unable to get through. The information is cited in link but its quite confusing.
Alternative Way:
You can build Openh264 using visual studio in windows. Here are the steps..
i) Download OpenH264 source code provided by cisco (that already you
mentioned https://github.com/cisco/openh264).
ii) Now you will find two visual studio compatible projects in
directory /OpenH264/codec/build/win32/dec and
/OpenH264/codec/build/win32/enc.
iii) You will need to download NASM software from http://www.nasm.us/pub/nasm/releasebuilds/2.12.02/
iv) Install NASM software on the directory C:\NASM or wherever you like.
v) Then Add NASM executable path to all these visual studio projects.
vi) Then You can either select static or dynamic library in general
options.
vi) If you are able to perform all these operations successfully, you will have 5 different .lib or .dll files named welsdcore, welsdecplus, welsecore, welsencplus, welsvp and those
are usable in any visual studio projects.
Now if you want to get openh264 features, just add all these libraries to your project and enjoy.
Hope it will help you.. :)
I also had some difficulty building openh264 on Windows using the recommended mingw approach.
In my case make crashed for all configurations I tried:
bash -c "make OS=msvc ARCH=x86_64 USE_ASM=No BUILDTYPE=Debug clean"
bash -c "make OS=msvc ARCH=x86_64 USE_ASM=No BUILDTYPE=Debug"
0 [main] make 3888 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
564 [main] make 3888 open_stackdumpfile: Dumping stack trace to make.exe.stackdump
0 [main] make 5448 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
561 [main] make 5448 open_stackdumpfile: Dumping stack trace to make.exe.stackdump
copying dll files to destination folder...
FullDestDir is E:\projects\openh264\bin\x64\Debug
current dir is:
E:\projects\openh264
DestDir is bin/x64/Debug
cp: cannot stat `openh264.dll': No such file or directory
cp: cannot stat `openh264.lib': No such file or directory
cp: cannot stat `openh264.pdb': No such file or directory
cp: cannot stat `codec_unittest.exe': No such file or directory
cp: cannot stat `h264enc.exe': No such file or directory
cp: cannot stat `h264dec.exe': No such file or directory
BuildDebugFlag =1
BuildReleaseFlag =0
BuildDebugInfo ="build debug--failed"
BuildReleaseInfo =NULL
aBuildFlagList is 1 0
ReturnCode is 1
I resorted to converting the existing solution/projects (VS2008) to VS2013 and linking/building with the created .lib files.
You can find the solutions in {openh264_dir}\codec\build\win32\enc and {openh264_dir}\codec\build\win32\dec.
Building the solution will create .libs and .dlls in {openh264_dir}\bin\Win32\Release
To link to the lib, you need to link to welsenc.lib.
When running, you need to have both the welsenc.dll and welsvp.dll in your application directory. So far it seems to have worked fine for my usage.
I'm assuming that building the decoder will be similar.
Using kitware's CMake, is it possible to automatically download a Microsoft installer (MSI) file and execute it (on Windows, of course)?
It generally should be. However, clearly running the installer will block the CMake process until the user completes all the required inputs to the installer.
Here's an example for 7-zip's installer making use of file(DOWNLOAD ...) and execute_process:
set(DownloadedMsi ${CMAKE_BINARY_DIR}/7z920-x64.msi)
file(DOWNLOAD http://sourceforge.net/projects/sevenzip/files/7-Zip/9.20/7z920-x64.msi/download
${DownloadedMsi}
TIMEOUT 30
STATUS StatusVar
LOG LogVar
EXPECTED_HASH SHA1=4173fea2af9a595fa0be1ef8251f412229687be1)
message("\${StatusVar} - ${StatusVar}")
message("\${LogVar} - ${LogVar}\n\n\n")
execute_process(COMMAND cmd /c "${DownloadedMsi}"
RESULT_VARIABLE ResultVar
OUTPUT_VARIABLE OutputVar
ERROR_VARIABLE ErrorVar)
message("\${ResultVar} - ${ResultVar}")
message("\${OutputVar} - ${OutputVar}")
message("\${ErrorVar} - ${ErrorVar}")