I'm trying to run my C++ program on my Macbook and I'm trying to run my program in VSCode by running the build task C/C++:clang++ build active file. However, every time I do this I get this error ld: can't open output file for writing: /Users/admin/first/first, errno=21 for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) The terminal process terminated with exit code: 1
This appears to be a simple permission problem here:
ld: can't open output file for writing
The linker cannot write to the file specified.
Edit: As correctly pointed to by molbdnilo, the error 21 is EISDIR, which means the file you are trying to write to already exists as a directory. So ... just this folder? :)
Did you brew install any c++ tools? Sometimes that is the source of these issues. The program is trying to use native OS versions of things when it should use Homebrew's or vice versa.
Related
I keep getting the same error on a simple piece of code after I downloaded multiple compilers and added them to 'PATH' in windows settings
Error :
E:\Programs\sublimeProjects\helloWorld: file not recognized: File format not recognized
collect2.exe: error: ld returned 1 exit status
[Finished in 985ms]
I downloaded multiple compilers and added them to 'PATH' in windows settings
This is a very bad idea. You will run into a complete mess where parts of one compiler interfere with parts of the other compiler due to them all being on the PATH.
I would recommend to immediately remove all compilers from the PATH. Instead, what you should do is have a batch file or shell script that you run to set up the environment for just that window.
Some compiler installations come already set up this way (e.g. mingw-w64/MSYS2).
In SublimeText you can set it to use that batch file or script to set up the build environment, e.g. see https://gist.github.com/sagebind/9039773048a3900fa49a .
Ive downloaded a sample code from here, but when I try opening it using visual studio code, I keep getting the following error:
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation
I have tried using xCode but this time it wont open at all,
As it can be figured Im using a mac, with the m1 chip to be precise.
This is a picture of the error:
How do I go about fixing the issue?
One can modify the configuration of Visual Studio code to support multiple files (header(s) and cpp ) running simultaneously on Mac.
Step 1
On the Virtual studio menu bar select
->terminal->configure task->Select the first option(C_Cpp_Runner)
Step 2
Go ahead and open the file folder in VS Code ->cmd+O ->select the file folder (with cpp and header included.)
At this point try running the code, if the same error still persist then, do Cmd+shift+P and make sure the Auto-header extension is installed.
That's what helped fixing my issue, hope it can benefit someone else out there.
I tried to compile a cpp file using VScode, but I have got an issue. The tdm-gcc have already added to environment variable. I tried to reboot my computer but it didn't work. Here is the error.
error:
/usr/bin/bash: D:TDM-GCC-64bing++.exe: command not found
The terminal process terminated with exit code: 127
Disclaimer: I am new here, I've done my best to follow the posting guidelines so please let me know if this needs any extra information. I am also relatively new to Linux development.
Background:
I am in the process of building a library using ActiveMQ-cpp on Linux. I have built and run it successfully on the host Ubuntu PC, but attempting to cross-compile it for the target ARM-based machine is producing some very abstruse errors.
The first step involves building APR (http://apr.apache.org/) using the arm-linux-gcc compiler. After some research, the following command runs the configuration script with little fuss:
CC=/usr/local/arm-linux/bin/arm-linux-gcc ./configure --prefix=/root/apr-arm --host=arm-linux cross_compiling=yes ac_cv_file__dev_zero=no ac_cv_func_setpgrp_void=no apr_cv_tcp_nodelay_with_cork=no apr_cv_process_shared_works=no
This allows the next step - running the makefile.
Current Issue: Entering make on the command line exits prematurely at the following line:
[...]
/root/.local/share/Trash/files/apr-1.5.1/build/mkdir.sh include/private
tools/gen_test_char > include/private/apr)escape_test_char.h
/bin/bash: tools/gen_test_char: cannot execute binary file
make[1]: *** [include/private/apr_escape_test_char.h] Error 126
make[1]: Leaving directory `/root/.local/share/Trash/files/apr-1.5.1'
make: *** [all-recursive] Error 1
Attempted Fixes: A solution to the following question, posted by the asker, has not worked. It is possible that I've not followed the process correctly (Apache Cross Compilation Error ./gen_test_char: cannot execute binary file)
In the same theme, I tried temporarily removing the problem gen_test_char program from its directory but the clever script just rebuilds it.
My aim is to either avoid this error and continue the build process on Ubuntu, or perhaps consider other means of building the library. I have built it with no trouble in VS2013 on Windows, so if it is possible to cross compile that project for ARM architectures I would happily go ahead with that.
APR need gen_test_char to be compiled for system not for arm, why you got "bin/bash: tools/gen_test_char: cannot execute binary file" error because make program is going to execute gen_test_char on your system and if you cross compile then every time you got this error.
To avoid this error please follow below steps:
1) Cross compile APR which is going to fail
2) compile APR for system and copy gen_test_char to cross compiled APR's directory.
3) Again cross compile
After performing above steps you should not get "cannot execute binary file" error.
Cross compile APR which is going to fail
compile APR for system and copy gen_test_char to cross compiled APR's directory.
change the name of gen_test_char to gen_test_char_host
in Makefile file change the name of gen_test_char to gen_test_char_host because make creates it again.
Again cross compile
you may see some struct redefinition which needs to find the file and comment the redefined struct manually.
I start saying that i am a newbie in programming and then i am not sure i will be able to explain well my problem.
I had some c++ code i wrote, this code are loaded and used by some R functions.
To compile the code i used the following:
R CMD SHLIB MyCode.cpp
and i loaded the library in R with
dyn.load("MyCOde.so")
Sometimes i built also an R package and i was able to load it into R.
If i do all these stuff on a Mac with mountain lion everything work fine, but now that i switched to mavericks, i have some problems. The R CMD SHLIB MyCode.cpp command works but when i used dyn.load("MyCOde.so") i get the following text:
Errore in dyn.load(paste(dir_function, "MyCOde.so", sep = "")) :
unable to load shared object 'MyCOde.so':
dlopen(MyCOde.so, 6): Symbol not found: __ZNSt8ios_base4InitC1Ev
Referenced from: MyCOde.so
Expected in: flat namespace
in MyCOde.so
Moreover if i try to load the package in R, i get the following
ld: warning: directory not found for option '-L/usr/local/lib/gcc/x86_64-apple-darwin13.0.0/4.8.2'
ld: library not found for -lquadmath
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [MyCode.so] Error 1
Can someone helps me?
Based on the helpful website of:
thecoatlessprofessor
Type this into your terminal shell:
curl -O http://r.research.att.com/libs/gfortran-4.8.2-darwin13.tar.bz2
sudo tar fvxz gfortran-4.8.2-darwin13.tar.bz2 -C /
This will create what you need to resume compiling as before.
Since it starts to work I can publish the answer for such a cases.
When you change the compiler and standard libraries - please note that different libraries have different implementation and different standard support. Changing the basement of your system might require total rebuild of your system with the new C++ standard library.
Your libraries are not the exception. So if have the errors in your linker like this:
warning: directory not found for option
'-L/usr/local/lib/gcc/x86_64-apple-darwin13.0.0/4.8.2'
apply next algorithm:
Check whether the directory /usr/local/lib/gcc/x86_64-apple-darwin13.0.0/4.8.2 still exists. I bet it is not.
Check if you still have the libstdc++ from the missed compiler? Usually if you upgrade the same compiler and the C++ standard library ABI does not change everything should continue to work. If the ABI changed or you switch standard C++ library and compiler - you face the massive system rebuild.
Recompile your library and apps with the new C++ standard library and compiler.