I am on RHEL 6.0 and got hold of the source code for join command(hopefully from the right source!!). I rarely work on a C code and hence finding this difficult. I am trying to compile and run the C code for join, but running into compile time errors.
g++ join.c
join.c:19:20: error: config.h: No such file or directory
join.c:25:20: error: system.h: No such file or directory
join.c:27:25: error: hard-locale.h: No such file or directory
join.c:28:24: error: linebuffer.h: No such file or directory
join.c:29:24: error: memcasecmp.h: No such file or directory
join.c:30:19: error: quote.h: No such file or directory
join.c:31:21: error: stdio--.h: No such file or directory
join.c:32:22: error: xmemcoll.h: No such file or directory
join.c:33:21: error: xstrtol.h: No such file or directory
join.c:34:22: error: argmatch.h: No such file or directory
Since I am not aware of where to find these libraries(I did google for each one and they are spread all over different websites), can anyone please guide me as to how I can link these libraries together and compile the source code of join command?
This is not a linking problem as you suggest. Instead, you get these errors because g++ can't find these files: config.h, system.h, ..., that are #included (indirectly) by join.c.
What you could do is find these files on your system, and then add as many -I<directory> options behind the g++ as there were directories you found these files in. Do man g++ for more info.
You'll also need to find the where the libraries are you need to link against. So you'll need to specify more than -I's.
On the other hand, aren't there 'configure' or other package files? Normally you don't have to specify compiler flags (like this -I) by hand. Instead, it's common that for example Makefile's are generated from such a configuration file, after which you just have to type make.
I advise you to get someone that has done this before, because you don't seem to understand the basics of C program compilation. This can cost you a lot of your precious time without results. But good luck anyway!
Perhaps you don't have everything in place to compile your code. Try installing the build-essential package.
sudo yum install build-essential
On a relevant note, I'm not aware of the script join.c but if you are looking for a way to concatenate a bunch of files together, you can do cat FILE1 FILE2 FILE3 > BIG_FILE where FILE1 FILE2 FILE3 are the files you want to join them. Under RHEL 6.0, you can use asterisks too, if there is a pattern. For example, cat FILE.00* > BIG_FILE
Related
I am trying to cross compile a simple program with the arm toolchain. And stdio library points to another library, which results in the following error:
/home/sansari/tools/arm-eabi-4.7/bin/arm-eabi-gcc hello.c -o hello
In file included from hello.c:3:0:
/home/sansari/tools/arm-eabi-4.7/bin/../lib/gcc/arm-eabi/4.7/include-fixed/stdio.h:50:23: fatal error: sys/cdefs.h: No such file or directory
compilation terminated.
make: *** [hello] Error 1
At first, I thought this file is in some subdirectory of the toolchain, and I need to include the folder for this library in my makefile. But a quick tree output says that it is not. So given that I have used this toolchain successfully for a larger project, I know it is copied from somewhere. So my question is how do I add it to this project please? And what is the appropriate place to copy it from? I am trying to understand why it is not in the toolchain folders that I have, and how I should add it to my project please.
#Olaf - You have been very helpful; I however have a little more learning curve. But I do understand what you are instructing. I know I have the libraries in my build system since have built for this platform successfully. I even know that it is in my WORKING_DIRECTORY. What I do not know is if I can copy a folder and address the issue entirely or do I need to keep compiling and see what errors I get. That is do it incrementally. For example, one of the files, which was missing was cdefs.h. And I was able to find it in the folder:
/home/sansari/ndk/android-ndk-r10d/platforms/android-19/arch-arm/usr/include/sys/cdefs_elf.h
So I copied it over and the build process proceeded to the next stage. I do like to know if I should perhaps have copied the entire /sys or /include directory or compared the /include directory of my source and make sure all the files are also in the destination directory also. And that way I can avoid having to compile a number of times.
But nevertheless, I proceeded with copying one file at a time. The last error I got is:
/home/sansari/tbt/tools/arm-eabi-4.7/bin/../lib/gcc/arm-eabi/4.7/include/stdint.h:3:26: fatal error: stdint.h: No such file or directory
And I look in the include directory; I see a file call stdint.h
What do you make of that? Does that make sense to you? I am confused by this error. How can I get this error when the file is in the directory. Basically it seems make is saying this file does not exist when it does.
I did find This post also, which seems to say what you are saying. I just need to know what is the best way to address it.
#Olaf - I really appreciate all your help. I was able to get through all the library errors by putting an include statement in my makefile. Now the linker is giving me errors as follows:
/home/sansari/tbt/tools/arm-eabi-4.7/bin/arm-eabi-gcc -I../../ndk/android-ndk-r10d/platforms/android-19/arch-arm/usr/include hello.c -o hello
/home/sansari/tbt/tools/arm-eabi-4.7/bin/../lib/gcc/arm-eabi/4.7/../../../../arm-eabi/bin/ld: cannot find crt0.o: No such file or directory
/home/sansari/tbt/tools/arm-eabi-4.7/bin/../lib/gcc/arm-eabi/4.7/../../../../arm-eabi/bin/ld: cannot find -lc
collect2: error: ld returned 1 exit status
make: *** [hello] Error 1
update - I searched for a solution for the above errors. The first error is discussed here and -nostartfiles switch seems to work for me for now. I found this link that talks about libc.a being the fix for the error about not finding -lc. So I found an appropriate copy of libc.a and passed the location to the linker. The program compiles, but I get one last warning as follows:
warning: cannot find entry symbol _start; defaulting to 00000000000080dc
For which this link suggested using --entery-main switch. So now I have an executable. I want to thank you again. If you do see any problem in what I have done, please post something for me. it is gonna take a while for me to get this executable on my device.
I previously made this question and got a light at the end of the tunnel by the response that I got. But now that I found the problem, I don't understand it. I don't have root priv. Whenever I run the program I get segmentation fault and a core file. When I analyse it with dbx I get this
reading symbolic information ...
Segmentation fault in QRspec_newFrame at line 546 in file "" ($t1)
couldn't read "qrspec.c"
How come he can't find qrspec.c if that file was included on the process of generating the lib? (I wasn't involved on that process so I have no idea if it went 100% but I gave the .tar with all the files). Also that file belongs to libqrencode.
Compiling:
xlc_r7 -g qrgen.c -lqrencode -L/usr/local/lib -I/usr/local/include
I'm starting to bealive it can't find the file because there is a .so symbolic link missing on the /usr/local/lib folder. Could that be it? (Only .a , .la and .so.3 in there)
I think my problem is similiar to this one but I can't install the lib again unless that is the real problem.
Machine: Unix AIX powerpc model: IBM,9117-MMB
xlc version: 12.01.0000.0000
I'm guessing you need to tell dbx where to find your source files
From man dbx
-I Directory
(Uppercase i) Includes directory specified by the Directory variable in the list of directories searched for source files. The default is to look for source files in the following directories:
* The directory the source file was located in when it was compiled. This directory is searched only if the compiler placed the source path in the object.
* The current directory.
* The directory where the program is currently located.
I found the problem... The installation of the lib generated problems and caused the symbolic links to exist as a simple file and the library just wasn't there...
This is the missing file "/usr/local/lib/libqrencode.so.3.4.4" which is the code itself... I was looking at the files and didn't notice it because there was a file called libqrencode.so.3.4 but this file was supose to be a symbolic link to libqrencode.so.3.4.4 since libqrencode.so.3.4.4 didn't exist, instead of the symbolic link failing, it created a empty file with that same name...
Since I am just now learning C I want to be able to create one "Projects" folder in XCode to hold all my mini files that I create to learn different stuff. Such as HelloWorld.c IfElse.c WhleLoop.c however I am having a major issue. I can't run these different main files without getting the error below...
duplicate symbol _main error:
linker command failed with exit code 1 (use -v to see invocation)
What is the easiest way to go about this? I want to only have one project open in Xcode to be able to very easily reference my previous files and just create little tests files that do different learning things before I really get into C.
Can anyone suggest a workaround?
-Henry
The best is to write Makefile
Open one new file with the name "Makefile"
In that file type as given below:
all:hello ifelse while
hello:HelloWorld.o
<tab>cc -o hello HelloWorld.o
ifelse:IfElse.o
<tab>cc -o ifelse IfElse.o
WhileLoop.o:WhileLoop.o
<tab>cc -o while WhileLoop.o
The above given is a makefile which are used for creating multiple executables under a single project in Linux. It is also available in standard sdks like Eclipse. For any new file you want compile add it to the makefile as shown for other files.
Once you finish writing the makefile enter the command make in the terminal.
Everything will get compiled and different executables get created.
To know more about the makefile you can refer to the below link:
http://www.cs.wmich.edu/~sdflemin/instr_pgs/make/index.html
I'm trying to accelerate a key function in a c project (not c++) using CUDA.
For some reason, i can't get the Makefile's to recognise the .cu extension when I change the name of one of the files to .cu.
It's using a configure script and .am/.in/.deps files, which I don't really understand all that well, but basically I grepped references to file.c and changed them all to file.cu, but it produces a file.o: File Not Found error.
Top level make file
https://www.dropbox.com/s/g282qvbdu8pdas0/Makefile
Src folder makefile
https://www.dropbox.com/s/b4pq026od8gauqi/Makefile
The search command I used was
grep -R -i "file.c"
and I simply changed them all to file.cu, then re-ran configure, make clean, make all - result is File Not Found.
I suppose it must be something to do with extensions being ignored/accepted by the Makefile, but as it's been a long time since I've programmed in C and I've never used such complex Makefiles I don't know how to fix it.
Any ideas?
*PS Also, file.cu has compile errors at the moment, but the error message I'm getting is File Not Found, so I think that's not the problem.
You need to have a rule to build o file from a cu file:
cudafile.o: cudafile.cu
nvcc $(NVCC_FLAGS) -c %< -o $#
So you also need to specify the rule for the cu file, and use nvcc for compilation.
The following guide seems to cover it...
http://mcclanahoochie.com/blog/2011/02/automake-and-cuda/
Actually, most of the advice given in the link seems unnecessary for basic compilation, but for some reason I found that when I re-created the config file using autoconf it worked. No explanation comes to mind.
I am working on a project which requires me to download and use this. Inside the downloaded folder, when extracted I am presented with three things:
A folder called "include"
A folder called "src"
A file called "Makefile"
After some research, I found out that I have to navigate to the directory which contains these files, and just type in the command make.
It seemed to install the library in my system. So I tried a sample bit of code which should use the library:
csp_conn_t * conn;
csp_packet_t * packet;
csp_socket_t * socket = csp_socket(0);
csp_bind(socket, PORT_4);
csp_listen(socket, MAX_CONNS_IN_Q);
while(1) {
conn = csp_accept(socket, TIMEOUT_MAX);
packet = csp_read(conn, TIMEOUT_NONE);
printf(ā%S\r\nā, packet->data);
csp_buffer_free(packet);
csp_close(conn);
}
That's all that was given for the sample server end of the code. So I decided to add these to the top:
#include <csp.h>
#include <csp_buffer.h>
#include <csp_config.h>
#include <csp_endian.h>
#include <csp_interface.h>
#include <csp_platorm.h>
Thinking I was on the right track, I tried to compile the code with gcc, but I was given this error:
csptest_server.c:1: fatal error: csp.h: No such file or directory
compilation terminated.
I thought I may not have installed the library correctly after all, but to make sure, I found out I could check by running this command, and getting this result:
find /usr -iname csp.h
/usr/src/linux-headers-2.6.35-28-generic/include/config/snd/sb16/csp.h
/usr/src/linux-headers-2.6.35-22-generic/include/config/snd/sb16/csp.h
So it seems like the csp.h is installed, maybe I am referencing it incorrectly in the header include line? Any insight? Thanks a lot.
The make command is probably only building the library, but not installing it. You could try sudo make install. This is the "common" method, but I recommend you to check the library's documentation, if any.
The sudo command is only necessary if you have no permissions to write the system's include and library directories, which may be your case.
Another possibility (instead of installing the library) is telling GCC the location of the library's source code and generated binaries (by means of the -I and -L options of the gcc command.
That Makefile will not install anything, just translate the source into a binary format.
The csp.h in the Linux kernel has nothing to do with your project, it's just a naming collision, likely to happen with three letter names.
In your case, I would presume you need to add the include directory to the compilation flags for your server, like gcc -I/path/to/csp/include/csp csptest_server.c.
(Next, you'll run into linker errors because you'll also want to specify -L/path/to/csp -lcsp so that the linker can find the binary code to link to.)