I have a windows 10 computer with atom version 1.52.0 and g++ (MinGW.org GCC Build-2) 9.2.0. I can run c++ programs in Atom with the gpp-compiler, but I don't like how the program output is in a new window rather than at the bottom of the Atom window. I'm trying to set up c++ with the script package, but when I run the program with the script package I get the following error.
g++: error: /mnt/c/Users/user/Documents/USACO/2015-2016/December/Silver/test.cpp: No such file or directory
g++: fatal error: no input files
compilation terminated.
I can run java programs with the script package btw. screenshot
A bit late to reply. But for those to come here from Google, on the script package page, it clearly says:
+---------+------------+-----------------+------------------+--------------------+---------------------------------------------------------+
| Grammer | File Based | Selection Based | Required Package | Required in PATH | Notes |
+---------+------------+-----------------+------------------+--------------------+---------------------------------------------------------+
| C++ | Yes | Yes | | xcrun clang++/g++ | Available only on macOS and Linux. Run with -std=c++14. |
+---------+------------+-----------------+------------------+--------------------+---------------------------------------------------------+
Available only on macOS and Linux. Run with -std=c++14.
So, it seems it's not available for Windows. Instead, you can use another package called gpp-compiler:
https://atom.io/packages/gpp-compiler
It works fine on windows:
You'll need to install MinGW and add it to your PATH.
Related
I just switched to ubuntu and I wanted to setup notepad++ for CPP.
So I used the NppExec plugin to compile within notepad++,
My script was :
npp_save
g++ "$(FULL_CURRENT_PATH)" -o "$(CURRENT_DIRECTORY)\$(NAME_PART)obj"
./"$(NAME_PART)obj"
Here the "obj" I used is to just save the file with an "obj" keyword nothing else.
The last line ./"$(NAME_PART)obj" is to run the program.
But it looks not working in ubuntu, it produces this error:
NPP_SAVE: Z:\home\username\cpp\test.cpp
g++ "Z:\home\username\cpp\test.cpp" -o "Z:\home\username\cpp\testobj"
; about to start a child process: "g++ "Z:\home\username\cpp\test.cpp" -o "Z:\home\username\cpp\testobj"
CreatProcess() failed with error code 2:
File not found.
./"testobj"
; about to start a child process: "./"testobj""
CreatProcess() failed with error code 2:
File not found.
I have investigated some of what I think is the problem, so I think is the usage of / and \ in changing the directory.
I don't know how to fix that, so I can not be sure.
Any ideas? :) I am using vim btw in the same machine and it is working perfectly.
In theory it might be possible (see below), in practice it is rather convoluted and works only for simple compiles (like single file hello world type).
I would suggest you try a linux program, e.g.
an editor like
scite (same editing engine as notepad++) or
kate
or a real IDE like
kdeveloper or
qtcreator.
The problems with Notepad++ inside wine and g++ outside wine (from the linux install ) are this:
notepad++ inside wine under linux is still a windows program
NppExec can only do, what a cmd inside wine can do.
starting g++ directly inside cmd is an error due to g++ being a linux binary and not a windows binary
that is your CreatProcess() failed with error code 2, it means: you are trying to execute a linux program inside wine.
That does not work! (At least not so easy.)
Though you can start linux program inside cmd inside wine using start /unix ...
started this way, g++ wants linux paths and NppExec through its variables will provide only windows paths (whatever wine has set up as drives like Z:\home\username\src\hello.cpp)
though you can convert wine paths to linux paths via the winepath -u command.
g++ started through 'start /unix ... ' inside a cmd inside wine has no proper terminal to report errors to you
though you can start an xterm for g++ and have g++ reports its messages to the xterm
the downside is that g++ will report errors using the linux paths in the xterm, so you cannot double click on an error message an get to the corresponding filename and line.
You get the idea: its complicated not comfortable.
What worked for me for a helloword.cpp was this NppExec script:
NPP_SAVE
npp_run cmd /c start /unix /usr/bin/xterm -e "/usr/bin/winepath -u '$(FULL_CURRENT_PATH)' | xargs g++ -o /tmp/a.out && /tmp/a.out ; echo 'Press return'; read"
The second line
uses an xterm,
let winepath convert the Z:\home\... path to /home/... and
have that send to g++ for compilation using /tmp/a.out as binary
if compile is successfull, /tmp/a.out is executed
the echo and read are for keeping the xterm open so that you can read the output.
If you really want to use Notepad++ inside wine, one option might be using Gnu Make outside of wine and have NppExec run make all or make run similar to the g++ in my script example. That would work for more complicated compiles.
Recently I have updated my MacBook operating system to Catalina 10.15.7 and Xcode command line tools to 12.1. Ever since I have been getting the following error when I try to use any C++ compiler:
gcc A3v2.cpp
In file included from /usr/local/include/c++/9.2.0/bits/postypes.h:40,
from /usr/local/include/c++/9.2.0/iosfwd:40,
from /usr/local/include/c++/9.2.0/ios:38,
from /usr/local/include/c++/9.2.0/ostream:38,
from /usr/local/include/c++/9.2.0/iostream:39,
from A3v2.cpp:13:
/usr/local/include/c++/9.2.0/cwchar:44:10: fatal error: wchar.h: No such file or directory
44 | #include <wchar.h>
| ^~~~~~~~~
compilation terminated.
I have tried removing and re installing command line tools but it hasn't worked (amongst trying various other solutions I've found on Stackoverflow). When I run sudo find on wchar.h I get the following.
sudo find /Library -name wchar.h
find: /Library/Application Support/com.apple.TCC: Operation not permitted
/Library/Developer/CommandLineTools/usr/include/c++/v1/wchar.h
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/wchar.h
As a current work around (as I need a c++ compiler for a current assignment) I have been using:
/usr/bin/gcc A3v2.cpp
however I'm hoping this will just be temporary. I think this is a path problem since the missing header file exsits? Not sure what I am doing when it comes to specifying file paths so please let me know if you know how to solve this. Thanks!
When trying to compile Fortran using PGI on Mac OS X Sierra, I get the error
ld: file not found: /usr/lib/crt1.o
I found a workaround for older Mac OS X versions (http://www.pgroup.com/userforum/viewtopic.php?t=4578)
sudo ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.o /usr/lib/crt1.o
However, with Sierra, System Integrity Protection prevents writing in /usr/bin. How can I solve this problem?
I tried linking into /usr/local/bin/ (which is permitted), but then, how can I make sure the compiler searches for library in that path?
Installing just the Command Line Tools for Mac OS X solved the problem. Do this in your terminal:
xcode-select --install
Installing Lazarus on MacOS X :
worked for me
http://wiki.lazarus.freepascal.org/Installing_Lazarus_on_MacOS_X#Xcode_5.0.2B_compatibility_.28Mac_OS_X_10.8_and_10.9.29
Solution for command line programs:
The correct answer for me was as explained in this link:
https://medium.com/#kviat/free-pascal-3-0-2-linking-on-macos-sierra-c40706e86fda
After some googling I realized that most libraries were removed from
/usr/lib in macOS Sierra. However this case is handled in FPC, so we
just need to set internal compiler variable MacOSXVersionMin to 10.8
(or later). There is no standard compiler option for it, but after
some search in source code I found the solution: set the environment
variable MACOSX_DEPLOYMENT_TARGET:
You should give the deployment target of MacOS:
MACOSX_DEPLOYMENT_TARGET= XX.XX #for instance 10.15
Solution for generally:
Linking the necessary file to /usr/bin/crt* . As already stated, this linking will be prohibited by MacOs beginning from 10.10. But there is still a way to accomplish this linking procedure and it solves the problem.
1) Reboot the Mac and hold down Command + R keys simultaneously after you hear the startup chime, this will boot Mac OS X into Recovery Mode
2) When the “MacOS Utilities” / “OS X Utilities” screen appears, pull down the ‘Utilities’ menu at the top of the screen instead, and choose “Terminal”
3) Type the following command into the terminal then hit return:
csrutil disable; reboot
4) When you come back, run the command sudo mount -uw /
5) Just run the linking code you want to:
sudo ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.o /usr/lib/crt1.o
sources: http://osxdaily.com/2015/10/05/disable-rootless-system-integrity-protection-mac-os-x/
https://www.reddit.com/r/MacOS/comments/caiue5/macos_catalina_readonly_file_system_with_sip/
In my case the problem was actually an error on the PGI installation side. PGI seems to be well aware that newer versions of macOS do not have the /usr/lib/crt1.o and that you can't create files there anymore. But it is possible to setup correct environment variables for the PGI compilers and then the linker should use the correct path to the crt1.o.
This configuration should be done automatically during the installation of the PGI compiler suite by running the makelocalrc command and should generate the file /opt/pgi/osx86-64/$PGIVER/bin/localrc. But in my case this step failed silently.
Reasons for failure seem to be:
license agreement for XCode not (yet) accepted, although this error should leave you with a /opt/pgi/osx86-64/$PGIVER/bin/localrc.error, containing some details
XCode version not supported, which seems to leave you with nothing. This is what I got when I ran the makelocalrc script manually:
makelocalrc -x /opt/pgi/osx86-64/19.10
Error: Unsupported XCode version 11
In my case (PGI 19.10, macOS 10.15, XCode 11.2.1) I manually patched the /opt/pgi/osx86-64/19.10/bin/makelocalrc to not error out on XCode 11:
if test $xcodever -gt 11 ; then # <-- was "-gt 10"!
echo " Error: Unsupported XCode version " $xcodever
exit -1
fi
and then re-ran the script after which compilation with PGI compilers (both pgcc and pgfortran) worked:
sudo /opt/pgi/osx86-64/2019/bin/makelocalrc -x /opt/pgi/osx86-64/19.10
Your case may vary, but you might want to check for a /opt/pgi/osx86-64/$PGIVER/bin/localrc.error or the /opt/pgi/osx86-64/$PGIVER/bin/localrc itself and try to manually (re-) generate it if it is not there or if you upgraded XCode/macOS since the installation of the PGI compilers.
I have two virtual machines; both are running on identical Intel Xeon E5-2699v4 (Broadwell-EP) platform. However, one virtual machine (the production machine) resides on a host which has of the features disabled, while they're all enabled on the other machine (the build machine). We also have other host machines running on an Intel Xeon E5-2699v3 platform (Haswell-EP) but those hosts will be addressed at a later time. I am able to determine what features are disabled by observing the results from a one-line bash command from my local machine:
sort <(sshi vm1 "cat /proc/cpuinfo | grep flags | head -n 1 | sed -r 's/\s+/\t/g' | cut -f 3- | sed -r 's/\t/\n/g' | sort | uniq") <(sshi vm2 "cat /proc/cpuinfo | grep flags | head -n 1 | sed -r 's/\s+/\t/g' | cut -f 3- | sed -r 's/\t/\n/g' | sort | uniq") | uniq -u
...where sshi is a bash alias which determines what key file to use when connecting, vm1 is the hostname of the machine with all of the features enabled and vm2 is the hostname of the machine which does not have all of the features enabled. I would think that this oneline command can then be paired with a loop to generate feature enablement flags for a compiler...
for feature in $(...); do echo "-mno-${feature}"; done
...which generates a list as such:
-mno-abm
-mno-avx
-mno-avx2
-mno-bmi1
-mno-bmi2
-mno-eagerfpu
-mno-fma
-mno-hle
-mno-invpcid
-mno-movbe
-mno-pcid
-mno-pse36
-mno-rtm
-mno-tsc_adjust
-mno-xsave
-mno-xsaveopt
Taking this list and passing it to the compiler via CMake:
LIST(APPEND COMMON_FLAGS /* paste flags here, along with other things such as -Wall -pedantic -Werror=etc */)
SET_PROPERTY(TARGET my_target PROPERTY COMPILE_OPTIONS ${COMMON_FLAGS})
...presents compilation errors when using g++ (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6) provided by package devtoolset-4 on Oracle Linux Server 7.3:
c++: error: unrecognized command line option ‘-mno-bmi1’
c++: error: unrecognized command line option ‘-mno-eagerfpu’
c++: error: unrecognized command line option ‘-mno-invpcid’
c++: error: unrecognized command line option ‘-mno-pcid’
c++: error: unrecognized command line option ‘-mno-pse36’
c++: error: unrecognized command line option ‘-mno-tsc_adjust’
That first error can be resolved simply by changing it to -mno-bmi instead of -mno-bmi1
I did find this interesting tidbit from the GCC mailing list archive: gcc -march=native -Q --help=target. Using this to search for features does not reveal all of the missing feature flags, so that seems to be a dead end to me.
So my questions are thusly:
Why aren't the feature sets directly convertible to feature flags
for compilers? I would certainly understand if it's a "new" feature
that the compiler simply doesn't understand or support... but
changing -mno-bmi1 to -mno-bmi suggests to me that there's
simply a disagreement of what to name the feature sets.
Is there a better method of compiling a fully-optimized build from
the machine with all features enabled to target the machine with
some features disabled?
Is there a mapping somewhere which describes what feature names are
reported by the kernel through /proc/cpuinfo (or elsewhere) and
the name used by compilers?
I've been trying to set a path to Clion directory in my computer in order to open this program with a command in terminal, but it didn't worked.
If you read this and asked yourself: "what?". I want to start a C++ project like I did with a normal text editor(I used to write codes with gedit).
I want something like, make a hello world:
Clion helloWorld.cpp &
And it will open a new project, named helloWorld, and then I can write down the code.
If it is impossible to do that, sorry.
In researching this question, I just discovered that there is an officially supported method for doing this is via CLion's Tools|Create Command Line Launcher... menu item.
Full details are posted here: https://www.jetbrains.com/help/clion/working-with-the-ide-features-from-command-line.html
Start CLion using the GUI interface, then start Terminal and run the following to find what process is running:
ps -ae| grep lion
Output
57257 ?? 0:20.45 /Applications/CLion.app/Contents/MacOS/clion
57434 ttys000 0:00.00 grep lion
So the command I need to use, in my case, to start CLion from the command line is:
/Applications/CLion.app/Contents/MacOS/clion
Then you need to pass the directory containing your project, so you could make a function like this:
function CLion { /Applications/CLion.app/Contents/MacOS/clion "$1"; }
Then you can just type:
Clion ~/CLionProjects/someProject
For Mac users, you need to add following row in ~/.bash_profile:
alias clion='open -na "CLion.app" --args "$#"'
Then from the terminal you can run CLion:
clion /path-to-your-project
If you use JetBrains Toolbox to manage your CLion (or other IntelliJ) apps like I do, you'll find that Toolbox installs CLion with a versioned pathname. This means every time you update CLion, the path to the clion.sh launcher script changes.
For Linux environments, you can use the following in your ~/.bash_profile to handle this:
alias clion="`find ~/.local -iname clion.sh | head -1` >/dev/null &" #Linux
or
alias clion='open -n "$(IFS=$'\n' && find "${HOME}/Library/Application Support/JetBrains/Toolbox/apps/CLion" -iname clion.app | head -1)"' #Mac OS X
If you upgrade your CLion you can restart your terminal or just run . ~/.bashrc to update the clion alias.