Year or so hence, I modified a project of mine to include subversion revision in installer file name.
I installed MSBuild.Community.Tasks.Targets and modified csproj file so that it contained:
<Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets" />
...
<SvnVersion LocalPath="$(MSBuildProjectDirectory)" ToolPath="C:\cygwin\bin">
<Output TaskParameter="Revision" PropertyName="Revision" />
</SvnVersion>
...
This worked like a charm. However, after upgrade to cygwin 1.7, following error started to occur when running build process:
C:\cygwin\bin\svnversion.exe --no-newline
"Z:/cygdrive/z/dev/myproject/src/winservice"
'/cygdrive/z/dev/myproject/src/winservice/Z:/cygdrive/z/dev/myproject/src/winservice'
doesn't exist
Z:\dev\swiftarhiv\src\myproject\myprojectservice.csproj(200,5): error
MSB6006 : "svnversion.exe" exited with code 1. Done Building Project
"Z:\dev\swiftarhiv\src\myprojects\myprojectservice.cspro j" (Rebuild
target(s)) -- FAILED.
I tried modifying LocalPath parameter of SvnInfo task to "." or "/cygdrive/z/dev/myproject/src/winservice", but SvnInfo task has a nasty habit of using windows full path no matter what you put in so "." resolved to the path used before and "/cygdrive/z/dev/myproject/src/winservice" resolved to "Z:/cygdrive/z/dev/myproject/src/winservice" which caused an error again.
Is there a setting I can set in Cygwin 1.7 that will make my problems scarce?
If you want to be able to deliberately use a particular path format, you could use the cygpath utility.
$ echo $PWD
/cygdrive/c/Windows
$ cygpath -ua .
/cygdrive/c/Windows/
$ cygpath -wa .
C:\Windows
Without knowing the particulars of the Subversion build process, would it be possible for you to set the LocalPath by passing that MSBuildProjectDirectory object through it?
Related
I have built llvm-13.0.1 from source using Visual Studio 17 2022 on Windows 11. When attempting to build llvm-sys (through external crate llvm-ir). It fails, saying:
error: No suitable version of LLVM was found system-wide or pointed to by LLVM_SYS_130_PREFIX.
I know llvm-config exists because I can use it from the command line, and it returns the correct version. I don't understand why this doesn't work. This might be a stupid question but I am really stuck.
I was also having this problem, trying to use llvm-sys on Windows. Here are some mistakes that I did that made it fail to compile just like yours.
Installation Prefix
Make sure that your LLVM installation path doesn't have any whitespace.
Mine was -DCMAKE_INSTALL_PREFIX=C:\Program Files (x86)\LLVM, which was their default install prefix. The whitespace in the installation path causes some errors when using it with llvm-sys. Later, I changed it to C:\LLVM and it worked.
Set Environment Variable
Set Environment Variable LLVM_SYS_<version>_PREFIX to the installed LLVM folder.
From CMD For LLVM-13.0.1
setx LLVM_SYS_130_PREFIX "<PATH TO LLVM WITHOUT WHITESPACE>" /M
Make sure that the variable is registered by using echo command
echo %LLVM_SYS_130_PREFIX%
It should output your registered path, not %LLVM_SYS_130_PREFIX%.
If it doesn’t output your path, restart the computer and try again and it should be working.
Now you should be good to go .....
Hope this helps :)
I'm trying to execute a .sh script (that wasn't written by me) and I get the following error:
0 [main] echo (5320) C:\Program Files\Git\usr\bin\echo.exe: *** fatal error - cygheap base mismatch detected - 0x180343408/0x180317408.
This problem is probably due to using incompatible versions of the cygwin DLL.
Search for cygwin1.dll using the Windows Start->Find/Search facility
and delete all but the most recent version. The most recent version should
reside in x:\cygwin\bin, where 'x' is the drive on which you have
installed the cygwin distribution. Rebooting is also suggested if you
are unable to find another cygwin DLL.
I tried to follow the instructions in the error but I only have one cygwin1.dll file.
So I tried to execute the following command in a git bash shell:
/c/cygwin/bin/man
and I get:
0 [main] man (11952) C:\cygwin\bin\man.exe: *** fatal error - cygheap
base mismatch detected - 0x180317408/0x180343408. This problem is
probably due to using incompatible versions of the cygwin DLL. Search
for cygwin1.dll using the Windows Start->Find/Search facility and
delete all but the most recent version. The most recent version
should reside in x:\cygwin\bin, where 'x' is the drive on which you have installed the cygwin distribution. Rebooting is also suggested
I already tried to disable ASRL options in the exploit protection panel (as suggested by somebody) and reboot but that didn't fix the problem.
If I write
which -a cygwin1.dll
I get:
/c/cygwin/bin/cygwin1.dll
/c/cygwin/bin/cygwin1.dll
It looks like I have two cygwin1.dll but actually I only have one..
I have been searching for a possible solution since days but nothing seems to work for me.
Any suggestion?
While the error message is mentioning cygwin1.dll, it is misleading as the Git for Windows is using MSYS and the file was renamed msys-2.0.dll
Unfortunately the MSYS team forgot to change the error messages when they imported and modified the Cygwin source:
I encountered the same problem while trying to build a certain C/C++ project from source in the Git Bash Terminal.
Based on the previous answers by #Harry and #matzeri it seems that Git Bash is what is causing this problem. To resolve it I had to disable ASLR for all executables in my Cygwin install folder (Usuall C:\cygwin64) using the command
Get-Item -Path "C:\cygwin64\bin\*.exe" | %{ Set-ProcessMitigation -Name $_.Name -Disable ForceRelocateImages }
I restarted the computer and then switched to using Cygwin Terminal and compiled from there.
NB: Cygwin Terminal comes by default with Cygwin installation
Find all the msys-2.0.dll's on your machine and add the suffix .bkp to them.
Wherever you found them at, copy "C:\Program Files\Git\usr\bin\msys-2.0.dll" to those locations.
Notes:
If you were to copy from C:\msys64\usr\bin\msys-2.0.dll to all other locations, then you lose that nice additional text at the end that shows the branch you're on (master)
Same goes if you just decide to delete all the extra dlls and just add C:\msys64\usr\bin to your path, there must be a dependencies it looks for relative to the directory it normally resides.
Because apparently I skimmed the selected answer and missed the part about msys-2.0.dll, I had to figure this out myself. For future reference:
Run listdlls -r -v -d msys-2.0.dll
Check Base, Path, and Version info for discrepancies.
I have recently moved from Window 7 to Windows 10 and I cannot get my makefiles to work anymore.
I have been using the GNU Make for Windows
The first thing that I noticed was that it had started treating Windows folder dividers (backslash characters '\') as line continuation characters, so I modified the 'clean' section as shown below to use forward slash '/' characters instead:
clean:
del $(ObjDir)/*.o
When I call make -ftest.mak clean I get the following error which suggests it is now trying to run in a MinGw/Cygwin environment:
c:\Test\Source>make -ftest.mak clean
del obj/*.o
/usr/bin/sh: del: command not found
make: *** [clean] Error 127
I do have MinGw folder on my PC (which I have renamed to stop make looking for it) and I can't see any 'MingGw' related environment variables in my Cmd.exe environment or PATH
How can I get make working so it doesn't try executing sh under Windows?
Is there some configuration parameter somewhere that makes it call sh instead of cmd.exe?
Update: Just tried running make -d which logs debug output. It looks as though it is using my Git folder as some sort of root folder:
Must remake target `clean'.
del obj/*.o
CreateProcess(NULL,C:/Program Files/Git/usr/bin/sh.exe -c "del obj/*.o",...)
Putting child 0x006e7fc0 (clean) PID 7234712 on the chain.
The cleanest way is to specify SHELL on command line.
make -ftest.mak clean SHELL=cmd
will do the job. ndk-build will do that for you, see your ndk-build.cmd. Don't try to run ndk-build bash script on Windows. The scripts in NDK may go amoc when you run them on Windows in bash.
Nasty conclusion to this problem.
make looks through the PATH environment variable for anything containing usr/bin. It just so happens that since I also installed Git on my Windows 10 PC, Git added the following folder to PATH:
C:\Program Files\Git\usr\bin
Adding any path with the substring "usr\bin" will cause make to try running sh instead of cmd.exe on Windows.
My solution: Remove the C:\Program Files\Git\usr\bin from my PATH.
Update: I changed the name from usr\bin to user\bin but make still finds sh.exe within that folder. In the end I renamed sh.exe to _sh.exe within the Git\usr\bin folder.
I have working Eclipse (Kepler Service Release 2) + EclipseFP (2.6.0) + Haskell Platform under Windows 8.1 x64.
In one moment after some cabal install, EclipseFP stopped working and showing me:
The program ghc version >=6.4 is required but it could not be found.
I have:
Uninstalled Haskell Platform
Deleted C:\Users\myuser\AppData\Roaming\cabal*
Deleted C:\Program Files (x86)\Haskell*
Install Haskell Platform 2013.2
Run Eclipse with my Haskell workspace
Try to build my project
It gave me this error about ghc and cannot build it.
EclipseFP configuration found all Haskell Helper executables. It found Cabal 1.16.0.2 and GHC 7.6.3 already. From command-line GHC and cabal are found and are working. "cabal build" is working on the project from command-line, too.
This message doesn't say almost anything! If I could see the path it is searching for GHC or where it get this path from...
EDIT:
Message from buildwrapper:
"C:\Users\home\AppData\Roaming\cabal\bin\buildwrapper.exe synchronize --force=false --tempfolder=.dist-buildwrapper --cabalpath=C:\Program Files (x86)\Haskell Platform\2013.2.0.0\lib\extralibs\bin\cabal.exe --cabalfile=D:\Project\haskell2\SomeGL\SomeGL.cabal --cabalflags= --logcabal=true
configuring because setup_config not present
"C:\Program Files (x86)\Haskell Platform\2013.2.0.0\lib\extralibs\bin\cabal.exe" "configure" "--verbose=1" "--user" "--enable-tests" "--enable-benchmarks" "--builddir=D:\Project\haskell2\SomeGL.dist-buildwrapper\dist"
cabal.exe: The program ghc version >=6.4 is required but it could not be found."
Calling exactly the last line from cmd.exe (as normal non-admin user) everything is working fine:
"C:\Program Files (x86)\Haskell Platform\2013.2.0.0\lib\extralibs\bin\cabal.exe" "configure" "--verbose=1" "--user" "--enable-tests" "--enable-benchmarks" "--builddir=D:\Project\haskell2\SomeGL\.dist-buildwrapper\dist"
EDIT:
To find the potential path environement that is used I tried to run GHCi console inside Eclipse and tried:
import System.Environment
x <- getEnvironment
filter (\ (a,_) -> a == "Path") x
and got something that is starting with:
[("Path","C:\Program Files (x86)\Haskell\bin;C:\Program Files
(x86)\Haskell Platform\2013.2.0.0\lib\extralibs\bin;C:\Program
Files (x86)\Haskell Platform\2013.2.0.0\bin;...")]
First folder is invalid, but Haskell Platform is valid and working.
Another thing I found. One of times I have run "Build All" command there was run Process in Eclipse with GHC and the path was:
Running executable C:\Program Files (x86)\Haskell
Platform\2013.2.0.0\bin\ghc.exe
I went to see this process details and it is run from the same user that is currently Eclipse run with. And the path is correct, but I still got the error:
The program ghc version >=6.4 is required but it could not be found.
Running from command-line still it is working. The program has errors, but only in command-line I see them.
Could someone help with finding this problem?
EDIT:
I found some interesting issue. Running "Build All" command is executing this command:
C:\Users\myuser\AppData\Roaming\cabal\bin\buildwrapper.exe synchronize
--force=false --tempfolder=.dist-buildwrapper --cabalpath=C:\Program Files (x86)\Haskell Platform\2013.2.0.0\lib\extralibs\bin\cabal.exe
--cabalfile=D:\haskell\SomeGL\SomeGL.cabal --cabalflags= --logcabal=true
Which run from command-line gives an error. The problem is that there are no quotes around cabalpath, because it has spaces in it. When I run it that way from command-line it works:
C:\Users\myuser\AppData\Roaming\cabal\bin\buildwrapper.exe synchronize --force=false --tempfolder=.dist-buildwrapper --cabalpath="C:\Program Files (x86)\Haskell Platform\2013.2.0.0\lib\extralibs\bin\cabal.exe" --cabalfile=D:\haskell\SomeGL\SomeGL.cabal --cabalflags= --logcabal=true
I think that all "--cabalfile" parameters should have quotes, because paths could have spaces in them. I still don't know if this is the problem under Eclipse.
I found the problem!
It is that EclipseFP 2.6.0 is using upper case "PATH" variable, but my Windows 8.1 use "Path" and programatically some kind it is possible to have valid two variables "PATH" and "Path" when executing BuildWrapper and Cabal. So something is messing up.
Workaround for this problem is if you rename from Control Panel | System | Environment variables for both User and System from "Path" to "PATH".
I hope this could be fixed in EclipseFP so it could in future work in any case.
Building your project means that under the scenes, cabal build is launched. If you activate the debugging mode in the Haskell helper executable preference page (show BuildWrapper responses), you should see the exact cabal build command being sent. It could be that the path used in Eclipse is different than the path used in the command line, check you eclipse shortcuts. EclipseFP can find the executables because it searches also in some well known folders on windows.
You can also take the current dev version of EclipseFP from github. It should now pass --with-ghc to cabal invocations to make sure the path detected in Eclipse is the one used.
After wrestling with my environment variables to get the proper directory set, I can now get the version with:
C:\Projects\TestProj>ant -version
Apache Ant(TM) version 1.8.4 compiled on May 22 2012
Ant appears to be working:
C:\Projects\TestProj>ant
Buildfile: build.xml does not exist!
Build failed
I still get the error when I try:
C:\Projects\TestProj>cordova -d platform add android
cordova library for "android" already exists. No need to download. Continuing.
Checking if platform "android" passes minimum requirements...
Creating android project...
Running command: C:\Users\Administrator\.cordova\lib\android\cordova\3.4.0\bin\c
reate.bat --cli C:\Projects\TestProj\platforms\android com.company.testproj
TestProj
C:\Users\Administrator\.cordova\lib\android\cordova\3.4.0\bin\node_modules\q\q.j
s:126
throw e;
^
Error: ERROR : executing command 'ant', make sure you have ant installed and add
ed to your path.
From all of the posts that I have read, this is an issue with ANT_HOME, but it appears I have that part of it tackled. Edit I've installed ant 1.9.3 to program files, and bin resides in:
EDIT Changed to just ant, instead of apache-ant-1.9.3-bin\apache-ant-1.9.3
C:\Program Files\ant
Echo home:
C:\Projects\TestProj>echo %ANT_HOME%
C:\Program Files\ant
And of course I have %ANT_HOME%\bin in my path. Any help identifying the issue would be appreciated.
I think the path you use for ANT_HOME is wrong. C:\Users\Administrator\AppData\Roaming\npm\node_modules\ant\ant seems to be the path to the ant npm module but not the ant command.
Ant command more probably is somewhere in program files. In a cmd, run where ant to know where in your path ant is found and use this path for ANT_HOME. (in the folder you should see ant, ant.cmd and ant.bat)
After further investigation, I think your problem is caused half by cordova not correctly checking node errors and half because of registry setting in your computer (a cmd autorun parameter).
You can check answers in those posts for more info:
nodejs child_process exec 'java -version'
Windows CMD.exe "The system cannot find the path specified."
Check if you have a registry key HKCU\Software\Microsoft\Command Processor\AutoRun
after setting the variables, restart your machine. Closing command prompt etc will not help.
Even I was stuck for quite a long time and next day when I started my system, it was working fine :P