I've searched through these forums for an answer to this, but the people posing this question tend to have even a rudimentary understanding of fortran, gfortran, and cygwin. I'm beginning a new course that focuses on Fortran, yet I cannot start on my first assignment ("hello world") given that I can't figure out how to start the process.
I'm on Windows, I have notepad++ and cygwin installed (as well as gnuplot, though I don't think that's relevant here). Beyond that, I don't know where to start. How do I get started here?
Ok, step by step Cygwin Fortran(90) Hello ;-)
First in which package is the GNU Fortran compiler ?
We ask the Cygwin server with cygcheck -p
$ cygcheck -p bin/gfortran
Found 8 matches for bin/gfortran
...
gcc-fortran-10.2.0-1 - gcc-fortran: GNU Compiler Collection (Fortran)
gcc-fortran-7.4.0-1 - gcc-fortran: GNU Compiler Collection (Fortran)
gcc-fortran-9.3.0-1 - gcc-fortran: GNU Compiler Collection (Fortran)
gcc-fortran-9.3.0-2 - gcc-fortran: GNU Compiler Collection (Fortran)
So after you install the latest gcc-fortran package we have
$ cygcheck -c gcc-fortran
Cygwin Package Information
Package Version Status
gcc-fortran 10.2.0-1 OK
$ cygcheck -l gcc-fortran |grep bin
/usr/bin/f95
/usr/bin/gfortran.exe
/usr/bin/x86_64-pc-cygwin-gfortran.exe
so the compiler you are looking for is named gfortran
As you have written your Fortran Hello program we can check its format
You need to save it as Unix LF format, not Windows CRLF one. You can use d2u to convert if needed.
$ file hello.f90
hello.f90: ASCII text
$ cat hello.f90
program hello
implicit none
write(*,*) 'Hello world!'
end program hello
and we can now compile and run it
$ gfortran hello.f90 -o hello -Wall
$ ./hello.exe
Hello world!
Related
I am building some software (swupdate) that has the traditional 'kbuild' (kconfig / menuconfig) mechanism, and thus has an intermediate binary mconf that it builds before it brings up the text-menu system.
I'm using a third-party "productivity layer" tool to invoke the menuconfig (PetaLinux, a wrapper around Yocto), but the binary that results is not usable:
$ scripts/kconfig/mconf
bash: scripts/kconfig/mconf: No such file or directory
I figured out that this weird behaviour is due to the following:
$ readelf -a scripts/kconfig/mconf | grep interpreter
[Requesting program interpreter: /scratch/jenkins-BUILDS-eSDK-2021.2_stable-pipeline-build-89_VersalFullPrime/build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2]
Note the long path to a ld-linux-x86-64.so, which I don't have on my system in that location. This path looks like it's leaked into the build from the PetaLinux environment, somehow.
What it should look like is:
$ readelf -a scripts/kconfig/mconf | grep interpreter
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
Incidentally, I got that binary by building mconf manually, with a command like this:
make -C <path/to/source> O=<path/to/build> menuconfig
...
HOSTCC scripts/kconfig/mconf.o
...
Anyway, that's all details, and my actual question is this - where can I find information about how the "program interpreter" is set by the compiler or linker? Where do you think it's going wrong? Is there an environment variable that can affect this behaviour?
first i used command : which gcc
If it shows location other than /usr/bin, then how to set the right path to compile the C program
It depends upon your $PATH. And that could be set to something starting with a directory containing some gcc command. Run echo $PATH to find out what is your current $PATH.
You could either type exactly /usr/bin/gcc, or add some alias to your interactive shell configuration (often ~/.bashrc which you might edit with great care), or change your PATH setting, or, assuming which gcc gives something like /home/zaid/bin/gcc (i.e. your $HOME/bin/gcc if $HOME/bin appears early in your $PATH), add a symbolic link ln -sv /usr/bin/gcc $HOME/bin/.
If you compile a program made of several translation units, you should use some build automation tool, probably GNU make. Try once make -p to understand the builtin rules known to your make and take advantage of these. Then, edit your Makefile, perhaps by adding near its beginning lines like
CC=/usr/bin/gcc
CFLAGS+= -Wall -g
The first line (with CC=) sets your C compiler in your Makefile. The second one (with CFLAGS+=) asks for all warnings (-Wall) & debug info (-g). Because you'll use the gdb debugger.
I use Linux mint. Installed gnat to work with Ada programs, using "sudo apt-get install gnat".
created a simple hello world program:
with Ada.Text_IO;
procedure Hello is
begin
Ada.Text_IO.Put_Line("Hello, world!");
end Hello;
and saved it as "hello.adb"
Tried running it from the location it was saved, opened terminal and typed & got following:
$ cd /media/disk1/ada\ programs $ gnatmake hello.adb gcc-4.4
-c hello.adb gnatbind -x hello.ali gnatlink hello.ali $ hello The program 'hello' can be found in the following
packages: * hello * hello-debhelper Try: sudo apt-get
install $ ./hello bash: ./hello:
Permission denied
What shall i do to see the output of the program?
where does it go wrong?
Few websites said, to just type "hello" after "gnatmake hello.adb" but it didn't work,
and few said, to try "./hello" after "gnatmake hello.adb" but that too didn't work?
what next? help out pls..
Don't build in /media/disk1/ada\ programs, a directory where you (apparently) don't have adequate permission. Instead, build somewhere in your home directory, ~, where you do have permission. GNAT executables are typically installed in /usr/bin, which is probably already in your PATH.
$ which gnatmake
/usr/bin/gnatmake
$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
$ cd ~
$ gnatmake hello
gcc-4.6 -c hello.adb
gnatbind -x hello.ali
gnatlink hello.ali
$ ./hello
Hello, world!
Your compilation process is fine. As Marc C says, you normally don't need to care about the execution permission (the chmod command). GNAT should take care of this.
To execute your program, you can't just type hello. It is a new program: you've just made it, and actually your terminal is too dumb to understand what you mean. You have to tell him where your program is in the file system. That's the point of typing ./hello. Basically, it means "look for a program called hello in the current directory". Consequently, it won't work if you've moved in another directory.
You have to assign execute permission on your executable :
$ chmod a+x hello
and run it:
$ ./hello
I have a file called commanKT and want to run it in a Linux terminal. Can someone help by giving the command to run this file? I tried ./commonRT but I'm getting the error:
"bash: ./commonrt: cannot execute binary file"
[blackberry#BuildMc MainApp]$ ls -al commonKT
-rwxrwxr-x. 1 sijith sijith 10314053 Feb 27 16:49 commonKT
To execute a binary, use: ./binary_name.
If you get an error:
bash: ./binary_name: cannot execute binary file
it'll be because it was compiled using a tool chain that was for a different target to that which you're attempting to run the binary on.
For example, if you compile 'binary_name.c' with arm-none-linux-gnueabi-gcc and try run the generated binary on an x86 machine, you will get the aforementioned error.
To execute a binary or .run file in Linux from the shell, use the dot forward slash friend
./binary_file_name
and if it fails say because of permissions, you could try this before executing it
chmod +x binary_file_name
# then execute it
./binary_file_name
Hope it helps
The volume it's on is mounted noexec.
:-) If not typo, why are you using ./commonRT instead of ./commonKT ??
It is possible that you compiled your binary with incompatible architecture settings on your build host vs. your execution host.
Can you please have a look at the enabled target settings via
g++ {all-your-build-flags-here} -Q -v --help=target
on your build host? In particular, the COLLECT_GCC_OPTIONS variable may give you valuable debug info. Then have a look at the CPU capabilities on your execution host via
cat /proc/cpuinfo | grep -m1 flags
Look out for mismatches such as -msse4.2 [enabled] on your build host but a missing sse4_2 flag in the CPU capabilities.
If that doesn't help, please provide the output of ldd commonKT on both build and execution host.
This is an answer to #craq :
I just compiled the file from C source and set it to be executable with chmod. There were no warning or error messages from gcc.
I'm a bit surprised that you had to 'set it to executable' -- my gcc always sets the executable flag itself. This suggests to me that gcc didn't expect this to be the final executable file, or that it didn't expect it to be executable on this system.
Now I've tried to just create the object file, like so:
$ gcc -c -o hello hello.c
$ chmod +x hello
(hello.c is a typical "Hello World" program.) But my error message is a bit different:
$ ./hello
bash: ./hello: cannot execute binary file: Exec format error`
On the other hand, this way, the output of the file command is identical to yours:
$ file hello
hello: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
Whereas if I compile correctly, its output is much longer.
$ gcc -o hello hello.c
$ file hello
hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=131bb123a67dd3089d23d5aaaa65a79c4c6a0ef7, not stripped
What I am saying is: I suspect it has something to do with the way you compile and link your code. Maybe you can shed some light on how you do that?
The only way that works for me (extracted from here):
chmod a+x name_of_file.bin
Then run it by writing
./name_of_file.bin
If you get a permission error you might have to launch your application with root privileges:
sudo ./name_of_file.bin
Or, the file is of a filetype and/or architecture that you just cannot run with your hardware and/or there is also no fallback binfmt_misc entry to handle the particular format in some other way. Use file(1) to determine.
your compilation option -c makes your compiling just compilation and assembly, but no link.
If it is not a typo, as pointed out earlier, it could be wrong compiler options like compiling 64 bit under 32 bit. It must not be a toolchain.
full path for binary file. For example: /home/vitaliy2034/binary_file_name. Or
use directive "./+binary_file_name".
'./' in unix system it return full path to directory, in which you open terminal(shell).
I hope it helps.
Sorry, for my english language)
1st login with su
su <user-name>
enter password
Password: xxxxxx
Then executer command/file, it should run.
how to go into the environment of "c". when using cygwin... please tell me the commands to go into the c environment....
If you want to cd to the C: drive then one way is:
$ cd /cygdrive/c
If you want to edit/compile/run/debug C programs, then it's:
$ emacs foo.c # edit
$ gcc -Wall foo.c -o foo # compile
$ ./foo # run
$ gdb ./foo # debug
Do you want to navigate to the C: drive when in the shell? If so, just do cd c:
Install cygwin from cygwin.org. Select development packages like gcc during the process. Open a cygwin shell and call gcc from the command line. Or whatever.
After reading the question, my first interpretation was that the question was about how to ensure that the C locale was set for the shell in Cygwin, rather than allowing the Windows locale to be inherited. Putting export LC_ALL=C or export LC_ALL=C.utf8 into your ~/.bashrc would force the C locale in all shell contexts. The command locale can be used to see your current locale before and after changing LC_ALL, which will help verify that the change is in effect. man bash (or your shell of choice) will provide more information on what is affected by the various locale-related environment variables.