I am trying to run some old Fortran code of my project team in ubuntu 16.04. I have not done any modifications to the existing code. All I have done is installed gfortran, opened a terminal, and gone to the file location using the cd command. Here I have many files, but just consider these two: a script file compile.sh, and a makefile remail.make.
In compile.sh:
make -f remail.make
In remail.make:
SOURCE_APPLI= ../SOURCES_COUNTERFLOW/
$(SOURCE_APPLI)grcom.f
TARGET = remail.e
OBJECTS = $(SOURCES_f77:.f=.o)
COMPILE = f90
.f90.o :
$(COMPILE) -o $*.o -c $*.f90
.f.o :
$(COMPILE) -o $*.o -c $*.f
$(TARGET) : $(OBJECTS)
$(COMPILE) $(OBJECTS) -o $#
del :
$(DELETE) $(OBJECTS)
When I run compile.sh, I get this error:
f90 ../SOURCES_COUNTERFLOW/grcom.o -o remail.e
make: f90: Command not found
make: *** [remail.e] Error 127
I have installed fort77 and gfortran-4.8 compilers.
What is the reason for this error?
The problem was that I was not using the correct executable.
For example, In my case, I installed fort77 and gfortran-4.8 and the executable was saved in the name as fort77 and gfortran-4.8.
The reason for my error was that I was calling these two executables as fort77 and gfortran instead of fort77 and gfortran-4.8.
When I called fort77 and gfortran-4.8 correctly in the terminal, it works!!
Related
I am writing an Operating System. I am currently stuck at not being able to compile C code into output files, then further linking them with ld
When I run my make file, this error pops up:
/usr/local/i386elfgcc/bin/i386-elf-gcc -g -ffreestanding -c kernel/kernel.c -o kernel/kernel.o
/usr/local/i386elfgcc/bin/i386-elf-gcc: /usr/local/i386elfgcc/bin/i386-elf-gcc: cannot execute binary file
make: *** [kernel/kernel.o] Error 126
This is the makefile
C_SOURCES = $(wildcard kernel/*.c drivers/*.c)
HEADERS = $(wildcard kernel/*.h drivers/*.h)
# Nice syntax for file extension replacement
OBJ = ${C_SOURCES:.c=.o}
# Change this if your cross-compiler is somewhere else
CC = /usr/local/i386elfgcc/bin/i386-elf-gcc
GDB = /usr/local/i386elfgcc/bin/i386-elf-gdb
LD = /usr/local/i386elfgcc/bin/i386-elf-ld
# -g: Use debugging symbols in gcc
CFLAGS = -g
# First rule is run by default
os-image.bin: boot/boot.bin kernel.bin
cat $^ > os-image.bin
# '--oformat binary' deletes all symbols as a collateral, so we don't need
# to 'strip' them manually on this case
kernel.bin: boot/kernelStart32.o ${OBJ}
${LD} -o $# -Ttext 0x1000 $^ --oformat binary
# Used for debugging purposes
kernel.elf: boot/boot_32bit_kernel_entry.o ${OBJ}
${LD} -o $# -Ttext 0x1000 $^
run: os-image.bin
qemu-system-i386 -fda os-image.bin
# Open the connection to qemu and load our kernel-object file with symbols
debug: os-image.bin kernel.elf
qemu-system-i386 -s -fda os-image.bin &
${GDB} -ex "target remote localhost:1234" -ex "symbol-file kernel.elf"
# Generic rules for wildcards
# To make an object, always compile from its .c
%.o: %.c ${HEADERS}
${CC} ${CFLAGS} -ffreestanding -c $< -o $#
%.o: %.asm
nasm $< -f elf -o $#
%.bin: %.asm
nasm $< -f bin -o $#
clean:
rm -rf *.bin *.dis *.o os-image.bin *.elf
rm -rf kernel/*.o boot/*.bin drivers/*.o boot/*.o
I have built GCC etc to the path: /usr/local/i386-elf-gcc
I am on macOS Monterey 12.4 (Intel - x86_64) and have all dependencies installed
I have tried looking everywhere for this problem, trying different flags and everything, however the problem still persisted
It means that the compiler you built doesn't run on the system you are running it on. You have to decide whether you want to do native compiling in which case you would build a compiler that runs on the target and also generates output for the target. This is how the compilers you usually use always work.
If you create that kind of compiler then you have to run make on the target since that's where you build the compiler to run.
Or, you can create a cross-compiler. A cross-compiler runs on your local system, but builds output that runs on the target system.
In your case, if you want to compile code on your MacOS system but generate binary files that run on a different system, you need a cross-compiler.
I am trying to run some old Fortran code of my project team in ubuntu 16.04. I have not done any modifications to the existing code.
All I have done is installed gfortran, opened a terminal, and went to the file location using "cd" command. Here I have many files, but just consider this three, a script file compile.sh, and two makefiles counter.make and remail.make.
In compile.sh
make -f counter.make
make -f remail.make
In counter.make
SOURCE_APPLI=../SOURCES_COUNTERFLOW/
SOURCES_f77 = $(SOURCE_APPLI)table.f
TARGET = unst.e
OBJECTS = $(SOURCES_f77:.f=.o)
COMPILE = f77 -f
.f90.o :
$(COMPILE1) -o $*.o -c $*.f90
.f.o :
$(COMPILE) -o $*.o -c $*.f
$(TARGET) : $(OBJECTS)
$(COMPILE) $(OBJECTS) -o $#
del :
$(DELETE) $(OBJECTS)
In remail.make
SOURCE_APPLI= ../SOURCES_COUNTERFLOW/
$(SOURCE_APPLI)grcom.f
TARGET = remail.e
OBJECTS = $(SOURCES_f77:.f=.o)
COMPILE = f90
.f90.o :
$(COMPILE) -o $*.o -c $*.f90
.f.o :
$(COMPILE) -o $*.o -c $*.f
$(TARGET) : $(OBJECTS)
$(COMPILE) $(OBJECTS) -o $#
del :
$(DELETE) $(OBJECTS)
When I run compile.sh, I got an error as shown below
f77: error: unrecognized command line option â-fâ
counter.make:29: recipe for target 'unst.e' failed
make: *** [unst.e] Error 1
make: 'remail.e' is up to date.
So my question is what is the difference with and without using -f option in the f77 command line?
The f77 manual page at https://www.unix.com/man-page/v7/1/f77/ says
-f Use a floating point interpreter
(for PDP11's that lack 11/70-style floating point).
If you are not on a PDP-11, it appears that this option would perhaps not be useful at all in the first place.
Probably still review the local documentation, ideally for the system where this set of Makefiles was once created.
GNU Fortran 77 appears to use this option to specify various language options, but then it would not be useful on its own (it takes arguments like -fdollar-ok to enable something called "dollar ok", for example. See the linked manual for an extensive list of these options and their meaning).
Here's my makefile:
assemblera: main.o parsingA.o parsingC.o symbolTable.o
gcc -o assemblera main.o parsingA.o parsingC.o symbolTable.o
main.o: main.c parsingA.h parsingC.h symbolTable.h
gcc -c main.c
parsingA.o: parsingA.c parsingA.h
gcc -c parsingA.c
parsingC.o: parsingC.c parsingC.h
gcc -c parsingC.c
symbolTable.o: symbolTable.c symbolTable.h
gcc -c symbolTable.c
clean:
rm *.o assemblera
Now for the problem: with Windows command prompt I can easily generate all the .o files and .exe file, and if I run the latter it works as intended. Now, if I use the cygwin terminal, I can give the instructions to generate the object files / the exe, but those do not appear nowhere in the folder and no error is returned. Also, if I use the make command, it returns this error:
gcc -c main.c
make: *** [Makefile:5: main.o] Error 1
(I did put tabs in front of every "gcc" and "rm"). I know next to nothing about makefiles and cygwin.
Basically I am trying to make a simple make file that creates a lexer.o and then a driver.o file combining them into an executable.
Code below shows what has been tried. Running it in Windows powershell using GNU make.
.PRECIOUS = driver.cpp lexer.h lexer.cpp
lexer.o: lexer.cpp lexer.h
g++ -o $# -c lexer.cpp
driver.o: driver.cpp lexer.h
g++ -o $# -c driver.cpp
lex.exe: lexer.o driver.o
g++ -o $# $^
clean:
$(RM) *.o lex.exe
Here is what output is given. I was expecting it to create the lexer.o file, but instead it cannot "find" the file it was supposed to create.
g++ -o lexer.o -c lexer.cpp
process_begin: CreateProcess(NULL, g++ -o lexer.o -c lexer.cpp, ...)
failed.
make (e=2): The system cannot find the file specified.
make: *** [lexer.o] Error 2
It ended up just being a G++ installation problem. I swapped over to Ubuntu and reinstalled everything and it worked fine.
I am having trouble compiling using make in windows 7 with gcc and the gsl library. It occurs only when using make (when I type the compilation commands manually into the cmd line, it compiles correctly). I found some posts where people had similar errors from gcc, but none where it worked when typing normally, but not when using make. The contents of my Makefile are shown below:
#Compiler
COMP=gcc
# Compiler Flags. -Wall turns on all warnings
FLAGS=-Wall
# GSL include file dir
INCLUDES=GnuWin32/include
# GSL Libraries directory
LIB=GnuWin32/lib
# Library Flags
LFLAGS=-lgsl -lgslcblas -lm
# Target Program
EXE=ex2.1.exe
# Dependencies needed for $(PROGRAM)
OBJ=ex2.1.o
# List of source files for objects
SRC=ex2.1.c
# List with types of files to be cleared by clean:
TRASH=*.exe *.o
# I/O files to be cleaned with 'very clean' target
#IOFILES= *.dat *.out *.csv *.mod
all: $(SRC) $(EXE)
$(EXE): $(OBJ)
$(COMP) -L/$(LIB) $(OBJ) $(LFLAGS) -o $(EXE)
$(OBJ): $(SRC)
$(COMP) -I/GnuWin32/include -c ex2.1.c
#$(COMP) -I/$(INCLUDES) -c $(SRC)
clean:
del $(TRASH)
If I type make with only the ex2.1.c present in the directory, I get the following output and error:
gcc -I/GnuWin32/include -c ex2.1.c
gcc: error: CreateProcess : No such file or directory
make: *** [ex2.1.o] Error 1
However, if I first type "gcc -I/GnuWiun32/include -c ex2.1.c", ex2.1.o is created successfully with no error. If then type 'make' I get the following output/error:
gcc -L/GnuWin32/lib ex2.1.o -lgsl -lgslcblas -lm -o ex2.1.exe
gcc: fatal error: -fuse-linker-plugin, but liblto_plugin-0.dll not found
compilation terminated
make: *** [ex2.1.exe] Error 1
But if I manually enter "gcc -L/GnuWin32/lib ex2.1.o -lgsl -lgslcblas -lm -o ex2.1.exe" then the executable compiles and runs like it should, so the problem seems to be with how make is calling gcc? My PATH variable contains the paths to both make.exe as well as gcc.exe, so I am not sure what I do not set up correctly. Does anyone have an idea of what may be wrong? Thanks.