I have a system running 64bit windows 7. I'm doing a project using JMF, which I found works best (or only) with 32 bit jdk. I'm using a 32bit eclipse. I also have a 64bit JDK installed. right now I have set classpath (JAVA_HOME and Path) for the 32bit JDK.
The problem is it becomes hectic to switch between the 64bit and 32 bit JDK(i have to change classpaths everytime). Is there any easier way to do that?
You can have multiple JREs registered with Eclipse, and associate a project or run configuration with a specific JRE. These are different from the JRE you use to run Eclipse in.
Eclipse doesn't need to depend on JAVA_HOME or PATH. You can specify the JVM to be used to run Eclipse in the eclipse.ini file, and specify the path(s) to the target JVM(s) via the Eclipse preferences.
If you have to run both 32 and 64 bit Java from the command line, you should invest some time in writing shell scripts, aliases, etc.
You could write a script (to be executed using ".") that will switch the settings of PATH and JAVA_HOME.
I prefer the approach of writing simple wrapper scripts or aliases to automate the build or run steps for the software you are developing. You can embed local overrides of PATH and JAVA_HOME in these scripts.
I would suggest just keep one JDK installed on your machine.
If you are working with JMF and Eclipse 32 bit then uninstall 64bit JDK
As per Oracle.
To run 64 bit eclipse without change environment variable
Simply copy 64bit jre to your eclipse(64 bit) root folder and rename it as jre.
Related
I am aware that there are many post about this, but I honestly didn't understood any of it.
So, how do I install a kit for my Qt Creator (open source 5.7)?
I already downloaded and installed MSYS2.... don't know what to do with it.
I already downloaded and installed Qt64 - NG.... no clue what to do next.
I just want to be able to develop in Qt and chose betwen MinGW 32 and MinGW 64.
Thanks in advance!
EDIT: I also checked the wiki page. Most of the commands didn't worked. And I was told that it is outdated.
I know that your question is how do you install a kit for your Qt Creator, but first I think it's needed an introduction (Sorry for your eyes, English it's not my native language)
Introduction
The intention is to use the GCC compiler under Windows, what mean we need MinGW (Minimalist GNU for Windows).
MinGW only works for 32 bits, so we need the 64 bits forks, what means to use the MinGW-w64 or TDM-GCC flavors.
MinGW , GCC compiler for 32bits applications.
MinGW-w64 , GCC compiler for 32 and 64 bits applications.
TDM-GCC , GCC compiler for 32 and 64 bits applications.
With that we can create our applications/programs in Windows. In addition, we have other two different tools:
Qt Framework library, for create GUI's/Interfaces with multi-platform compatibility.
Qt Creator , an C/C++ editor, with additional editing tools for the Qt Framework.
About the binary compatibility chain
When we make an application, we've to follow the chain of libraries compiled with the same compiler version, the same way we've to follow the application binary interface (32 or 64 bits) for those libraries.
This means, if we want to compile an application for 32 and 64 bits with MinGW-w64 5.3, plus the Qt 5.7 Framework, we need:
MinGW-w64 5.3 (with flags 32 bits in the config) and the Qt 5.7 Framwork 32 bits build compiled under MinGW-w64 (MinGW-w64 version 5.3 or lower as long as they maintain binary code compatibility with our compiler).
MinGW-w64 5.3 (with flags 64 bits in the config) and the Qt 5.7 Framwork 64 bits build compiled under MinGW-w64 (MinGW-w64 version 5.3 or lower as long as they maintain binary code compatibility with our compiler).
Now come the weird thing. At Qt official webpage it's only available the 32bits builds for MinGW... I don't know why...
Here is when come the Qt64-NG project, a place where get the Qt Framework 64bits binary packages for MinGW-w64. Unfortunately the project is closed, so only are available until the Qt 5.5 Framework version.
I don't know other place where to get newer 64bits Qt binary packages for MinGW-w64 (Maybe the ones at MSYS2 project? I didn't tried yet). So, if one need it, at this moment must be compiled by oneself (This is for answer your opensource 5.7 comment).
Install and configuration
Now your question. How to install a kit for your Qt Creator. I'm going to answer for 64bit binaries because it's what I use (and latter you just need to do the same thing for 32bits)
For use Qt Creator with MinGW-w64, one just need:
Download Qt Creator and install it. My advice is to download the 4.1 (or upper version) snapshots if one is going to use CMake projects.
Download MinGW-w64 (posix-seh , or your choice flavor) + decompress in one folder.
That's all, with this we can create 32 and 64 bits applications.
By other way, in addition to the above steps, if one want to create applications using the Qt Framework library (a GUI/Interface for our applications), it's needed the binary package, this case 64 bit (The 32bit binary package is available at the Qt official page)
Download Qt64-NG (posix-seh , or your above choose flavor) + decompress in one folder.After that it's needed to execute the qtbinpatcher.exe included in that directory, just a double click.Note: If you change this directory to other path, execute again qtbinpatcher.
Here is where end the installation process. In my case, I have all under the same folder. Example:
D:\Programacion\mingw64_5.3.0rev0\
D:\Programacion\qt64-ng\qt-5.5.0-x64-mingw510r0-seh\
Now you just need to configure QtCreator, in this case:
Tools > Options > C++ , Compilers, Add > MinGW
In name put the compiler version, MinGW-5.3 x64 It's the name that will be shown in Kits
In Compiler path browse for the C++ compiler path, in this case D:\Programacion\mingw64_5.3.0rev0\bin\g++.exeTake note in ABI it's selected to use 64 bits flags in the compiler. That's why we put in name x64. For 32 bits, just duplicate and change the selection.
Tools > Options > C++ , Debuggers, Add
In Path browse to the debugger path, in this case D:\Programacion\mingw64_5.3.0rev0\bin\gdb.exe
In name put the name showed at version, GDB 7.10.1 in this case.It's the name that will be shown in Kits
And, if one want to create 64bits programs using Qt Framework, in addition to the above:
Tools > Options > C++ , Qt versions, Add, and select the qmake.exe placed at the qt64-ng bin directory.
In this case is, D:\Programacion\qt64-ng\qt-5.5.0-x64-mingw510r0-seh\bin\qmake.exe
In name put Qt %{Qt:Version} (qt-5.5.0-x64-mingw510r0-seh)It's the name that will be shown in Kits tab
Now you just need to specify the Kit:
Tools > Options > C++ , Kits, Add
In name MinGW-5.3 x64 (Qt-5.5)
In compiler select MinGW-5.3 x64
In debugger select GDB 7.10.1
In Qt Version select Qt 5.5.0 (qt-5.5.0-x64-mingw510r0-seh)
And in CMake goes the CMake path if one is going to use it (I use it with Ninja ).
Note: For install Ninja just copy ninja.exe to the mingw-w64\bin directory, and at the Kit, in Cmake generator push change to generator->ninja , and Extra generator->CodeBlocks. Ninja launch several make commands at same time, what decreases compilation times.
Long text for 1 minute of configuration. The Kit is what we select for compile the project, and one can have as many Kits as one wish (CompilerA x32 + Qt5.x , CompilerB x64 + Qt5.x , CompilerX x64 + Qt4.8, etc, etc).
Now, before to finish, an important thing. After we create a project (and the project it's open), at the Projects selector (Ctrl+5) we've to take care of the Build Environment variables.
Those are the variables that are going to be added at the command who launch our Runs/Builds for testing and debug.
In PATH it's needed to put the paths to MinGW-w64 and to Qt64-NG. And under my humble opinion, I recommend to put it in that order because of dll's. Following our example:
PATH D:\Programacion\mingw64_5.3.0rev0\bin;D:\Programacion\qt64-ng\qt-5.5.0-x64-mingw510r0-seh\bin;the_other_paths
At QtCreator snapshots branch I don't need to check it, it's done automatically
Most of the C/C++ editors works that way. To install editor, specify compiler&debugger path, and specify Build Environment variables for launch from the editor (overriding those environment variable that we've in Windows).
Note: I recommend to compile Qt Creator with 64 bits, due as happen with the Framework, for Windows it's only available in 32 bit at the official Qt website
Alternative way
By other side, we have:
MSYS2 , a Linux like tools environment.
There is all the same, just we download/install the packages with the pacman command, and are available the 32 and 64 bit versions. Those applications need to be launched from MSYS2 shell. It's not a binary compatibility thing but a paths matter.
The libraries available at MSYS2 project can be used in the first tool chain I described (due are build under MinGW-w64 also).
EDIT: Corrected namings, the last explanation, and added Ninja's url and installation note.
You should decide if you are going to use the MSYS2 ecosystem or not. If you want to use MSYS2, you should uninstall the Qt software that you downloaded separately to avoid confusion. For the rest of this answer, I'll assume you are using MSYS2.
You can install these MSYS2 packages using pacman:
mingw-w64-i686-qt
mingw-w64-i686-qt-creator
mingw-w64-x86_64-qt
mingw-w64-x86_64-qt-creator
Then open up a MinGW-w64 32-bit or 64-bit shell using the appropriate shortcut in your Start Menu, and run "qtcreator" at the command line.
You can also use other build systems to build your software. I have used CMake successfully for building Qt applications in MSYS2, instead of Qt Creator.
Directly launching from explorer will also work, unless you need to use qtcreator's Autotools plugin in which case launching it from an msys2 shell is necessary (so that various environment variables are set correctly).
This is my first attempt at making a Qt Application work on different systems.
I have opted for static linking method.I have already compiled the sources of Qt 5.5 and compiled my application with the static Qt. The executable is working fine on my computer.
My operating system is Ubuntu 15.04. But when I tried to run the same executable on Ubuntu 14.04 then I ran into trouble. The key details of the error message are given below.
libstdc++.so.6 cxxabi_1.3.8 not found
I did a standard Google search and realised it was because I had a newer version of it on my machine, the machine where I had created the executable. There were so many different approaches to handle this problem. One of the solutions I saw involved shipping your own copy of libstdc++.so with the executable. But when I tried to copy the .so file to a pen drive, there was a warning saying that the file system does not support such files.
My question is , what am I doing wrong ? Also if I wanted to make the executable target Ubuntu 10.04, what would be the correct procedure handling the backward compatibility issues. I know that one method would be to install the same OS on my machine and then create the executable , is there any other way?
libstd++ is backward compatible but not forward compatible, which means you can run a program with a newer version of libstdc++ than the one you compiled it with but not vice-versa. This is what you experienced.
One way to deal with this issue is using older OS versions as the build machine. When you for example use Ubuntu 14.04 LTS, you'll get this list of compatible target systems.
The build system you're using will probably limit available compilers. On Ubuntu 14.04 you get GCC 4.8, which is good for most C++11 and packages for clang 3.6 are available, which will give you full C++14 support.
Targeting Ubuntu 10.04 will be challenging if you do not want to use a stone age compiler.
The idea of shipping libstdc++ will not help you much because you'll run into the same problem with libc.
My development team recently was forced over to a remote development environment where we do not have full access to the servers. Before the change over we had a JAR that was running fine on Java 1.7 x64 along with JRE 7. When we moved over to the new server our JAR was running alright, but then one of the server admins "updated" our Java to an older version and uninstalled the one we were using. Don't ask me why, I don't know. I re-installed Java 1.7 and uninstalled 1.6 along with the JREs.
The following problem occurs at runtime, there are no build errors:
Registry key 'Software\JavaSoft\Java Runtime Environment\CurrentVersion'
has value '1.7', but '1.6' is required.
Error: could not find java.dll
Error: could not find Java SE Runtime Environment.
I've run the same JAR on my laptop with no issues. Both the server and my laptop have JDK 1.7 and JRE 7 in the respective %HOME% variables and system PATH. I've even reinstalled JRE 6 and placed it later in the system environment PATH variables with the same result.
I have also changed the registry back to look at 1.6 and it results in the following, which I looked up and it appears to be from having multiple Javas installed (leading back to my original problem):
Exception in thread "main" java.lang.UnsupportedClassVersionError: ... :
Unsupported major.minor version 51.0
I would appreciate any insight you all have as I have been looking over various forums but nothing seems to have exactly my problem. Also, this has happen on another server we are using as well. Thanks!
Update: No luck with recompiling the JAR to either 1.6 or 1.7 and matching the JDK. Also, why in the world would a newer version of Java break an older compiled version?
This happens when you somehow confused java itself. You are trying to run a java 6 VM where it found a JRE 7. It might show this problem even if you type in the command line just java or java -version in a misconfigured environment. The JAR is not the problem, except in the very unlikely case where the code in JAR is looking in the Windows Registry for that (which probably is not your case).
In my case, I had the java.exe, javaw.exe and javaws.exe from Java 6 in the Windows/System32 folder (don't know how it got to be there). The rest of the JDK and JRE where found in the PATH inside C:\Java\jdk_1.7.0\bin. Oops!
Just had the similar error when installing java 8 (jdk & jre) on a system already running Java 7.
Error: Registry key 'Software\JavaSoft\Java Runtime
Environment'\CurrentVersion' has value '1.8', but '1.7' is required.
Error: could not find java.dll Error: Could not find Java SE Runtime Environment.
My environment was set up correctly (Path & java_home correctly defined), but the problem arises from the way pre-8 Java installers worked, which is that they used to copy the three executables (java.exe, javaw.exe & javaws.exe) to the Windows system directory. These remain unless overwritten by a new pre-8 installation.
However the Java 8 installer instead creates symbolic links in a new directory, C:\ProgramData\Oracle\Java\javapath, pointing to the actual JRE 8 location.
This means that you'll actually run the old 7 exes but use the new 8 DLLs.
So, the solution is simply to delete the 3 Java exes, as above, from the windows system directory.
If you are running 32-bit Java on a 64-bit Windows, the exes would be in Windows\SysWOW64, otherwise in Windows\System32.
I've deleted java files at windows/system32 and I also have removed c:\ProgramData\Oracle\Java\javapath from the PATH variable, because there was 3 symlinks to java 1.8 files.
I had JDK 1.7 in the %JAVA_HOME% variable and java1.7/bin in the PATH.
PS1: My problem was between Java 1.7 and Java 1.8.
PS2: I can't add this as a comment to Victor's answer because I haven't enough points.
In the START menu type "regedit" to open the Registry editor
Go to "HKEY_LOCAL_MACHINE" on the left-hand side registry explorer/tree menu
Click "SOFTWARE" within the "HKEY_LOCAL_MACHINE" registries
Click "JavaSoft" within the "SOFTWARE" registries
Click "Java Runtime Environment" within the "JavaSoft" list of registries here you can see different versions of installed java
Click "Java Runtime Environment"- On right hand side you will get 4-5 rows . Please select "CurrentVersion" and right Click( select modify option) Change version to "1.7"
Now the magic has been completed
I don't know if anyone is still following this thread, but I recently had this issue when I tried to launch ActiveMQ 5.10 as a Windows service.
I didn't have a JAVA_HOME path set.
I had Java 6 and Java 7 installed, but the default version was v7. (ie if I opened a command window and types "java -version").
This is where the clue was - "java -version" returned "Java HotSpot(TM) 64-Bit Server VM (build 23.1-b03, mixed mode)" but I was had installed the Win32 service...
It turns out that if you use the Win32 wrapper on a 64-bit machine it somehow decides to use a different version of Java...
So my fix was to uninstall the 32-bit version of the wrapper and install the 64-bit version.
aversion on my machine; just habit I guess... But luckily I resolved the issue eventually...
For my Win7
Paradox was in being java.exe and javaw.exe in System32 folder.
Opening that folder I couldn't see them but using search in Start menu I get links to those files, removed them. Next searsh gave me links to files from JAVA_HOME
magic )
Change to directory with correct java.exe i.e. go to the required JDK version java.exe
cd C:/Program Files/Java/jdk1.7.0_25/bin
Run the java.exe from this directory, it has precedence over registry and $PATH settings.
java -jar C:/installed/selenium-server-standalone-2.53.0.jar
I solved this problem by uninstalling Java 1.8
The jar was compiled to be 1.6 compliant. That is why you get this error. Two resolutions:
1) Use Java 1.6
OR
2) Recompile the jar to be compliant for your environment 1.7
Using regedit, remove the entries corresponding to java 7. It will work.
How can I set my java jar application to use jre 6 instead of jre 7?
I'm doing this because there are some compatibility issue with the libraries I'm using if the application use jre 7.
Edit:
The application will come with its own installers (using advanced installer) that have a jre6 installer. But I don't know how to trace the installation folder of the jre6.
How can I trace it and make the jar file use the jre6?
You can do this from Advanced Installer much simpler. You have two options:
Force the package to use the JRE 1.6 found on the machine by going to "Virtual Machine" tab from Java Products page and setting the minimum and maximum JRE versions to 1.6
Add as bundle in the project from the same page the JRE for version 1.6. This means that Advanced Installer will automatically import in your package the JRE resources required for your application, thus increases the package size, and will install them in the application's install folder. This JRE bundle will be used only by your application and removed along with it.
When running your application using java.exe, you could provide the absolute path to a Java 1.6 installation. Something like:
absolute_path_to_java6_dir/bin/java -jar yourRunnableJar.jar
or
absolute_path_to_java6_dir/bin/java -cp .;yourJar.jar;otherJarFiles className
You could check the running JVM version when starting your application.
System.getProperty("java.version");
This way you could provide a meaningful explanation to end-user.
We using Gallio for test execution. All projects under test and all test projects are compiled as 32bit Version. The Buildserver is Win2008 R2 64bit.
Gallio is installed as 32bit version.
Gallio is startet through Sonar. As coverageTool we use OpenCover.
As the title says the BadImageFormat Exception is the Problem. Then Trying to run, the .Net\Framework64\ folder is used. But all targets are set to 32bit architecture.
After two days of testing and researching I tryed different Gallio Versions:
32bit installer
64bit installer
Gallio Bundle Zip
I tried to rename the Gallio.Host.x86.exe to Gallio.Host.exe
I tried to force Gallio to run in 32bit mode via CorFlags Galio.Echo.exe /32BIT+ /FORCE
(Using /FORCE will invalidate the signature of this image and will require the assambly to be resigned)
Has anybody a Idea what I'am doing wrong?
Make sure you're running Sonar v3.0 (or greater), as most 64-bit issues were resolved with that release. I would also suggest moving to PartCover as your coverage tool. (Edit: PartCover is the way to go now)
Then Trying to run, the .Net\Framework64\ folder is used
What do you mean by "used"? Even if every executable is correctly marked and run as a 32-bit process, if one of them tries to load a binary in the Framework64 folder (all 64-bit binaries) a BadImageFormatException would be expected.
Try renaming both "Gallio.Host.Elevated.x86.exe", "Gallio.Host.x86.exe" to "Gallio.Host.Elevated.exe", "Gallio.Host.exe". That worked for me - running nunit tests (x86) with gallio