I'm having an issue with a makefile compiling and I'm not sure where to start diagnosing this. It was generated for a colleague's OS X system, and I'm trying to implement it on my linux system. It worked on the OS X computer. I've updated library locations to represent where they live on my computer - and this is likely the biggest source of error, as gfortran procedure shouldn't be different, no?
The included files: file0.i, ... fileN.i all live in the same directory as the makefile.
I'm certain if I could compile the first object file I could get through the rest and complete my PhD or save the world or something.
A snippet of the file follows:
# %W% %G%
# Makefile for directory ~/Documents/workstuff/project/program
#
fflags = -O3 -I. -I/usr/local/include -frecord-marker=4 -ffree-form
## -fdefault-real-8 -fdefault-double-8
lflags = -L/usr/local/lib -lnetcdf -lnetcdff
# for debugging, use these options
fflags = -g
lflags = -g
chem = ~/Documents/workstuff/project/chem
main.o: $(chem)/code/main.f file0.i file1.i file2.i
gfortran -c $(fflags) $(chem)/code/main.f
And I receive the following error:
~/Documents/workstuff/project/program/chem/code/main.f:11: Error: Can't open included file 'file0.i'
makefile:14: recipe for target 'main.o' failed
make: *** [main.o] Error 1
I thought it might be an executable issue, so we went from 644 to 744:
username$ file file0.i
file0.i: ASCII text
username$ stat -c '%A %a %n' file0.i
-rwxr--r-- 744 file0.i
Still same error. Double-check that my flags are pointing to the right place:
username$ nf-config --fflags
-I/usr/local/include
username$ nf-config --flibs
-L/usr/local/lib -lnetcdff -lnetcdf -lnetcdf
For what its worth, file0.i contains the following, which I have of course filled with nonsense numbers for sharing online:
$Id: file0.i,v 1.12 2012/12/31 04:25:23 username Exp $
PARAMETER (NLT=19,NHT=51,DZETA=0.5/3.,Psurf=100.)
PARAMETER (NLT1=NLT+1,NHT1=NHT+2,NLT2=3*NLT+1,NHT2=4*NHT+1)
PARAMETER (NDYEAR=33,NTN=75,NTCV=14,NLV=21,NPOL=8,NGSP=3)
PARAMETER (NDIST=111,TD1=110.,NVC=1,NVSP=1,NVTIME=3)
Does anything obvious stick out to anyone?
I do not know gfortran very well, so I may be completely wrong, but for gcc, if a C source file contains:
#include <foo.h>
and if gcc is called with -I., foo.h will be searched in the same directory as the source file, not in the directory where you call gcc from. Example:
$ ls foo
bar.c bar.h
$ cat foo/bar.c
#include <bar.h>
int main(int argc, char **argv) {
return 0;
}
$ gcc -I. foo/bar.c
foo/bar.c:1:10: error: 'bar.h' file not found with <angled> include; use "quotes" instead
#include <bar.h>
^~~~~~~
"bar.h"
1 error generated.
$ gcc -Ifoo foo/bar.c
$
So, it could be that you should put your header files in the same directory as your source file or use a -I<path> where <path> is the absolute path of where you call gfortran from.
Related
I am following the LLVM tutorial : Kaleidoscope: Code generation to LLVM IR, which will use LLVM libraries like LLVMContext, Module and so on. Different from the tutorial, I am trying to write the lexer, parser and code generator in different source file and link them into one executable file.
Here is my compile command on the Ubuntu 20.04:
clang++ -g -O3 -I /home/therlf/LLVM/include -I ./ -I /home/therlf/LLVM_Temp/llvm/include `llvm-config --cxxflags --ldflags --system-libs --libs all` ast/CallExprAST.o ast/NumberExprAST.o ast/PrototypeAST.o ast/FunctionAST.o ast/BinaryExprAST.o ast/VariableExprAST.o lexer/lexer.o logger/logger.o parser/parser.o main.cpp -o main
But I only get lots of "undefined error".
Here are some of them:
/usr/bin/ld: /tmp/main-2b71c8.o:(.data+0x0): undefined reference to `llvm::DisableABIBreakingChecks
/home/therlf/MyProject/tmp/ast/CallExprAST.cpp:6: undefined reference to `llvm::Module::getFunction(llvm::StringRef) const'
/home/therlf/LLVM/include/llvm/IR/InstrTypes.h:1112: undefined reference to `llvm::Instruction::Instruction(llvm::Type*, unsigned int, llvm::Use*, unsigned int, llvm::Instruction*)'
/usr/bin/ld: /home/therlf/LLVM/include/llvm/IR/InstrTypes.h:977: undefined reference to `llvm::VectorType::get(llvm::Type*, llvm::ElementCount)'
At first I thought it's including path's error. But when I compiled and ran the source file in the tutorial successfully, which is just a whole source file with everything packed into file, I knew the including path is nothing wrong.
I have searched for this question, and some blogs say that you should link them with lld and use the -fuse-ld=lld in the compile command. But I don't have lld, and the clang++ doesn't know the argument -fuse-ld, which will report an error. The blog says that you should have lld as long as you have installed LLVM. In fact here are what I got: LLVM tools
And I know the llvm-link is used to link IR file, not the object file compiled from cpp source file.
Here is my LLVM version:
10.0.0svn
And here is my Makefile:
SOURCES = $(shell find ast kaleidoscope lexer logger parser -name '*.cpp')
HEADERS = $(shell find ast kaleidoscope lexer logger parser -name '*.h')
OBJ = ${SOURCES:.cpp=.o}
CC = clang++
# -stdlib=libc++ -std=c++11
CFLAGS = -g -O3 -I /home/therlf/LLVM/include -I ./ -I /home/therlf/LLVM_Temp/llvm/include
LLVMFLAGS = `llvm-config --cxxflags --ldflags --system-libs --libs all`
.PHONY: main
main: main.cpp ${OBJ}
${CC} ${CFLAGS} ${LLVMFLAGS} ${OBJ} $< -o $#
clean:
rm -r ${OBJ}
%.o: %.cpp ${HEADERS}
${CC} ${CFLAGS} ${LLVMFLAGS} -c $< -o $#
In fact, I follow the project structure from the repository : ghaiklor/llvm-kaleidoscope and the Makefile is nearly identical.
Sincerely thank you for your answers!
I have sloved this problem by exchanging my linker ld with linker lld.
You should install lld first by this command in ubuntu if you can't find it in the LLVM/tools directory like I did.
sudo apt-get update
sudo apt-get -y install lld
And then you can add -fuse-ld=lld to your compile command
or you can
cd /usr/bin
ln -s /path/to/ld.lld /usr/bin/ld
This should work if everything goes well.
But I still can't figure out the reason behand this situation :-(
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.
CMake seems to prepend linker flags at the front of a GCC compilation command, instead of appending it at the end. How to make CMake append linker flags?
Here is a simple example to reproduce the problem.
Consider this C++ code that uses clock_gettime:
// main.cpp
#include <iostream>
#include <time.h>
int main()
{
timespec t;
clock_gettime(CLOCK_REALTIME, &t);
std::cout << t.tv_sec << std::endl;
return 0;
}
This is a CMakeLists.txt to compile the C++ file above:
cmake_minimum_required(VERSION 2.8)
set(CMAKE_EXE_LINKER_FLAGS "-lrt")
add_executable(helloapp main.cpp)
Note that we have added -lrt since it has the definition of clock_gettime.
Compiling this using:
$ ls
CMakeLists.txt main.cpp
$ mkdir build
$ cd build
$ cmake ..
$ make VERBOSE=1
Which throws up this error, even though you can see -lrt in the command:
/usr/bin/c++ -lrt CMakeFiles/helloapp.dir/main.cpp.o -o helloapp -rdynamic
CMakeFiles/helloapp.dir/main.cpp.o: In function `main':
main.cpp:(.text+0x15): undefined reference to `clock_gettime'
collect2: ld returned 1 exit status
make[2]: *** [helloapp] Error 1
The problem here is the C++ compilation command generated by CMake has -lrt prepended at the front. The compilation works fine if it had been:
/usr/bin/c++ CMakeFiles/helloapp.dir/main.cpp.o -o helloapp -rdynamic -lrt
How to make CMake append the linker flags at the end?
In general you can't (I think), but in the specific case that you want to link against a particular library, you should be using the syntax
target_link_libraries(helloapp rt)
instead. CMake knows that this corresponds to passing -lrt on the linker command line.
I'm trying to compile a program using a third party library, Omnet++ in my case. Apparently "make" does not find a library, but the path it uses is correct as you can see (in the sense that I can see the library under omnet++ source tree)
pv135168:basic Bob$ opp_makemake
Creating Makefile in /Users/Bob/Code/network_sim/basic... Makefile created, running "make depend" to add dependencies... opp_makedep -Y --objdirtree -I. -f Makefile -P\$O/ -- ./*.cc
pv135168:basic Bob$ make
g++ -c -g -Wall
-fno-stack-protector -m32 -DHAVE_PCAP -DXMLPARSER=libxml
-DWITH_PARSIM -DWITH_NETBUILDER -I.
-I/Users/Bob/Code/omnetpp-4.1/include -o out/gcc-debug//txc1.o txc1.cc g++ -m32 -Wl,-rpath,/Users/Bob/Code/omnetpp-4.1/lib -Wl,-rpath,. -o out/gcc-debug//basic out/gcc-debug//txc1.o -Wl,-all_load
-L"/Users/Bob/Code/omnetpp-4.1/lib/gcc"
-L"/Users/Bob/Code/omnetpp-4.1/lib" -u _tkenv_lib -lopptkenvd
-loppenvird -lopplayoutd -u _cmdenv_lib -loppcmdenvd -loppenvird
-loppsimd -lstdc++
ld: library not found for -lopptkenvd
collect2: ld returned 1 exit status make: *** [out/gcc-debug//basic]
Error 1 pv135168:basic Bob$
It's looking in the following directories for a file called libopptkenvd.dylib or libopptkenvd.a:
/Users/Bob/Code/omnetpp-4.1/lib/gcc
/Users/Bob/Code/omnetpp-4.1/lib
Is that file in one of those directories (or in the standard directories like /usr/lib)? I don't see an indication of that in your output.
I have a working setup, where all files are in the same directory (Desktop). The Terminal output is like so:
$ gcc -c mymath.c
$ ar r mymath.a mymath.o
ar: creating archive mymath.a
$ ranlib mymath.a
$ gcc test.c mymath.a -o test
$ ./test
Hello World!
3.14
1.77
10.20
The files:
mymath.c:
float mysqrt(float n) {
return 10.2;
}
test.c:
#include <math.h>
#include <stdio.h>
#include "mymath.h"
main() {
printf("Hello World!\n");
float x = sqrt(M_PI);
printf("%3.2f\n", M_PI);
printf("%3.2f\n", sqrt(M_PI));
printf("%3.2f\n", mysqrt(M_PI));
return 0;
}
Now, I move the archive mymath.a into a subdirectory /temp. I haven't been able to get the linking to work:
$ gcc test.c mymath.a -o test -l/Users/telliott_admin/Desktop/temp/mymath.a
i686-apple-darwin10-gcc-4.2.1: mymath.a: No such file or directory
$ gcc test.c -o test -I/Users/telliott_admin/Desktop/temp -lmymath
ld: library not found for -lmymath
collect2: ld returned 1 exit status
What am I missing? What resources would you recommend?
Update: Thanks for your help. All answers were basically correct. I blogged about it here.
$ gcc test.c /Users/telliott_admin/Desktop/temp/mymath.a -o test
edit: gcc only needs the full path to the library for static libraries. You use -L to give a path where gcc should search in conjunction with -l.
To include the math libraries, use -lm, not -lmath. Also, you need to use -L with the subdirectory to include the library when linking (-I just includes the header for compiling).
You can compile and link with:
gcc test.c -o test -I/Users/telliott_admin/Desktop/temp /Users/telliott_admin/Desktop/temp/mymath.a
or with
gcc test.c -o test -I/Users/telliott_admin/Desktop/temp -L/Users/telliott_admin/Desktop/temp -lmymath
where mymath.a is renamed libmymath.a.
See link text for comments (search for "bad programming") on the practices of using -l:
In order for ld to find a library with -l, it must be named according to the pattern libyourname.a. Then you use -lmymath
So, there is no way to get it to take /temp/mymath.a with -l.
If you named it libmymath.a, then -L/temp -lmymath would find it.