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
Related
I am trying to compile a file Mv.c like - g++ microtime.c Mv.c
It gives an error - v.c:2:10: fatal error: microtime.h: No such file or directory 2 | #include <microtime.h>
My current directory has both microtime.h and microtime.c and Mv.c includes microtime.h
I am not sure how to go about compiling it.
Since my main program Mv.c is using microtime.h do I need to compile microtime.c first and pass it as an argument to g++?
I got it compiled by using the command g++ -I. Mv.c microtime.o
where microtime.o I generated using g++ -c microtime.c
I am not sure why this command works and why we need to specify the extra -I. option when I have already created the compiled object file microtime.o
If you write #include <microtime.h>, the compiler uses its list of system directories to look for the header file. By the option -I you add a directory to this list, and the compiler is happy.
To include project-local header files, use #include "microtime.h".
Read the chapter "Directory Options" in GCC's documentation to learn more.
I'm trying to use this C library using gcc Apple LLVM version 8.0.0 (clang-800.0.42.1) on macOS Sierra. I've done the following steps:
make libquirc.so
Copied libquirc.so into my project directory
gcc -o quirc_test quirc_test.c -L. -l libquirc.so.1.0
It produces the error:
quirc_test.c:1:10: fatal error: 'quirc.h' file not found
#include <quirc.h>
^
1 error generated.
quirc_test.c
#include <quirc.h>
This is the first time I've tried to do anything in C and other related questions about compiling with the link flag didn't seem to help as seen above.
C is somewhat primitive. Shared object libraries do not contain the declaration of the API they implement - at least not in enough detail or a form that the compiler can understand.
You'll need the header file quirc.h somewhere you can find it. You could just copy it into the current directory just like the library, but you'll need a minor adjustment to the include statement.
#include "quirc.h"
If the included file is surrounded by double quotes instead of angle brackets, it will first look in the source code directory instead of the system header directories.
An alternative is to install the library somewhere e.g. /usr/local. Your library would go in /usr/local/lib nd your header in /usr/local/include. If you do that, use the -I directive on the compiler command line to tell the compiler where to look for the header e.g.
cc -I/usr/local/include -L/usr/local/lib -lquirc quirc_test.c
I'm trying to compile a Fortran source code (which I didn't write) using gfortran. The code calls a C function, drand48.c, whose source is in the same folder.
Problem is, when I do:
gfortran -o filename.exe filename.f drand48.c
I get the following error message:
drand48.c:1:20: fatal error: stdlib.h: No such file or directory
#include <stdlib.h>
^
compilation terminated.
Now, I am sure that I HAVE the standard library, because I use it all the time in C (I just compiled another C code with `#include <´ and it goes).
What can I do? Thanks!
PS My OS is OSX
You cannot use the same compiler to compile C and Fortran. Instead, you should first compile objects from each of the source files with the appropriate compiler:
gcc -c -o ccode.o ccode.c
gfortran -c -o fcode fcode.f
The -c option tells the compiler in this case to create objects, not an executable.
Then link these objects. Because Fortran needs to link to its runtime library, use the Fortran compiler which you used to create the Fortran objects to link all objects and create an executable:
gfortran ccode.o fcode.o -o myprogram
If you have to do this frequently, you should set up a Makefile.
I'm trying to execute the below program-
Within APUE.3E -> filedir -> filetype.c (this comes by default when I downloaded APUE.3E. I didn't make any changes)
but when I compile this is the error I'm receiving:
myramya~/Documents/apue.3e/filedir$ gcc filetype.c -lm -o filetype
/tmp/cchPKE7K.o: In function main':
filetype.c:(.text+0x94): undefined reference to err_ret'
collect2: error: ld returned 1 exit status
I'm using Linux Ubuntu. I have installed APUE.3E in Documents folder. I have administrator permissions. I wrote a simple Hello.c program and executed using:
$ gcc hello.c -o hello
and it worked without any issues.
Your hello example works compiling in a single step with gcc because it does not call any functions in other files (except functions in the standard C library which allways gets linked in).
Your filetype.c makes calls to a function err_ret which is not within filetype.c but in some other source file.
When compiling bigger programs the work is usually done in two steps: First source files are compiled into object files by making one call to gcc with the flag -c for each source file. Then all object files are linked together with a single call to gcc with all object files. It is also possible to put object files together into libraries. Usually a Makefile is used to compile bigger projects.
Your specific case with apue.3e is well explained here: https://unix.stackexchange.com/questions/105483/compiling-code-from-apue
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.