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...
Related
Preface: I am very new to c and CLion, so apologies in advance if my phrasing is very wrong.
Essentially, I have an assignment that involves two c files (a "main", and one performing a conversion between imperial and metric units). The main c file simply #include-s the conversion file, performs a function within the conversion file, and prints the resulting value to the user. Simple enough, but I keep getting a message every time I try to run it:
"undefined reference to 'conversion'"
I have tried to suss out the problem, and my only idea relates to the banner at the top of conversion.c which says "This file does not belong to any project target, code insight features may not work properly.". I do not understand why I receive this message, because conversion.c and main.c are both within the main project directory, and this setup worked perfectly fine in my previous assignment.
I have searched for solutions online, and the only one that seemed to make sense was to update my CMakeLists.txt file to include add_executable(project conversion.c). This is what my CMakeLists.txt file looks like before I add this line:
cmake_minimum_required(VERSION 3.12)
project(project C)
set(CMAKE_C_STANDARD 11)
add_executable(project main.c)
However, when I add it, I get the error:
CMake Error at CMakeLists.txt:7 (add_executable):
add_executable cannot create target "directory" because another
target with the same name already exists. The existing target is an
executable created in source directory
"/home/john_s/CLionProjects/project". See documentation for
policy CMP0002 for more details.
Presumably this is because the previous line I have (add_executable(project main.c)) is linking to the same directory, but I have no idea how to resolve this. Any suggestions?
From cmake manual:
add_executable(< name> [WIN32] [MACOSX_BUNDLE]
[EXCLUDE_FROM_ALL]
[source1] [source2 ...])
Adds an executable target called to be built from the source files listed in the command invocation. (The source files can be omitted here if they are added later using target_sources().)
So to combile a single executable using two source files, you just use:
add_executable(target_name source1.c source2.c)
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'm trying to build the linux kernel and would like to understand a few things:
I have added a new file (b.c) to a certain directory with the intention of having the file compiled in. The Makefile has been updated accordingly. While compiling the file, an error is thrown saying that a certain header (a.h) is not found. However, other files in the same directory use a.h without any issues.
I have observed that .o.cmd file get created for all files except b.c. Is this a prerequisite for the headers to be correctly included? Does this file have any significance to the issue I'm facing?
For eg: I added 'async_infra.o' to this line in the Makefile:
uml_gre-objs := uml_gre_kern.o uml_gre_user.o async_infra.o
uml_gre_user.c includes the header that I'd like to be included in async_infra.c
Any suggestions on what's missing and how to address the issue will be appreciated.
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
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.)