I've followed the steps on the Cygwin wiki for updating my version of gcc. Now I have two installations of gcc in Cygwin: 3.4 in /bin and 4.7 in /usr/local/bin. Now, in Eclipse the only way to use it seems to be changing the invocation command from g++ to C:/cygwin/usr/local/bin/g++, and this has to be done for all projects. Is there any way to make Eclipse CDT use this by default? I have changed the Path environment variable, and typing g++ --version in a command line gives 4.7, but building a project in Eclipse with --version still gives 3.4
Related
sbt fails with a cryptic error on issuing any command (compile, assembly, clean or any other).
$ sbt --version
error: error while loading String, class file '/modules/java.base/java/lang/String.class' is broken
(class java.lang.NullPointerException/null)
I am on a machine running macOS, and sbt was installed via homebrew. I have tried upgrading to the latest versions of sbt (1.3.10), but the error still persists.
The issue is documented on the SBT Download page.
Homebrew maintainers have added a dependency to JDK 13 because they want to use more brew dependencies (brew#50649). This causes sbt to use JDK 13 even when java available on PATH is JDK 8 or 11. To prevent sbt from running on JDK 13, install jEnv or switch to using SDKMAN.
I was able to resolve the problem by using JDK 8 via jEnv.
Since sbt documents JDK 8 and 11 as compatible versions
We recommend AdoptOpenJDK JDK 8 or AdoptOpenJDK JDK 11
try controlling which JDK is used by sbt via -java-home setting which can be configured system-wide via sbtopts run configuration
/usr/local/etc/sbtopts
or per-project basis via
<project-root>/.sbtopts
For example, to configure JDK used by sbt in current project, try setting in .sbtopts
-java-home /Users/picard/.sdkman/candidates/java/current
This is what solved my problem on my Mac.
brew uninstall sbt
Install sdkman
curl -s "https://get.sdkman.io" | bash
source "$HOME/.sdkman/bin/sdkman-init.sh"
Install sbt via sdk
sdk install sbt
I had the same issue recently. What worked for me is to install SDKMAN(https://sdkman.io/)
$ curl -s "https://get.sdkman.io" | bash
...
$ source "$HOME/.sdkman/bin/sdkman-init.sh"
...
After installation, I wanted to see what versions of Java I can install. So I simply run this command to list all the available versions of Java
sdk list java
Choose the version you want to install (recommend installing either 8 or 11 as mentioned above) and simply run the command with the identifier that specifies your version from the list
sdk install java 11.0.3.hs-adpt
After installation, it set the Java 11 to default on my system. I then ran the sbt command again and it worked.
If you are using SDKMAN then in some cases certain versions of Java (i.e. JDK) from different vendor might help.
E.g. I was using Amazon Correto JDK8 (version 8.332.08.1-amzn) and it could not properly build my sbt project in IntellIJ IDEA, so I've switched to using Zulu's JDK8 (version 8.0.332-zulu) as default java version.
Hope this helps and good luck. :)
For some reason it forces -G Ninja when I try to build within eclipse. I would prefer Eclipse just not specify the -G option to cmake, but I can't figure out how to configure Eclipse to do that.
For exampe, this in my console window:
Building in: /home/bgass/eclipse-workspace/scomlib/build/default
cmake -G Ninja -DCMAKE_BUILD_TYPE=Release -DCMAKE_EXPORT_COMPILE_COMMANDS=ON /home/bgass/eclipse-workspace/scomlib
CMake Error: Error: generator : Ninja
Does not match the generator used previously: Unix Makefiles
Either remove the CMakeCache.txt file or choose a different binary directory.
cmake --build . -- -v
GNU Make 4.2.1
Built for x86_64-redhat-linux-gnu
Copyright (C) 1988-2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Build complete (0 errors, 0 warnings): /home/bgass/eclipse-workspace/scomlib/build/default
In a terminal it works just fine without the generator specified.
cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_EXPORT_COMPILE_COMMANDS=ON /home/bgass/eclipse-workspace/scomlib
-- Configuring done
-- Generating done
-- Build files have been written to: /home/bgass/eclipse-workspace/scomlib/build/default
I always execute cmake outside eclipse and open the generated eclipse project in Eclipse.
use -G "Eclipse CDT4 - Unix Makefiles" to specify Eclipse as the generator.
Following are the full set of Eclipse generators.
Eclipse CDT4 - NMake Makefiles
= Generates Eclipse CDT 4.0 project files.
Eclipse CDT4 - MinGW Makefiles
= Generates Eclipse CDT 4.0 project files.
Eclipse CDT4 - Ninja = Generates Eclipse CDT 4.0 project files.
Eclipse CDT4 - Unix Makefiles= Generates Eclipse CDT 4.0 project files.
Type in cmake --help to see what generators are supported by your specific cmake version.
I am trying to use Eclipse CDT under Ubuntu 18.04 LTS.
I get the same error as many others, but I could not find a solution in what I read.
I try to launch with
$ eclipse &
OpenJDK 64-Bit Server VM warning: Ignoring option MaxPermSize; support was removed in 8.0
and I get
/home/user1/.eclipse/org.eclipse.platform_3.8_155965261/configuration/1551271296090.log
When checking /usr/lib/eclipse/configuration/config.ini (as per this) I found the following lines (among others)
osgi.framework=file\:plugins/org.eclipse.osgi_3.8.1.dist.jar
osgi.bundles=reference\:file\:org.eclipse.equinox.simpleconfigurator_1.0.301.dist.jar#1\:start
org.eclipse.equinox.simpleconfigurator.configUrl=file\:org.eclipse.equinox.simpleconfigurator/bundles.info
As for the first two lines, I have files
$ locate eclipse.osgi_
/usr/share/java/org.eclipse.osgi_3.8.1.dist.jar
$ locate simpleconfigurator_1
/usr/lib/eclipse/plugins/org.eclipse.equinox.simpleconfigurator_1.0.301.dist.jar
Nevertheless:
/usr/share/java/org.eclipse.osgi_3.8.1.dist.jar seems to belong to no package (a remnant of some old package?), since
$ apt-file search /usr/share/java/org.eclipse.osgi_3.8.1.dist.jar
gives no results.
I have ver 3.9.1
$ dpkg -l | grep libequinox-osgi-java
ii libequinox-osgi-java 3.9.1-1 all Equinox OSGi framework
$ dpkg -L libequinox-osgi-java
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/libequinox-osgi-java
/usr/share/doc/libequinox-osgi-java/changelog.Debian.gz
/usr/share/doc/libequinox-osgi-java/copyright
/usr/share/java
/usr/share/java/org.eclipse.osgi-3.9.1.jar
/usr/share/maven-repo
/usr/share/maven-repo/org
/usr/share/maven-repo/org/eclipse
/usr/share/maven-repo/org/eclipse/osgi
/usr/share/maven-repo/org/eclipse/osgi/org.eclipse.osgi
/usr/share/maven-repo/org/eclipse/osgi/org.eclipse.osgi/3.9.1
/usr/share/maven-repo/org/eclipse/osgi/org.eclipse.osgi/3.9.1/org.eclipse.osgi-3.9.1.pom
/usr/share/maven-repo/org/eclipse/osgi/org.eclipse.osgi/debian
/usr/share/maven-repo/org/eclipse/osgi/org.eclipse.osgi/debian/org.eclipse.osgi-debian.pom
/usr/share/java/org.eclipse.osgi.jar
/usr/share/maven-repo/org/eclipse/osgi/org.eclipse.osgi/3.9.1/org.eclipse.osgi-3.9.1.jar
/usr/share/maven-repo/org/eclipse/osgi/org.eclipse.osgi/debian/org.eclipse.osgi-debian.jar
So I do not know if the problem is here.
How can I solve this?
Could not find an answer here
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891956
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898086
https://bugs.launchpad.net/ubuntu/+source/eclipse/+bug/1754886
https://ubuntu.pkgs.org/16.04/ubuntu-universe-i386/libequinox-osgi-java_3.8.1-8_all.deb.html
https://askubuntu.com/questions/1031171/eclipse-doesnt-start-on-ubuntu-18-04
You are probably using an older Eclipse version that does not work with Java 9 or higher:
If using Java 9 or newer please use Eclipse 4.7.1a or newer as it contains fixes in Eclipse launcher to add all JVM modules.
Do one of the following to solve the problem:
Use Java 8 to run Eclipse (a JRE/JDK can be put in the subfolder jre of your Eclipse installation or be specified in the eclipse.ini file)
Upgrade Eclipse (recommended).
I'm getting a C++ compiler works....no error when compiling the CPP legacy driver.
I'm compiling with:
scons --64 --cxx=/usr/local/bin/gcc -cc=/usr/local/bin/gcc --prefix=/opt/mongo install
The config.log states:
libmpc.so.2 cannot open shared object file
libmpc.so.2 does exists in /usr/local/lib which is in LD_LIBRARY_PATH
When I execute the compilation command for conftest_o.cpp file, from the config.log it compiles with no issues.
~/.bashrc and ~/.bash_profile seems fine.
OS: RedHat 6.6 64bit
GCC: 4.9.2
mongodb CPP legacy driver version: 1.0.5
Boost : 1.57
Python: 2.6.6
scons: 2.3.6
Thanks for your help.
Update : solved the problem using
--propagate-shell-environment flag when running scons.
Apparently scons does not pass shell environment variables to child processes.
Thanks for your help
I am using 32-bit eclipse CDT Kelper to manage a piece of code, which I could compile on command line but not with eclipse if I use any up-to-date c++11 feature. CDT tells me that "-std=c++11" is unrecognized.
After turning on the verbose option in project properties\settings\tool settings, I found that eclipse CDT somehow chooses an older version of MinGW that comes with Haskell platform 2013.2:
Configured with: ../gcc-4.5.2/configure --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --disable-werror --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.5.2 (GCC)
COLLECT_GCC_OPTIONS='-O0' '-g3' '-Wall' '-c' '-fmessage-length=0' '-v' '-o' 'src\vaomp_bnb.o' '-shared-libgcc' '-mtune=i386' '-march=i386'
c:/haskell platform/2013.2.0.0/mingw/bin/../libexec/gcc/mingw32/4.5.2/cc1plus.exe -quiet -v -iprefix c:\haskell platform\2013.2.0.0\mingw\bin\../lib/gcc/mingw32/4.5.2/ -dD ..\src\vaomp_bnb.cpp -quiet -dumpbase vaomp_bnb.cpp -mtune=i386 -march=i386 -auxbase-strip src\vaomp_bnb.o -g3 -O0 -Wall -version -fmessage-length=0 -o C:\DOCUME~1\ting\LOCALS~1\Temp\ccWNoh7I.s
GNU C++ (GCC) version 4.5.2 (mingw32)
I searched SO, and there is a similar question a half year ago here. But the answer there was about setting environment variables and didn't solve the problem.
In my case, CDT can find a MinGW GCC, but found the wrong one. I have installed tdm-gcc 64 bit with gcc-4.8.1, and Haskell platform. The tdm-gcc has priority and
gcc --version
on both DOS and MSYS shows
gcc.exe (tdm64-2) 4.8.1
I don't know what heuristic does CDT use to find toolchains. My question is, how can I tell CDT to use the gcc in a specific location, e.g. c:/MinGW?
Note, I can't uninstall the Haskell platform version of gcc as I will need HP.
Thanks,
I figured it out. It seems that Eclipse CDT does not take tdm-gcc MinGW 64-bit because eclipse itself is 32-bit. So it picked up the only 32-bit MinGW it can find, which is the old version from HP.
To verify this, I installed java 1.7 64-bit, and downloaded 64-bit version of Eclipse CDT (Kelper). Now, CDT automatically selects the TDM-GCC 64 version of MinGW gcc.
For those in a similar situation, one additional issue is that the 64-bit CDT - MinGW64 combination combination does not build projects. No binary/executable files are generated even for a newly created HelloWorld c++ project (even though compilation is OK). In my case, I changed the build tool in the project properties..\tool chain. from CDT internal builder to either of the other two options (one is Gnu's and another is a long name), and then the project can be successfully made to generate exe files.