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.
Related
I am currently working on a project in C. I searched through multiple similar questions, but the answers are too unspecific for me, because I haven't really worked with C in the past.
My problem is the following:
The project consists of multiple different files. I am editing the file "pm3/armsrc/epa.c". Now i need to use a function from another file. This function is located in "pm3/common/mbedtls/sha1.c.
I tried to include this file in my epa.c like this:
#include "../common/mbedtls/sha1.h"
It seems to work and I could access the function. But after starting the Makefile in order to compile the project (which worked fine until now), i get an error message in epa.c:
undefined reference to `mbedtls_sha1_ret'
In other answers it seems to be a problem with the linker and the gcc call, but the Makefile, which calls multiple other Makefiles in order to build everything are all pre-made. As you can see here in the "make all" output, the file with the needed function is successfully builded:
Compiling mbedtls
cd ../common/mbedtls && make all
make[2]: Entering directory '/pm3/common/mbedtls'
ar rcs libmbedtls.a aes.o asn1parse.o asn1write.o base64.o bignum.o ctr_drbg.o entropy_poll.o entropy.o error.o timing.o ecp.o ecp_curves.o certs.o camellia.o blowfish.o cipher_wrap.o cipher.o cmac.o des.o ecdsa.o md.o md_wrap.o md5.o oid.o pem.o arc4.o pk.o pk_wrap.o pkwrite.o pkcs5.o pkcs12.o pkparse.o platform.o platform_util.o rsa.o rsa_internal.o sha1.o sha256.o sha512.o threading.o x509.o x509_crl.o x509_crt.o
ranlib libmbedtls.a
make[2]: Leaving directory '/pm3/common/mbedtls'
If someone could maybe take a look at the Makefiles or if someone has another possibility in order to get the compilation working, I would be very happy. Here is the link to the git-repo: https://github.com/Proxmark/proxmark3. My knowledge of Makefiles is very low, so I don't see any problems in the pre-made ones.
Without diving into the makefile, you did use the include directive correctly,
but probably the executable's make command (link) did not include the
library you now used (and refernced).
Look for the place in the makefile where there is a call to the linker
(gcc or maybe g++ or ld), and see if the library (probably mbedtls) appears on the
list of files being linked.
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...
I am trying to modify the dynamic linker provided in the libc6(2.15-0ubuntu20.2) on a 64 bit Ubuntu machine.
So currently my code is using the same version of the glibc library. (I have downloaded the source code for the same and working on it). My question is that is it possible to modify and build only the linker source code which is present in glibc\elf\ directory without building the entire glibc library.
And if it is possible how can I make my test program to switch using the new version of dynamic linker that I have build myself instead of using the default unmodified linker.
Any pointers or suggestions are highly appreciated.
(If any more information is needed please let me know)
EDIT::
#constantius
I followed the steps in the post linked by you to build ld.so.
But I am getting following error on the make and I checked ld.so is not there in the elf.
The error is::
/var/services/homes/abhi/test/ld/eglibc-build/elf/librtld.os: In function `generic_getcwd':
/var/services/homes/abhi/test/ld/eglibc-2.15/elf/../sysdeps/posix/getcwd.c:356: undefined reference to `__closedir'
/var/services/homes/abhi/test/ld/eglibc-2.15/elf/../sysdeps/posix/getcwd.c:368: undefined reference to `__fdopendir'
/var/services/homes/abhi/test/ld/eglibc-2.15/elf/../sysdeps/posix/getcwd.c:384: undefined reference to `__readdir'
/var/services/homes/abhi/test/ld/eglibc-2.15/elf/../sysdeps/posix/getcwd.c:397: undefined reference to `rewinddir'
/var/services/homes/abhi/test/ld/eglibc-2.15/elf/../sysdeps/posix/getcwd.c:528: undefined reference to `__closedir'
/var/services/homes/abhi/test/ld/eglibc-2.15/elf/../sysdeps/posix/getcwd.c:490: undefined reference to `__closedir'
collect2: error: ld returned 1 exit status
make[2]: *** [/var/services/homes/abhi/test/ld/eglibc-build/elf/ld.so] Error 1
make[2]: Leaving directory `/var/services/homes/abhi/test/ld/eglibc-2.15/elf'
make[1]: *** [elf/subdir_lib] Error 2
make[1]: Leaving directory `/var/services/homes/abhi/test/ld/eglibc-2.15'
make: *** [all] Error 2
NOTE With the same infrastructure I can build and install the full GLIBC so I dont think there is an error with the infrastructure.
-- I guess the error is some where related to editing Makeconfig to all-subdirs = csu elf gmon io misc posix setjmp signal stdlib string time.
--Any suggestions on this..
SOLVED
Need to add dirent in the all-subdirs list in addition to what we edited before
Thanks
Citing this page. In case you don't get something, comment please — I'll try to explain.
Building
To compile Glibc (ld.so cannot be compiled independently) download and unpack Glibc source tarball.
1 Make sure the version of Glibc you downloaded is the same as the system's current one.
2 Make sure the environmental variable LD_RUN_PATH is not set.
3 Read the INSTALL and make sure all necessary tool chains (Make, Binutils, etc) are up-to-date.
4 Make sure the file system you are doing the compilation is case sensitive, or you will see weird errors like
/scratch/elf/librtld.os: In function `process_envvars':
/tmp/glibc-2.x.y/elf/rtld.c:2718: undefined reference to `__open'
...
5 ld.so should be compiled with the optimization flag on (-O2 is the default). Failing to do so will end up with weird errors (see Question 1.23 in FAQ)
6 Suppose Glibc is unpacked at
/tmp/glibc-2.x.y/
Then edit /tmp/glibc-2.x.y/Makefile.in: Un-comment the line
# PARALLELMFLAGS = -j 4
and change 4 to an appropriate number.
7 Since we are only interested in ld.so and not the whole Glibc, we only want to build the essential source files needed by ld.so. To do so, edit /tmp/glibc-2.x.y/Makeconfig: Find the line started with
all-subdirs = csu assert ctype locale intl catgets math setjmp signal \
...
and change it to
all-subdirs = csu elf gmon io misc posix setjmp signal stdlib string time
8 Find a scratch directory, say /scratch. Then
$ cd /scratch
$ /tmp/glibc-2.x.y/configure --prefix=/scratch --disable-profile
$ gmake
Since we are not building the entire Glibc, when the gmake stops (probably with some errors), check if /scratch/elf/ld.so exists or not.
ld.so is a static binary, which means it has its own implementation of standard C routines (e.g. memcpy, strcmp, etc) It has its own printf-like routine called _dl_debug_printf.
Testing
You can run the ld-linux.so directly. It will complain that this is probably not what you want (but you want exactly this) and offer you list of options with which you can run it. See also man ld-linux.so for debugging flags, i.e. there's LD_DEBUG environment variable you can define to see ld-linux.so debugging output.
While I'm not clear on whether the build system for glibc makes doing this easy, there's no fundamental reason why you can't build and use the glibc dynamic linker without building libc.so. I would peruse the top-level Makefile for ways to make this work.
As for testing it, there are two methods:
Explicitly invoke the dynamic linker to run a program, as in:
./ld-linux.so.2 a.out args ...
When linking your program, specify an alternate dynamic linker pathname (which will get stored in its PT_INTERP program header) by passing this option to the compiler driver:
-Wl,-dynamic-linker,/path/to/alternate/ld-linux.so.2
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
So, most of the times I'm testing if every include is correct on a given C/C++ code, I have a makefile with a gcc/g++ call with proper -I option for searching headers on specific directories (like every program) when I'm compiling sources to headers.
However, if the included directory is not correct and an undefined header appears (e.g. foo.h has #include and was not found), the gcc/g++ will just spit a bunch of errors for every include I have of that foo.h header for all other sources I'm compiling afterwards (and I'm already using -Werror -Wfatal-errors to make gcc/g++ to stop).
So, my question is simple: how can I tell makefile stop after the first error of the type "No such file or directory" it finds? It is really annoying it continue to compile sources and sources, giving me hundreds of errors just for a repeated error I already understood.
It probably continues because you told it to. See the following two options of GNU make:
-k, --keep-going Keep going when some targets can't be made.
-S, --no-keep-going, --stop
Turns off -k.
Put the header files into a variable and use that variable as a dependency. The following snippet will not build anything until the specified headers exist.
HEADERS=test.h other.h /usr/include/special.h
all: $(HEADERS) $(BINPROGS)
[... all other rules go here as usual ...]
*.h:
echo found $#
The ".h:" simply prints out each header that is found before any building even starts. The makefile itself stops if a header cannot be found (and it will stop before trying to compile anything).
I believe that that is what you wanted?
you can write a shell script to check for error conditions before running the make script.