How to run .cpp file in garuda linux? I installed gcc compiler but it only compiles .c files.
Related
I had some code that wasn't working until I added extern "C" before the name of a function, even though I was compiling using gcc. The file's name did, however, end in ".cpp".
Is it possible for gcc to name mangle? Did it intelligently pick up the file extension ".cpp"?
The gcc compiler driver looks at the file extension. If it is .cpp (or .cc, .C and a few more), the file is compiled as a C++ file:
Compiling C++ Programs
I'm trying to compile a .c file into .so using Cygwin on Windows 7.
I installed Cygwin following this guide...How to Compile Linux Programs Under Windows with Cygwin:
http://www.maketecheasier.com/compile-linux-programs-under-windows/
I installed library packages: gcc-core, gcc-g++, make and wget.
I did: cd C:/cygwin/x and found the directory with My .c file. The .c file is named: myproxocket.c
My instructions for compiling the source code:
gcc -o myproxocket.so myproxocket.c -shared -ldl
I get: -bash: gcc: command not found
Can someone familiar with Cygwin help Me compile .c into .so?
Do I have to make a .o file and then make a .so file?
I'm trying to cross compile programs (currently avconv from libav) for a Nokia N9 phone using arm-linux-gnueabi-gcc from Linux Mint's 64-bit repository. The compiler's libc version is 2.15 and the phone has libc-2.10.1. They have an incompatibility in the math library, which gives me a segfault when I compile and run the avconv program from libav.
I'd need to compile and link against the older libc version, but I haven't managed to get the --sysroot option to work.
I made a small test program to avoid repeatedly configuring and compiling libav.
arm-linux-gnueabi-gcc --sysroot=/opt/CrossCompilation/NokiaN9/ -o output.sysroot hello.c
arm-linux-gnueabi-gcc -o output.nosysroot hello.c
Both commands create an identical output file. This is what hello.c looks like:
#include <stdio.h>
#include <math.h>
int main() {
printf("Hello, World! Sin = %f\n", sin(0.6451));
}
The strangest part is that gcc completely ignores the --sysroot option. If I pass a nonexisting directory to sysroot, it still produces exactly the same output binary:
arm-linux-gnueabi-gcc --sysroot=/foo/bar -o output.foobar hello.c
It doesn't even complain about any errors. What's the problem?
since I wasted a few days messing with this before reading the comments, I'm going to post artless noise's comments as an answer:
"Run the compiler with arm-linux-gnueabi-gcc -v and look at the value of --with-sysroot; this is the directory the compiler was built with. If you have this directory present on your machine (maybe with a different compiler), then the --sysroot may not work[; and if you do not see --with-sysroot and instead see --with-libs, it] means your gcc is compiled without --sysroot support."
I have a problem with compiling a fortran program with the gfortan complier.
The main program is located in main.f. So, I write in console:
gfortran D:\test\test.f
But it displays me a lot of errors such as:
C:\Users\Efds~1\AppData\Local\Temp\cchFNGgc.o:test.f:<.test+0x3a>: undefined reference to '_gridw_'
C:\Users\Efds~1\AppData\Local\Temp\cchFNGgc.o:test.f:<.test+0x3a>: undefined reference to '_gridz_'
etc.
I think it's because of functions gridw, gridz etc. are located in other *.f files. But I don't know how to link these all together.
Also, I tried to use Compaq Visual Fortran Complier, but it didn't help me.
A basic command for compiling and linking multiple source files into one executable would be
gfortran -o executable source1.f source2.f source3.f
taking care that any .f file you specify is named to the right of any other source files on which it depends. All of this, and much more besides, is well covered in the compiler's documentation.
As noted above, you can compile several files with the same command, but it's quite unusual.
You may prefer first compile to object files (".o") :
gfortran -c gridw.f
gfortran -c gridz.f
And then compile the program
gfortran test.f grodw.o gridz.o
If you have many files to link, it may be interesting to build a library:
ar cru mylib.a gridw.o gridz.o
gfortran test.f mylib.a
If you name your library libSOMETHING.a, you can simply write
gfortran test.f -lSOMETHING
While I am sure that gcc libraries (.a) are incompatible with mingw lubraries (also .a), I want to know. Can I cross-compile a windows executable with mingw using the gcc .a library generated for unix systems?
In code form, keep in mind this is a unix system:
cd mylibrarydirectory/
make #produces mylibrary.a
cd ../myprogramdirectory/
gcc -o UnixExecutable mysrc.c -L../mylibrary.a
#and I get a valid unix executable
i586-mingw32msvc-gcc -o Win32Executable.exe mysrc.c -L../mylibrary.a
#will I get a valid windows executable?
No. You have to recompile the library for Windows.
The second command should give an "incompatible library format" or something error. Or at least undefined references to whatever is linked in.