When I try to configure my Hudson job to use polling against my Sourcesafe repository, I get the following error :
com4j.dll: Can't load IA 32-bit .dll on a AMD 64-bit platform
How can I resolve this?
Source: credit to Allen at hudson-ci.org
What's happening here is that Hudson is trying to use the 32-bit dll from a 64-bit Java process.
To resolve this, simply either configure Hudson to run exclusively using a 32-bit version of the JRE, or just uninstall your 64-bit java runtime and replace it with a 32-bit runtime (don't forget to update your %PATH% values pointing to the JRE!).
Once this is done, the error should be resolved.
Related
I downloaded eclipse-juno, and run it. It was giving error as " A Java Runtime Environment (JRE) or Java Development Kit (JDK) must be available in order to run Eclipse. No Java virtual machine was found after searching the following locations:
C:\Program Files\eclipse\jre\bin\javaw.exe javaw.exe in your current PATH "
Then I set environment variables as told in this post
Eclipse - no Java (JRE) / (JDK) … no virtual machine.
Now its giving error
Failed to load the JNI shered library "C\Program Files\Java\Jdk version\bin\...\jre\bin\client\jvm.dll"
First of all make sure your Java and Eclipse have the same architecture - they both have to be either 32-bit or 64-bit. If that checks out, it should be OK.
I had the same problem: in my case everything was in fact 64-bit - 64-bit OS, 64-bit Eclipse and 64-bit JRE in use, so there was some confusion as to the origins of the issue...
What helped was correcting environmental variables JAVA_HOME and PATH - and pointing them directly to the bin catalogue:
.../My/Java/Location/bin
instead of
.../My/Java/Location
Possibly you have installed wrong BIT version of Java on your machine. If your machine is 64 bit, you might have installed 32 bit java only. You can able to view whats your machine architecture by right clicking on computer and say properties.
If your machine is 64 bit machine. Install 64 bit Java, 64 bit Eclipse. Make sure your classpath is set
Hope this will help.
You can test this solution, maybe works: go to window->preference->server->runtime environments->and set your server path Example: tomcat path.
for set java invironment variable and classpath:try like this:
and in path section:
check this link:link
I use ActiveStates TCL version 8.6.0.0 for Windows x64.
In a script I call:
package require tcom
Tcom is included in the installation but I get the following error:
couldn't load libary "C:/TCL/lib/tcom/tcom.dll": Invalid argument while executing
"load C:/TCL/lib/tcom/tcom.dll"
("package ifneeded tcom 3.9" script)
invoked from within
"package require tcom"
Does anyone understand whats actually missing? C:/TCL/lib/tcom/tcom.dll is installed on my system, so what is the "invalid argument" ?
This appears to be a 32-bit/64-bit issue. You can't mix different bit-sizes within the same process† and you may well have installed a 64-bit build of ActiveTcl 8.6.0.0 under the belief that matching the size of the build and the system architecture is a good idea. Alas, this is not the case. ActiveTcl 8.6.0.0 for 64-bit Windows, for commercial reasons‡, requires an extra product key to access their 64-bit builds of external packages. But you've got the package installed anyway (perhaps from a previous installation of ActiveTcl?) and that appears to be a 32-bit build.
The misleading error from using the wrong size of binary library build is unfortunate (a relatively minor bug stemming from the subtle differences between Windows and POSIX and how Tcl handles the mapping between the two) but I'd bet that's it.
The easiest fix is to:
Uninstall all copies of ActiveTcl that you've got installed, then
Ensure that your C:\Tcl directory really is deleted, and then
Install the 32-bit build of ActiveTcl 8.6.0.0 (which works just fine on Win64-based systems like 64-bit Windows 7 and Windows 8). Once you've done that, you
Use teacup update to get a full set of packages installed and you should get Tcom working.
†Except on ARM with extra trickiness, which doesn't apply here.
‡I'm not going to try to justify them; it's their decision, not mine.
I get the following error when I try to build my first GPU Program. Any suggestions what might be going wrong?
Error 1 error MSB4062: The "Nvda.Build.CudaTasks.SanitizePaths" task
could not be loaded from the assembly C:\Program
Files\MSBuild\Microsoft.Cpp\v4.0\BuildCustomizations\Nvda.Build.CudaTasks.dll.
Could not load file or assembly 'file:///C:\Program
Files\MSBuild\Microsoft.Cpp\v4.0\BuildCustomizations\Nvda.Build.CudaTasks.dll'
or one of its dependencies. The system cannot find the file specified.
Confirm that the declaration is correct, that the assembly
and all its dependencies are available, and that the task contains a
public class that implements
Microsoft.Build.Framework.ITask. C:\Program
Files\MSBuild\Microsoft.Cpp\v4.0\BuildCustomizations\CUDA
3.2.targets 70 4 gpu
I have faced with this problem. So many searching on internet but I could not find anything. At last I recognize that I closed Microsoft .NET Framework 3.5.1 features on Windows Features section in Control Panel.
to turn on Microsoft .Net Framework 3.5.1, you can easily follow these instructions;
http://www.sevenforums.com/tutorials/5023-windows-features-turn-off.html.
I hope this solution will help you !
I've come across this problem after upgrading my system to windows 10. It turns out that I have to reinstall Visual Studio because some dependent dlls have been moved to Windows.old folder.
I had this same error when I was compiling on a remote server. I think it was because I was logged in using Remote Desktop (RDP). When I logged in using VNC and compiled, the error no longer happened.
Note that it's impossible to even install the CUDA Toolkit via RDP, so this is unlikely to happen, unless you regularly use both methods to connect to a server.
I compiled MySQL++ with no issues. When I launched some of the executables (resetdb.exe and simple1.exe) they suggest to run to test if the installation has been successful, the first error I got was that libmysql.dll was missing.
Adding its path to the PATH environment variable did not fix the problem, even after launching a new command prompt; I had to copy the DLL in the directory where MySQL++ executables are.
Now the DLL is found, but I get this error:
simple1.exe - Application error
The application was unable to start correctly (0xc000007b).
Click OK to close the application.
even launching from the command line, I get no more information than these.
Thank you for any help!
MySQL 5.5 -
MySQL++ 3.0.9 -
Windows 7 64 bits -
MINGW32 -
GCC 4.4.0
0xC000007B is a Windows error that means the executable is corrupted. It could refer either to simple1.exe or to one of the DLLs it's linking against.
Some reasons this could happen:
You're mixing toolchains in an incompatible way. In your case, you may have built simple1.exe using pieces built by MinGW GCC and pieces built by Visual C++. MinGW should be compatible with any pure C DLL built by Visual C++, including the MySQL C API DLL. However, you may have other pieces interfering. MinGW isn't compatible with VC++ at the C++ level, but then, it shouldn't have linked at all if this were your problem.
You didn't follow the MySQL C API import library build steps in README-MinGW.txt. You either missed a step, or skipped it entirely and are trying to use the import library that shipped with MySQL.
In your previous gyrations, you ended up with a corrupt object file, which got linked in. Try saying make clean all at the top level of MySQL++ to force a complete rebuild.
You're mixing versions of MySQL or MySQL++. If you have more than one version of each on the system, make sure you're consistent in their use. That is, build the C API import library from the same DLL you run the programs against, use exrun.bat to run the examples to ensure you're using the just-built version of the MySQL++ DLL instead of another you have in your PATH, etc.
Additionally, I note that you're using an older version of MySQL++. If you were on Linux, I could understand that as some distributions still ship with 3.0.9. But since you have to build MySQL++ from source with MinGW, I don't see why you're not using 3.1.0. Did you get a binary build from somewhere?
As for your PATH problem, did you restart the MinGW shell after doing this? PATH updates don't affect running programs; they keep the value they saw when they started.
I'm creating installer using InstallShield 2010 (basic MSI) that is having two features.
First feature consists of:
main .NET application compiled as x86,
some native x86 third party dlls which are used by main application (x64 versions are unavailable).
Second feature contains single component which is an extension for MS Reporting Services compiled as AnyCPU.
During UI sequence I'm using InstallScript custom action to enumerate all available Reporting Services instances from both x86 and x64 registry trees.
The user is prompted to select on which instance he wants to deploy our extension.
Based on selected instance I'm quering registry for actual location of Reporting Services in file system which is usually something like "C:\Program Files\Microsoft SQL Server\MSSQL.2\Reporting Services" and storing this value in a MSI Property.
Then by using Set Directory action I'm setting destination directory of a component (our extension) to the value of that MSI Property.
Everything is installing perfectly fine unless you've trying to install it for x64 Reporting Services in that case extension files are installed to wrong location. Even thou MSI Property is set to correct path "C:\Program Files\MicroSoft..." (I've checked msi log) it looks like system is automatically redirecting to "Program Files (x86)".
Is there any possible solution to overcome this issue?
If you need to install to the 64-bit ProgramFiles folder, use a 64-bit MSI.
Finally solved this issue myself without creating 64bit MSI by using InstallScript custom actions.
First custom action to install:
Manually copy required files to desired location (InstallScript can access x64 Program Files)
Save this location in registry as a key component for this feature to use during uninstall
Second custom action to uninstall:
Read installed location from registry (do not use System Search to get this value due to it'll be auto translated by WindowsInstaller to "ProgramFiles (x86)")
Delete files
You can change the INSTALLDIR property to ProgramFile64 rather then ProgramFiles, this will help you to install on desired path, since you application is 32-bit so the path will be C:\ProgramFiles(x86)\Your Company Name\Your Product Name along with this have you made your components as 64-bit compatible?