I have run into an ERROR with SBT today. It can best be shown with the sbt sbt-version command:
Run on 5/29/17:
eric#linux-x2vq:~$ sbt sbt-version
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option
MaxPermSize=256M; support was removed in 8.0
[info] Set current project to eric (in build file:/home/eric/)
[info] 0.13.13
Run on 6/1/17:
eric#linux-x2vq:~$ sbt sbt-version
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option
MaxPermSize=256M; support was removed in 8.0
[ERROR] Failed to construct terminal; falling back to unsupported
java.lang.NumberFormatException: For input string: "0x100"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Integer.parseInt(Integer.java:580)
at java.lang.Integer.valueOf(Integer.java:766)
at jline.internal.InfoCmp.parseInfoCmp(InfoCmp.java:59)
at jline.UnixTerminal.parseInfoCmp(UnixTerminal.java:233)
at jline.UnixTerminal.<init>(UnixTerminal.java:64)
at jline.UnixTerminal.<init>(UnixTerminal.java:49)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at java.lang.Class.newInstance(Class.java:442)
at jline.TerminalFactory.getFlavor(TerminalFactory.java:209)
at jline.TerminalFactory.create(TerminalFactory.java:100)
at jline.TerminalFactory.get(TerminalFactory.java:184)
at jline.TerminalFactory.get(TerminalFactory.java:190)
at sbt.ConsoleLogger$.ansiSupported(ConsoleLogger.scala:123)
at sbt.ConsoleLogger$.<init>(ConsoleLogger.scala:117)
at sbt.ConsoleLogger$.<clinit>(ConsoleLogger.scala)
at sbt.GlobalLogging$.initial(GlobalLogging.scala:43)
at sbt.StandardMain$.initialGlobalLogging(Main.scala:64)
at sbt.StandardMain$.initialState(Main.scala:73)
at sbt.xMain.run(Main.scala:29)
at xsbt.boot.Launch$$anonfun$run$1.apply(Launch.scala:109)
at xsbt.boot.Launch$.withContextLoader(Launch.scala:128)
at xsbt.boot.Launch$.run(Launch.scala:109)
at xsbt.boot.Launch$$anonfun$apply$1.apply(Launch.scala:35)
at xsbt.boot.Launch$.launch(Launch.scala:117)
at xsbt.boot.Launch$.apply(Launch.scala:18)
at xsbt.boot.Boot$.runImpl(Boot.scala:41)
at xsbt.boot.Boot$.main(Boot.scala:17)
at xsbt.boot.Boot.main(Boot.scala)
[info] Set current project to eric (in build file:/home/eric/)
[info] 0.13.13
No changes (that I know of) to either my SBT or Java setup.
Any ideas on what might be causing this or how to fix the error?
Thank you!
I had the same issue, especially when the TERM environment variable is set to xterm-256color. Setting it to a different value fixed the issue for me, e.g.
export TERM=xterm-color
I found the package which causes this issue: ncurses. I downgraded ncurses to version ncurses-6.0+20170429-1 (I am using Arch Linux) and SBT starts just fine.
Steps for Arch Linux:
cd /var/cache/pacman/pkg
sudo pacman -U ncurses-6.0+20170429-1-x86_64.pkg.tar.xz # or some other older version
Steps for Mac: see https://github.com/jline/jline2/issues/281
I think this issue was introduced with ncurses version 20170506, see: http://invisible-island.net/ncurses/NEWS.html#index-t20170506
+ modify tic/infocmp display of numeric values to use hexadecimal when
they are "close" to a power of two, making the result more readable.
I filed an issue on the SBT issue tracker: https://github.com/sbt/sbt/issues/3240
Edit: SBT version 0.13.16 includes the fix for this problem.
You can add export TERM=xterm-color to the top of /usr/share/sbt/bin/sbt because $HOME/.sbtconfig is deprecated.
sbt command is just a script. It load $HOME/.sbtconfig at the very beginning, so just put
export TERM=xterm-color
as #user3113045 said in the conf file, sbt will work. In that case your other term commands will still use xterm-256color.
This resolved the issue in my case (Linux Users):
Open your terminal
Navigate to your project directory
type "export TERM=xterm-color" in your terminal without the quotes
Hit ENTER
That is all and then you are good to go.
One year passed... now it happened to me.
So, ncurses did change, and the corresponding sbt part was ...I guess... probably only implemented based on random guessed tests and observations/bugs and not any spec nor RFC. (So far, sbt is the only program with this ncurses issue that I know of.)
In case you can't simply upgrade sbt nor downgrade ncurses, you could change the TERM environment variable as mentioned in the other answers.
trivial fix:
If your sbt script is some bash script (most likely, unless you run DOS' .bat files)
$ file /usr/bin/sbt
/usr/bin/sbt: Bourne-Again shell script, ASCII text executable
, then it might suffice to add this workaround:
TERM="${TERM/xterm-256color/xterm-color}"
If you can, change sbt version in build.properties to higher. 13.16 work for me.
For Ubuntu 20.04 Users, Open your terminal and run the bellow CMDs
Go to this "/usr/share/sbt/bin" directory ( $ cd /usr/share/sbt/bin )
give the permission to edit file ( $ sudo chmod -R 777 sbt )
Open the sbt text file in this directory ( $ nano sbt )
Add this "export TERM=xterm-color" cmd in top and save ( Ctrl + X )
Ex:-
#!/usr/bin/env bash
export TERM=xterm-color
set +e
I can't write a comment as my score is too low, but user3113045's answer worked when I added export TERM=xterm-color to my .zshrc file
I faced this issue when i am using activator which uses sbt internally.
I am using Ubuntu and this error was frustrating me.
I started facing this issue when i ran
$ activator gen-idea (tool which as per the intellij is legacy)
After this i tried to delete all the cache that this tool generated.
I deleted the .ivy and .sbt directories from my home folder and ran the activator cleanFiles compile command which resolved my issue.
Related
I am just learning C++ via Codelite, which was updated on 01/11. After updating to the latest version, 17.0.0, I get the error
process_begin: CreateProcess(NULL, makedir Debug, ...) failed.
mingw32-make[1]: *** [AssignmentOperator.mk:90: Debug/.d] Error 2,
mingw32-make: *** [Makefile:5: All] Error 2
when I run a simple code.
#include <iostream>
int main(){
std::cout<<"Hello"<<std::endl;
return 0;
}
and get nothing in the terminal window.
How can I fix this problem? Thanks a lot.
I guess the probrem occured since the updating of Codelite, but I have no idea how to fix it.
Looks like a an old relic that was not handled properly during upgrade.
This can be fixed in 2 ways:
Update the mkdir command as defined by your compiler setup:
Go to Settings -> build settings and select your compiler from the list
Select the Tools tab
Select the last entry at the bottom mkdir
Replace the content with the mkdir that comes with CodeLite, for example, if you have installed CodeLite under C:\Program Files\CodeLite (the default path), set it to
"C:/Program Files/CodeLite/mkdir.exe" -p
Notice the double quotes around the command itself
Change the makefile generator used
Right click on your project and open the project settings
In the General tab, under the Makefile Generator change the selection from Default -> CodeLite Makefile Generator
I'm using Mac OS 13.1, and codelite 17.0.0, and when I 'clean', build completed successfully. But when I run its show 'make: ***[All] Error 2.
What happened? just new to learn C++
I had the same problem with Codelite 17 in windows.
Solution:
In Settings - Build - Tools under Makedir select the Path of mkdir.exe within in the Codelite folder (surrounded by " -quotes).
Although context help says to leave it empty in order to use the OS' own mkdir, Windows' mkdir is quite different to the mkdir of other *ix-like OS.
Furthermore for me it was necessary to explicitly add -p
There is a hint in Codelite's change dokumentation in the recent monthly build 17.1 that it solves this problem as a bugfix.
I am working in Ubuntu 16.04. I need to install gradle and the gradle is installed when i checked with sudo apt list --installed command but when i use gradle -version command it shows the following error,
JAVA_HOME is set to an invalid directory: /usr/lib/jvm/java-8-oracle/jre/bin/java
In sudo vim /etc/environment file,
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games"
JAVA_HOME="/usr/lib/jvm/java-8-openjdk-amd64/"
http_proxy="http://username:password#IP:port no/"
https_proxy="https://IP:port no/"
ftp_proxy="ftp://IP:port no/"
I don't know where i made mistakes. Please help me.
Thanks.
On a 64bit openSuse 64 42.1 box;
readlink -f $(which java)
provided;
/usr/lib64/jvm/java-1.8.0-openjdk-1.8.0/jre/bin/java
But;
export JAVA_HOME=/usr/lib64/jvm/jre-1.8.0-openjdk
is the path that worked and allowed java emulator to run.
So i think we have to manually browse our file system and see what path to choose.
Today I faced this problem. I am using the default java that comes with your linux distro (so in my case, linux mint).
$ whereis java
This command gave me
java: /usr/bin/java /usr/share/java
So, I opened /user/bin. There was a link to Java. I right clicked it and selected follow original link. This lead me to /usr/lib/jvm/java-11-openjdk-amd64/bin/java.
So now that I know where this java is, I opened my .bashrc file, and edited the JAVA_HOME.
So for my case,
## My Custom variables
export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64
export PATH=$JAVA_HOME/bin:$PATH
This solved the problem.
Now if you are using some other java (say you downloaded from oracle and extracted the zip file ...), then you have to add that location. So for example, if your java is in /home/user/.sdkman/candidates/java/current, then
export JAVA_HOME=/home/user/.sdkman/candidates/java/current
export PATH=$JAVA_HOME/bin:$PATH
I see a mismatch. In your enviornment file the JAVA_HOME is set to "/usr/lib/jvm/java-8-openjdk-amd64/" and your mentioned that the error that you got relates to the JAVA_HOME as "/usr/lib/jvm/java-8-oracle/jre/bin/java"
If you JAVA is really installed in /usr/lib/jvm/java-8-oracle directory, then you need to ensure that the JAVA_HOME is set to that directory. And also your PATH reflects $JAVA_HOME/bin in it.
I typically install Oracle JDK/JRE separately in a separate directory such as /usr/local/jdk1.8.0 etc.
check the jvm installtion folder from Files
eg : /usr/lib/jvm/java-12-oracle
then in terminal run sudo nano /etc/environment and add the line
JAVA_HOME="/usr/lib/jvm/java-12-oracle"
Then open terminal and run
export JAVA_HOME="/usr/lib/jvm/java-12-oracle"
When I am trying to sourceCpp, it gives a warning:
ld: warning: text-based stub file
/System/Library/Frameworks//CoreFoundation.framework/CoreFoundation.tbd
and library file
/System/Library/Frameworks//CoreFoundation.framework/CoreFoundation
are out of sync. Falling back to library file for linking.
But the function actually works. Just wondering how to solve this warning.
Using MacOS Mojave 10.14.2, the fix for me was to use the solution from this comment on GitHub:
export SDKROOT=macosx10.14
Put the line above in your ~/.bash_profile. Replace 10.14 with your specific version of MacOSX Xcode tools. Find out what version you have by doing:
xcrun --show-sdk-path
It will print something like:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk
Just grab the last word, make it all lower caps and replace it in the export command above.
Update Sep 2019
In the latest release, they removed the version number from the sdk. Just grab the full path and export it as SDKROOT, like this:
export SDKROOT="/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk"
Update Aug 2021
To avoid having to continuously update the exported value whenever you upgrade your OS, you can place the xcrun command directly in the shell script:
export SDKROOT=$(xcrun --show-sdk-path)
I had this problem while compiling Go code on my Mac too.
The tld files were out of sync in /System/Library/Frameworks/.
The solution:
Just links the recent frameworks from MacOSX.sdk to /Library/Frameworks/
sudo ln -s /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreFoundation.framework /Library/Frameworks/CoreFoundation.framework
Edit: this seems to have stopped working post 10.13.16. Trying it will not hurt your mac after the re-install but i'm not sure how to fix it going forward.
Came across this recently, just remove the command line tools for mac and re-install.
$ rm -rf /Library/Developer/CommandLineTools
$ xcode-select --install
After these steps you will see a pop to install the new version of the tools.
Reinstalling may help, but also may not.
It's Apple's fault and they need to fix it with another command line tools update.
Just ignore the warning for now.
(See a bunch of other people experiencing the issue here: https://github.com/vim/vim/issues/3445 and here: https://github.com/golang/go/issues/26073)
I think this has nothing to do with Rcpp.
This is related to your system.
I show first lines of one tbd file below. It is just a text file. You can open it using a text editor.
--- !tapi-tbd-v3
archs: [ i386, x86_64, x86_64h ]
uuids: [ 'i386: 17321B27-67AB-3D26-B9DF-A69624B1C82B', 'x86_64: 358C547D-E227-3228-8218-62327F4605C8',
'x86_64h: 945E5C0A-86C5-336E-A64F-5BF06E78985A' ]
platform: macosx
install-name: /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
current-version: 1452.23
compatibility-version: 150
exports:
- archs: [ i386 ]
symbols: [ '$ld$add$os10.5$.objc_class_name_NSObject', '$ld$add$os10.6$.objc_class_name_NSObject',
'$ld$add$os10.7$.objc_class_name_NSObject', '$ld$hide$os10.4$.objc_class_name_NSArray',
'$ld$hide$os10.4$.objc_class_name_NSCalendar', '$ld$hide$os10.4$.objc_class_name_NSData',
...
As I understand, the tbd file contains the version and location of the real library file. It is like a "link". (Just my personal understanding. Please correct me if this is wrong.)
After the upgrade of Xcode, your tbd file and real library are out of sync. Then you got the warning.
I think you can ignore this warning for now, since your compiler has fallen back and found the correct library.
The dates of CoreFoundation and CoreFoundation.tbd show that the latter is much older. This suggests it can be ignored. The out of sync problem can easily be cured by deleting the .tbd file. It is not needed and if not present cannot generate the out of sync error.
I use CoreFoundation and IOKit on 10.13.6 and this is a simple solution avoiding reloading CommandLine tools or setting links or trying to export SDKs etc.
John
If you previously set SDKROOT in your ~/.bash_profile or ~/.zshrc you either need to update it whenever you update macOS or delete (if you do not need it).
This was the case for me export SDKROOT=macosx10.14 was in my ~/.bash_profile, after I updated to macOS Catalina 10.15.7 so it was causing the problem.
If you choose to update, it will look like this (based on previous answers)
export SDKROOT="/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk"
When compiling with -fsanitize=memory I get WARNING: Trying to symbolize code, but external symbolizer is not initialized! when running the program. How do I initialize the external symbolizer?
I solved my own problem using MSAN_SYMBOLIZER_PATH=$(which llvm-symbolizer-3.4) ./a.out. The problem is that Ubuntu postfixes the version number but the binary doesn't know that. Of course you need to use MSAN instead of ASAN when using the memory sanitizer.
You are supposed to be able to set the ASAN_FILTER environment variable to point at a symbolizer, but I could not get it to work. However, you can redirect stderr into a symbolizer after the fact. You'll still get the warnings about the uninitialized symbolizer, but the filenames and line numbers will be correct.
You can use asan_symbolizer.py as the external symbolizer. After downloading it from that link (to /tmp, for example), invoke your program like so (in bash, for this example):
./myprogram 2>&1 | /tmp/asan_symbolize.py | c++filt
On my Ubuntu system, the issue is that LLVM's tools are installed under /usr/bin with version suffixes (like llvm-symbolizer-4.0), and the sanitizer tools are looking for them without version suffixes.
LLVM also installs its binaries to, e.g., /usr/lib/llvm-4.0/bin; the tools under /usr/bin are actually just symlinks. So an easy solution is to add the appropriate /usr/lib/llvm-*/bin directory to your path when working with sanitizers.
I received such warning when I run program debug version (compiled with -fsanitize=address) on Linux machine that didn't contain clang installation. The problem disappeared after I installed clang from devtoolset.
I'm installing Apache Spark which uses its own copy of SBT to set things up.
I'm using Linux Mint in a VirtualBox VM.
Here's a snippet from the error when I run sudo ./sbt/sbt compile from the Spark directory spark-0.9.0-incubating:
[error] (core/compile:compile) java.io.IOException: Cannot run program "javac": error=2, No such file or directory
[error] Total time: 181 s, completed Mar 9, 2014 12:48:03 PM
I can run java and javac from the command line just fine: e.g. javac -version gives javac 1.6.0_31
The correct jdk1.6.0_31/bin is in my PATH.
I read that the error might be due to the 64-bit JDK that I had installed, but I get the same error with the 32 bit JDK.
How can I sort out the issue?
edit: Using bash shell.
DISCLAIMER I'm mostly guessing now and still am unsure I should've responding here rather than adding a comment. Until it's clear, the DISCLAIMER remains.
When you execute java and javac from the command line, what user are you at that moment? I'm pretty sure your problems surface because the users you operate are different.
Please notice that you're executing sudo ./sbt/sbt compile as root (due to the way sudo works), but you say nothing about what user(s) you've been using to execute javac and java commands.
Add jdk1.6.0_31/bin to PATH for root and you'll be all set (as far as the configuration of Java's concerned).
I'd also recommend setting JAVA_HOME to point to jdk1.6.0_31 as it may help at times -- many applications are using it as the way to find the location of Java.
As a workaround, you may edit ./sbt/sbt and add PATH and JAVA_HOME appropriately.
You need to include the javac executable. To do this in Ubuntu please run the following command:
sudo apt-get install openjdk-7-jdk
It also places it within your path variable.