I have this test code :
require 'mkmf'
puts have_header("iostream.h")
this code throws an error in Jruby like this :
checking for iostream.h... RuntimeError: The compiler failed to generate an executable file. You have to install development tools first.
try_do at /home/abd/.rvm/rubies/jruby-9.1.6.0/lib/ruby/stdlib/mkmf.rb:456
try_cpp at /home/abd/.rvm/rubies/jruby-9.1.6.0/lib/ruby/stdlib/mkmf.rb:587
block in have_header at
/home/abd/.rvm/rubies/jruby-9.1.6.0/lib/ruby/stdlib/mkmf.rb:1091
block in checking_for at
/home/abd/.rvm/rubies/jruby-9.1.6.0/lib/ruby/stdlib/mkmf.rb:942
block in postpone at /home/abd/.rvm/rubies/jruby-9.1.6.0/lib/ruby/stdlib/mkmf.rb:350
open at /home/abd/.rvm/rubies/jruby-9.1.6.0/lib/ruby/stdlib/mkmf.rb:320
block in postpone at /home/abd/.rvm/rubies/jruby-9.1.6.0/lib/ruby/stdlib/mkmf.rb:350
open at /home/abd/.rvm/rubies/jruby-9.1.6.0/lib/ruby/stdlib/mkmf.rb:320
postpone at /home/abd/.rvm/rubies/jruby-9.1.6.0/lib/ruby/stdlib/mkmf.rb:346
checking_for at /home/abd/.rvm/rubies/jruby-9.1.6.0/lib/ruby/stdlib/mkmf.rb:941
have_header at /home/abd/.rvm/rubies/jruby-9.1.6.0/lib/ruby/stdlib/mkmf.rb:1090
at test.rb:3
I have no idea what does it mean by development tools and I searched the internet without finding anything about this.
I installed Jruby 9.1.6.0 through rvm, this is my java version :
[abd#abd testruby]$ java -version
openjdk version "1.8.0_112"
OpenJDK Runtime Environment (build 1.8.0_112-b15)
OpenJDK 64-Bit Server VM (build 25.112-b15, mixed mode)
I'm using Arch linux here.
The real reason behind my question is that I tried installing gmp gem and native extensions wouldn't build because of the same error, I know the gem is unmaintained but I want to resolve this issue anyway because the above message suggests that my installation is lacking.
By the way I have the jdk, not just the jre.
JRuby C extensions have been deprecated [and possibly removed already but I'm a bit out of the loop].
Since you're running on the JVM, have you considered the alternatives? i.e. either use Java's BigInteger or BigDecimal if the performance is adequate for your needs, or wrap GMP using JNI / JNA- it looks like somebody has tried already. Check out this SO question for a few more Java alternatives.
Related
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 created an NPAPI plugin that I'm packaging within a Chrome extension. I'm able to successfully install and use the extension in Chrome on Windows 2003 and Windows XP 64-bit.
However, when I install the plugin on Windows 7 (either 32-bit or 64-bit) or Windows XP 32-bit, I'm unable to use the extension within Chrome. The chrome logs reveal the error message "Couldn't initialize plug-in".
I ran the dependency walker in all of my environments and it looks like in the environments where the extension doesn't work, they all have in common the warning message "Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module." (the DLL's in question are SHLWAPI.DLL, IEFRAME.DLL, and MPR.DLL) whereas the environments where the extension does work don't have this warning (although one of them does warn of a delay-load dependency module not being found).
Should these DLL dependencies be different across different versions of Windows? What's the best way to resolve them? Or is the plugin failure most likely not related to these DLL dependencies?
Rebuild your project without dependencies on the runtime libraries by compiling your binaries with the "/MT" compiler flag instead of the default "/MD".
If you depend on open source code, make sure to rebuild each of those projects with the "/MT" flag, otherwise you will be chasing these runtime DLL issues forever.
shlwapi and ieframe are probably unrelated to your issue; seeing those errors is a common issue. not sure about mpr.dll, haven't seen that one.
You might try a FireBreath plugin and compare the dependency walker results and see if you can spot anything you're requiring that firebreath doesn't, since firebreath has no external DLL dependencies.
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.
So, I have rvm installed on my machine, and I type:
rvm install jruby
Everything looks good at first, but eventually I get:
jruby-1.5.6 - #fetching
jruby-1.5.6 - #extracted to /home/jenny/.rvm/src/jruby-1.5.6 (already extracted)
Building Nailgun
jruby-1.5.6 - #installing to /home/jenny/.rvm/rubies/jruby-1.5.6
jruby-1.5.6 - #importing default gemsets (/home/jenny/.rvm/gemsets/)
Copying across included gems
Exception in thread "main" java.lang.NoClassDefFoundError: org.jruby.Main
at gnu.java.lang.MainThread.run(libgcj.so.9)
Caused by: java.lang.ClassNotFoundException: org.jruby.Main not found in gnu.gcj.runtime.SystemClassLoader{urls=[file:./], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
at java.net.URLClassLoader.findClass(libgcj.so.9)
at gnu.gcj.runtime.SystemClassLoader.findClass(libgcj.so.9)
at java.lang.ClassLoader.loadClass(libgcj.so.9)
at java.lang.ClassLoader.loadClass(libgcj.so.9)
at gnu.java.lang.MainThread.run(libgcj.so.9)
jenny#linux-auvv:~/workspace/pcms_stable>
I have absolutly no context for debugging this... I honestly have no idea what to do...
I'm on OpenSuse, and when I type "java -version", I get:
java version "1.6.0_0"
OpenJDK Runtime Environment (build 1.6.0_0-b11)
OpenJDK Server VM (build 1.6.0_0-b11, mixed mode)
I can't see any references to java requirements for JRuby, though...
As far as RVM, I'm running:
rvm 1.2.4 by Wayne E. Seguin (wayneeseguin#gmail.com) [http://rvm.beginrescueend.com/]
I can install other rubies with RVM (1.9.2, 1.8.7, that sort of thing) with no problem, this is the first issue I've ever found.
It doesn't seem to matter WHICH jruby I install, either. My rvm knows about:
# JRuby
jruby-1.2.0
jruby-1.3.1
jruby-1.4.0
jruby[-1.5.6]
jruby-head
I don't even get the same errors for each one of them:
For 1.2.0, 1.3.1, 1.4.0 I get:
Fatal: GCJ (GNU Compiler for Java) is not supported by JRuby.
Where 1.5.6 and head get me the error I mentioned first.
I WANT to use JRuby with Rails 3, so I'm figuring I want the newest version I can get (which is having the exceptions)
Is there ANYTHING I can do, or am I just doomed to not be able to use RVM for my purposes?
EDIT:
I have confirmed that it's not just RVM, it is JRuby that is to blame. To test, I downloaded JRuby without rvm at all, through the website (I chose version 1.6). I unpacked it as per the instructions, and typed:
bin/jruby -v
in the extracted directory.
I got the exact same error:
jenny#linux-auvv:~/jruby-1.6.0.RC1> bin/jruby -v
Exception in thread "main" java.lang.NoClassDefFoundError: org.jruby.Main
at gnu.java.lang.MainThread.run(libgcj.so.9)
Caused by: java.lang.ClassNotFoundException: org.jruby.Main not found in gnu.gcj.runtime.SystemClassLoader{urls=[file:./], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
at java.net.URLClassLoader.findClass(libgcj.so.9)
at gnu.gcj.runtime.SystemClassLoader.findClass(libgcj.so.9)
at java.lang.ClassLoader.loadClass(libgcj.so.9)
at java.lang.ClassLoader.loadClass(libgcj.so.9)
at gnu.java.lang.MainThread.run(libgcj.so.9)
So, still have no clue what's going on, but at least I know now it's a jruby issue, and not an rvm one (though I still WANT it installed through rvm)
Edit:
So, I tried updating my OpenJDK, and it was no dice, but I found ANOTHER version of OpenJDK (that I didn't have installed) through YAST, and installed THAT one, and suddenly my manually installed jruby works just fine:
jenny#linux-auvv:~/jruby-1.6.0.RC1> bin/jruby -v
jruby 1.6.0.RC1 (ruby 1.8.7 patchlevel 330) (2011-01-10 769f847) (OpenJDK Client VM 1.6.0_0) [linux-i386-java]
When I type java -version, I even get something different:
jenny#linux-auvv:~/jruby-1.6.0.RC1> java -version
java version "1.6.0_0"
OpenJDK Runtime Environment (IcedTea6 1.6.2) (suse-0.1.1-i386)
OpenJDK Server VM (build 14.0-b16, mixed mode)
It even works in RVM, so hooray!
I would try installing the Sun JRE/JDK.
Or perhaps you could reinstall OpenJDK(probably the easiest way to reset it to being the default on your system).
Update:
To change the default java do this. First check which Javas are available:
update-alternatives --list java
To actually change which one you are using do this:
update-alternatives --config java
I think the clue is in this:
Fatal: GCJ (GNU Compiler for Java) is not supported by JRuby.
For whatever reason, your system is configured to fire up GCJ instead of your OpenJDK compiler. Check the docs on your system for how it handles the case where multiple things can provide the same service name (multiple versions of compilers, for example, or multiple interpreters) and see what you can do to have OpenJDK be the default handler for Java compilation and execution.