I am compiling fortran code on both my macbook pro (10.9.5, 2.3GHz, 8 GB RAM) and on my Dell Latitude E6400 (Windows 7, #.26GHz, 4GB RAM). The code runs in about 12.2 minutes on the mac and 32.6 minutes on the pc. I am using gfortran (4.9.0 on the mac, 4.10.0 on the pc). My make file is:
{
# Makefile for NRMMII
F95 = gfortran
#FINCLUD=
#OBJPATH=./objG95/
# .F90 invokes the fpp preprocessor whereas .f90 does not
# the preprocessor expands source code "macros" and symbolic definitions prior to compilation
# it makes no difference with nrmm30
# compiler flags
#FLAGSC = -ffree-form -fall-intrinsics -fcheck=all -m64 -c
FLAGSC = -std=f95 -v -ffree-form -O0 -fall-intrinsics -fcheck=all -march=native -flto \
-funroll-loops -fno-protect-parens -fstack-arrays -c
# link flags
FLAGSL = -g
#-static Only for windows machines
OBJS = module_nrmmdefs.f90 module_nrmmcntc.f90 module_nrmmdevc.f90 \
module_nrmmdrvc.f90 module_nrmmploc.f90 module_nrmmprdc.f90 \
module_nrmmscnc.f90 module_nrmmstsc.f90 module_nrmmsumc.f90 \
module_nrmmterc.f90 module_nrmmtppc.f90 module_nrmmvehc.f90 \
module_nrmmvers.f90 module_nrmmvppc.f90 module_nrmm_global.f90 \
module_nrmmpbuffs.f90 module_nrmmxmlc.f90 \
main.f90 areal.f90 auxout.f90 crlsno.f90 diag.f90 histogram.f90\
input.f90 miscg95.f90 plow.f90 road.f90 summary.f90 terrain.f90\
vpp.f90 spclxml2.f90 nrmmxml.f90
# special files in nrmmii_misc
# module_spclapfc.f90 spclapf.f90 module_spclresc.f90 spclres.f90 \
# spcljody.f90 spclnode.f90 spclnode1.f90 spclnull.f90 spcltrfs.f90\
# module_nrmmxmlc.f90 nrmmxml.f90 spclxml2.f90 spcltrav.f90
# This defines the compile rules
.SUFFIXES: .o .f90
.f90.o:
$(F95) $(FLAGSC) $*.f90
nrmm30:
$(F95) $(FLAGSL) -o $# $(OBJS)
}
Does anyone have any suggestions as to why the pc version is running so much slower?
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 tried to compile without makefile with equations.com gcc
i have bunch of f90, and lib.a
Since a lot of files, i can't use like gfortran *.f90 *.f so i am using gfortran -c filename.f90 each in a batch file.
This create alot of .mod files and .o files.
[code]
gfortran -c -I INCLUDE -O3 -ffast-math -march=znver3 ALLOCATED_ARRAY_DATA.f90
gfortran -c -I INCLUDE -O3 -ffast-math -march=znver3 ALLOCATED_MEMORY.f90
gfortran -c -I INCLUDE -O3 -ffast-math -march=znver3 ALLOCATED_MEMORY_Interface.f90
[/code]
How to link it to exe with ld with several file?
[code]
ld #"names.rsp"
[code]
that names.rsp contains
[code]
../superlu/lib/superlu.a \
../superlu/src/c_fortran_dgssv.o \
../superlu/lib/libopenblas.a \
ALLOCATED_ARRAY_DATA.o \
ALLOCATED_MEMORY.o \
ALLOCATED_MEMORY_Interface.o \
/o mys.exe
[/code]
I think better to study cross-compiling-linking using CMAKE and building using jom or make, than to do it manual.
I'm working on a simple application that will be running on a Intel Galileo's board as UEFI app. I've started with a "Hello, World" app and tested it under qemu-system-i386 and it works well. Then, I've run it under Galileo EFI Shell and it stuck (nothing happend and never returned anything - like a never-ending loop). I know that Intel Galileo's Quark processor is a i586 architecture. It shouldn't be a problem to run application compiled for i386 under i586, due to the backward compatibility, am I right? Or am I missing something?
I'm using Ubuntu 14.04 (32-bit) for development with GCC 5.4.0 (default). Also, I'm using gnu-efi in version 3.0.4.
Should I build a cross-compiler? Will it resolve all of my problems? Is it necessary?
Here is a sample code:
#include <efi.h>
#include <efilib.h>
EFI_STATUS EFIAPI efi_main(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable) {
InitializeLib(ImageHandle, SystemTable);
Print(L"Hello, World!\n");
return EFI_SUCCESS;
}
Here is my Makefile:
ARCH = ia32
OBJS = src/main.o
HEADERS =
TARGET = build/main.efi
EFIINC = lib/gnu-efi/inc
EFIINCS = -I$(EFIINC) -I$(EFIINC)/$(ARCH) -I$(EFIINC)/protocol
LIB = lib/gnu-efi/$(ARCH)/lib
EFILIB = lib/gnu-efi/gnuefi
EFI_CRT_OBJS = $(EFILIB)/crt0-efi-$(ARCH).o
EFI_LDS = $(EFILIB)/elf_$(ARCH)_efi.lds
CFLAGS = $(EFIINCS) -ffreestanding -fno-stack-protector -fpic -fshort-wchar -mno-red-zone -Wall -masm=intel
LDFLAGS = -nostdlib -znocombreloc -T $(EFI_LDS) -shared -Bsymbolic -L $(EFILIB) -L $(LIB) $(EFI_CRT_OBJS)
all: $(TARGET)
build: $(TARGET)
src/%.so: $(OBJS) $(HEADERS)
ld $(LDFLAGS) $(OBJS) -o $# -l:libefi.a -l:libgnuefi.a
build/%.efi: src/%.so
objcopy -j .text -j .sdata -j .data -j .dynamic \
-j .dynsym -j .rel -j .rela -j .reloc \
--target=efi-app-$(ARCH) $^ $#
run:
qemu-system-i386 bin/OVMF.fd -hda fat:build
.PHONY: all build run
I'm trying to launch a client for a school project that has an AI developed in Lua, I have added liblua.so in a /lib/ folder at the root of my program's folder.
After compiling and launching said program, I get the following error:
./zappy_ai: error while loading shared libraries: liblua.so: cannot open shared object file: No such file or directory
From what I understand I must do something at the compilation for my program to know where my shared library is located.
Here's the relevant part of my Makefile:
CXX = g++
BASE_FLAGS = -Wall -Wextra -Iincludes
AI_NAME = zappy_ai
AI_PATH = ./sources/client/
AI_FLAGS = $(BASE_FLAGS) \
-L./lib/ \
-I./includes/client/ \
-I./include/ \
-std=c++11 \
AI_LDFLAGS = -llua
AI_SRCS = main.cpp \
Client.cpp \
Params/Params.cpp \
Params/Option.cpp \
SocketTCP.cpp \
Misc/Error.cpp
AI_OBJS = $(addprefix $(AI_PATH), $(AI_SRCS:.cpp=.cpp.o))
%.cpp.o : %.cpp
#printf "%b[Compilation]%b %-50s" $(BLUE) $(RESET) $<
#$(CXX) $(FLAGS) -c $< -o $#
#printf "%bOK%b\n" $(GREEN) $(RESET)
$(AI_NAME) : FLAGS = $(AI_FLAGS)
$(AI_NAME) : $(AI_OBJS)
#$(CXX) $^ -o $# $(AI_LDFLAGS)
#printf "%b[Message]%b AI compilation done\n\n" $(YELLOW) $(RESET)
What should I add in order to be able to launch my program and have it find my shared library?
tldr:
$ LD_LIBRARY_PATH="$LD_LIBRARY_PATH:./lib" ./zappy_ai
Longer explanation:
You've dynamically linked
zappy_ai
against
./lib/liblua.so
by using
LDFLAGS = -L./lib/
and
LDLIBS = -llua
The resulting zappy_ai executable requires that same ./lib/ to be present within the LD_LIBRARY_PATH environment variable when the dynamic linker/loader attempts to resolve the -llua symbols that zappy_ai uses.
I need to compile VASP 5.3.5 on a Cray XC MPP machine. The system has the Gnu, Intel and Cray compiling environments available. There is also a choice of Intel MKL or Cray LibSci for BLAS, LAPACK, ScaLAPCK.
Which is the best compiler to use, the best numerical library to use and the Makefile options to use?
Tests on ARCHER (http://www.archer.ac.uk) have shown that using the Intel compiler with Intel MKL and FFTW produce the best performance and the most stable build of VASP 5.3.5 on the Cray XC30 system.
Full compilation instructions can be found at:
http://www.archer.ac.uk/documentation/software/vasp/compiling_5-3-5-phase2.php
Briefly, the procedure is:
module swap PrgEnv-cray PrgEnv-intel
module load fftw
module load cray-pe-hugepages2M
Modify the library makefile to have the following options:
CPP = gcc -E -P -C $*.F >$*.f
FC=ftn
CFLAGS = -O3
FFLAGS = -O3 -unroll -ip -no-prec-div -xAVX
FREE = -free
Build the library (assuming makefile is called "makefile.cray_xc_intel.lib"):
cd vasp.5.lib
make -f makefile.cray_xc_intel.lib
Move to the main source code directory:
cd ../vasp.5.3
Setup the preprocessor options in the Makefile (this is for the multiple K-points version):
CPP = $(CPP_) -DMPI -DHOST=\"CrayXC-Intel\" \
-DNGZhalf \
-DLONGCHAR \
-Dkind8 \
-DCACHE_SIZE=2000 \
-Davoidalloc \
-DRPROMU_DGEMV \
-DMPI_BLOCK=100000 \
-Duse_collective \
-Drandom_array \
-DscaLAPACK
Set the makefile compilation options:
FC=ftn
FCL=$(FC)
CPP_ = ./preprocess <$*.F | cpp -P -C -traditional >$*$(SUFFIX)
FFLAGS = -free -march=corei7-avx -assume byterecl -m64
OFLAG = -O3 -ip -fno-alias -unroll-aggressive -opt-prefetch -use-intel-optimized-headers -no-prec-div
OFLAG_LOW = -O1 -g -ftz
OBJ_LOW = broydon.o
Set the makefile linear algebra library options for Intel MKL:
MKL_PATH = $(MKLROOT)/lib/intel64
BLAS=
LAPACK=
BLACS=
SCA=
LIB = ../vasp.5.lib/linpack_double.o -L../vasp.5.lib -ldmy \
${MKL_PATH}/libmkl_blas95_lp64.a ${MKL_PATH}/libmkl_lapack95_lp64.a \
${MKL_PATH}/libmkl_scalapack_lp64.a \
-Wl,--start-group ${MKL_PATH}/libmkl_intel_lp64.a \
${MKL_PATH}/libmkl_sequential.a ${MKL_PATH}/libmkl_core.a \
${MKL_PATH}/libmkl_blacs_intelmpi_lp64.a -Wl,--end-group -lpthread -lm
Finally, set the makefile options for linking FFTW:
FFT3D = fftmpiw.o fftmpi_map.o fftw3d.o fft3dlib.o
Now build the code (assuming makefile is called "makefile.cray_xc_intel"):
make -f makefile.cray_xc_intel