I am trying to compile this with tcc
and I have these errors
Before the error it was "Cannot find pthread.h" and I copied
pthread,pthread_compat,pthread_signal,pthread_time,pthread_unistd header files from gcc include dir to tcc include dir ! ... and now I have the above errors.. I think is something with linking but I don't know exactly :/
Copying header files from the gcc include dir was neither required nor a good idea; better use tcc option: -Igcc-include-dir-path.
Anyway, now you will need to link your program to the pthread library in order complete build. Look in the gcc directory for a file named pthread.a or pthread.lib, there you have the gcc libraries directory. Then when you get this directory path, add the following options to the tcc command-line: -Lgcc-library-dir-path -pthread.
Related
I have made a python "compiler" that helps me compile my C code with gcc, for example it fetches all my header files and source files. So my cmd commmand is gcc {headers} {source} -o {build_dir}/build.exe -lgdi32 -w where {headers} is a string like -Ipath/to/headers/foo.h -Ipath/to/other/headers.foo2.h and where {source} is the same but with .c files. It seems that the compiler finds the header files, but when compiling my code it fails.
(btw I am trying to make a portable programming environment on my flash drive so python and mingw are both portable)
This is the error: fatal error: test.h: No such file or directory #include "test.h"
My project tree
I have put the third party library files into the mingw directory instead of making a custom one and then linking it in the gcc command.
The -I option takes the path to the directory containing the header files or more specifically with an argument -Ipath and a directive #include<a/b.h>, the compiler will try to look for the header file at path/a/b.h.
So you should not give it paths to header files, only to the directory or directories relative to which you use include directives.
I am trying to compile the gjh solver - written in C - into an executable file in windows. It is available on netlib
I downloaded the c file and am using gcc compiler via WinGW on windows' command prompt. Trying to compile the gjh.c file directly gave me an error that says:
gjh.c:33:21: fatal error: getstub.h: No such file or directory
#include "getstub.h"
compilation terminated.
I assumed that compiling gjh.c requires the dependency getstub.h.
getstub.h is not the only dependency required, there are other dependencies, namely: arith.h, asl.h, funcadd.h, and stdio1.h. All of these files are available on the same link where I found getstub.h. However, arith.h0 and stdio1.h0 are available instead of arith.h and stdio1.h.
Are these files the same? I tried to rename the .h0 files to .h and tried to compile gjh.c, but I got this error:
collect2.exe: error: ld returned 1 exit status
Are the two files the same? If not, is there any way for me to compile the gjh solver successfully into an .exe?
If that's the only problem in compiling, try using the -I switch in gcc:
gcc -I/my/path/to/include/files -o gjh gjh.c
the -I switch hints to gcc where to find your #include files.
I am not sure about the stdio1.h. I think your approach to rename is OK but that reference to external functions such as Sprintf. You need to link with a library defining that. If you know where it comes from, use the -L and -l switch in gcc for that:
gcc -I/my/path/to/include/files -L/my/path/to/library -lnameoflibrary \
-o gjh gjh.c
When I compiled my program and ran it, I got a a symbol lookup error. I was doing this:
$ gcc -o parts parts.c -lnettle
$ ./parts
$ ./parts: symbol lookup error: ./parts: undefined symbol: nettle_pbkdf2
My code included these header files:
#include <nettle/pbkdf2.h>
#include <nettle/hmac.h>
#include <pbkdf2-hmac-sha1.c>
I solved my problem by including the object files for the two included header files during gcc compilation.
$ gcc -o parts parts.c hmac.o pbkdf2.o -lnettle
The thing is, I don't understand what is going on and therefore why this works. Why must I include the .o files and not just the header files to avoid symbol lookup or undefined reference errors?
As Tobias mentioned, a header file tells the compiler what is done, the object file tells the compiler how it is done. You can see here what an object file is, but in reality it's just a precompiled version of a source file.
Truly, you were not actually getting compiler errors, but linker errors. It knew how to compile your source file, but it couldn't put everything together until it got the other object files.
I am trying to compile a C program which uses regexes on FreeBSD. I have checked in /usr/local/include and the file pcre.h is definitely there.
However, no matter what I do, I get the following compiler error:
/usr/home/myname/project/include/pcre_wrap.h:4:18: error: pcre.h: No such file or directory
What could be going wrong? My understanding of C libraries on Unix could be better...
As the comment above says you need to use #include. If this isn't working you may want to export an environment variable C_INCLUDE_PATH that points to the header file.
Failing that why not try adding -I/usr/local/include to your gcc call, something like gcc myfile.c -I/usr/local/include -o myexe
MPICH2 is installed in C:\Program Files\MPICH2. There are two subdirectories (of interest), \include which contains .h files, and \lib which contains .lib files.
The readme that comes with MPICH2 has the following instructions:
create a makefile
add –I...mpich2\include
add –L...mpich2\lib
add –lmpi
add the rules for your source files
compile
Since there are no other rules in my project, I don't create a makefile, I just go to the command line and try compiling like this:
g++ -I"C:\Program Files\MPICH2\include" main.cpp -L"C:\Program Files\MPICH2\lib" -lmpi
This gives me a fistful of undefined reference errors on every single MPI symbol in the code. I spent hours trying to fix it, juggling -I, -L and -l switches around, shuffling the order of the parameters, even copied all the .lib files into the same directory as my source, but nothing seems to work.
What kind of voodoo is needed to get this thing to link?
EDIT: I think I found the problem: here's an excerpt of the linker's output in verbose mode (adding -Wl,--verbose to the compile command):
attempt to open C:\Program Files\MPICH2\lib/libmingwex.dll.a failed
attempt to open C:\Program Files\MPICH2\lib/mingwex.dll.a failed
attempt to open C:\Program Files\MPICH2\lib/libmingwex.a failed
attempt to open C:\Program Files\MPICH2\lib/mingwex.lib failed
attempt to open C:\Program Files\MPICH2\lib/libmingwex.dll failed
attempt to open C:\Program Files\MPICH2\lib/mingwex.dll failed
attempt to open C:\Program Files\MPICH2\lib\libmingwex.a failed
Apparently, the linker adds a / instead of a \ to the directory names I supply it with (except when looking for the lib___.a format for some reason), which is obviously not a valid path. Is there any way to tell the linker to use backslashes instead of slashes?
This also caught my eye:
attempt to open /mingw/lib/libmingwex.a succeeded
So I tried compiling like this:
g++ -I"/Program Files/MPICH2/include" -L"/Program Files/MPICH2/lib" objManager.cpp ongom.cpp io.cpp main.cpp -lmpi -lcxx
But I still get the same undefined reference errors.
GCC is able to find your library. Otherwise it would report: cannot find -lmpi.
Somehow it happens that the routines cannot be found in that library. I managed to compile an example with this syntax:
g++ -I../include cpilog.c ../lib/mpi.lib ../lib/mpe.lib
I did that inside msys though. And my directory does not contain spaces.
After removing libmpi.a file, this also works:
g++ -I../include -L../lib cpilog.c -lmpi -lmpe
try adding -lmpicxx (the lib for the c++ bindings), and make sure the -l... come after the cpp source file *. this works for me:
g++ -Iinclude -Llib test/cxxpi.cpp -lmpicxx -lmpi
EDIT: re: "undefined reference to 'MPI_Comm_rank'": could it be that your are mixing up / using c and / instead of c++? MPI_Comm_rank seems to be the c binding - the c++ binding would be MPI::Comm::Get_rank(). maybe try compiling your program as c, or, if you want to use c++, using the proper bindings (see cxxpi.cpp in the examples dir)?
* http://newsgroups.derkeiler.com/Archive/Comp/comp.parallel.mpi/2006-08/msg00036.html
I had the similar problem resulting from linking 32-bit object files with 64-bit MPICH library. Linking with 32-bit libmpi.a solved the problem.
I had a similar issue with mingw: for those library files with a .lib ending, I had to put the name of the library without the ending (e.g. -llibboost_system-mgw34-mt when the filename is libbboost_system-mgw34-mt.lib). For library files with a .a ending, I had to put the name of the library excluding the starting "lib" and the trailing .a (e.g. -lws2_32 for libws2_32.a).
So in your case - try -llibmpi (or whatever your file is called without the .lib ending), perhaps it's the same issue.
from: http://www.mingw.org/node/98/revisions/358/view
Note: some paths were printed with “/” as the path separator while some other was printed with “\” as the path separator. I've substitued all with “/” as MinGW GCC accept both.
So I would not put too much time into finding a way to correct the path seperator. Is your library compiled for mingw?
perhaps: http://www.mingw.org/wiki/LibraryPathHOWTO helps you a bit further.