I am trying to use create a project for LPC1769 on LPCXpresso. I have a C file calling
#include <string.h>
int main()
{
//some stuff
strnlen(SomeString, someInt);
}
to which I get an error:
Undefined reference to 'strnlen'
The weird part is that there is no problem with strcpy, strncpy or other common string functions.
I am building for a Cortex-M3 processor
Compiler used is: arm-none-eabi-gcc
In Eclipse, I have ticked the MCU linker option : No startup or default libs
I am running Eclipse on Ubuntu
While it may be easy enough to bypass this by just using strlen, I am actually facing a problem using a library which uses strnlen, and I don't want to mess with the library source.
The strnlen function was (until fairly recently) a Linux-specific function (some documentation such as the GNU libc manual still says that it is a "GNU extension"). The current manual page says it is part of POSIX.1-2008. Since you are cross-compiling, it is possible that the target machine's runtime library does not have this function. A forum posting from 2011 said just that.
I add the same problem and I found out that using -std=gnu++11 compiler flag solves it.
The following may work for you (since strnlen() is not a part of the runtime lib).
Define your own/local version of the strnlen().
int strnlen(char *param, int maxlen)
{
// Perform appropriate string manipulation ... as needed.
// Return what you need.
};
You want this include instead:
#include <string.h>
The difference between <> and "" is that <> searches for header files in your systems include folder. The "" searches for header files in the current directory and in any other include folders specified by -I directory
Related
I know how to compile a C application without linking any library using GCC in bare metal embedded application just setting up the startup function(s) and eventually the assembly startup.s file.
Instead, I am not able to do the same thing in Windows (I am using MINGW32 GCC). Seems that linking with -nostdlib removes also everything needed to be executed before main, so I should write a specific startup but I did not find any doc about that.
The reason because I need to compile without C std lib is that I am writing a rduced C std lib for little 32 bits microcontrollers and I would like to test and unit test this library using GCC under Windows. So, if there is an alternative simplest way it is OK for me.
Thanks.
I found the solution adding -nostdlib and -lgcc together to ld (or gcc used as linker). In this way the C standard lib is not automatically linked to the application but everything needed to startup the application is linked.
I found also that the order of these switches matters, it may not work at all, signal missing at_exit() function or work without any error/warning depending by the order and position of the options.
I discovered another little complication using Eclipse based IDEs because there are some different approaches in the Settings menu so to write the options in the right order I needed to set them in different places.
After that I had a new problem: I did not think that unit test libraries require at least a function able to write to stdout or to a file.
I found that using "" and <> forces the compiler and linker to use the library modules I want by my library and the C standard library.
So, for instance:
#include "string.h" // points to my library include
#include <stdio.h> // points to C stdlib include
permits me to test all my library string functions using the C stdlib stdout functions.
It works both using GCC and GCC Cross Compilers.
I have compiled the gnu standard library and installed it in $GLIBC_INST.
Now, I try to compile a very simple programm (using only one #include : #include <stdio.h>):
gcc --nostdinc -I$GLIBC_INST/include foo.c
The compilation (preprocessor?) tells me, that it doesn't find stddef.h.
And indeed, there is none in $GLIBC_INST/include (nor is there one in /usr/include). However, I found a stddef.h in /usr/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/include.
Why is that file not under /usr/include? I thought it belonged to the standard c library and should be installed in $GLIBC_INST/include.
How can I compile my foo.c with the newly installed standard library when it doesn't seem to come with a stddef.h?
Edit: Clarification
I feel that the title of this question is not optimal. As has been pointed out by some answers, there is not a requirement for stddef.h to be in /usr/include (or $GLIBC_INST/include, for that matter). I do understand that.
But I am wondering how I can proceed when I want to use $GLIBC_INST. It seems obvious to me (although I might be wrong here) that I need to invoke gcc with --nostdinc in order to not use the system installed header files.
This entails that I use -I$GLIB_INST/include. This is clear to me.
Yet, what remains unclear to me is: when I also add -I/usr/lib/gcc/x86..../include, how can I be sure that I do have in fact the newest header files for the freshly compiled glibc?
That's because files under /usr/include are common headers that provided by the C library, for example, glibc, while the files at /usr/lib/gcc are specific for that particular compiler. It is common that each compiler has their own different implementation of stddef.h, but they will use the same stdio.h when links to the installed C library.
When you say #include <stddef.h> it does not require that /usr/include/stddef.h exists as a file on disk at all. All that is required of an implementation is that #include <stddef.h> works, and that it gives you the features that header is meant to give you.
In your case, the implementation put some of its files in another search path. That's pretty typical.
Why is that file not under /usr/include?
Because there's absolutely no requirement for standard headers to be located at /usr/include/.
The implementation could place them anywhere. The only guarantee is
that when you do #include <stddef.h>, the compiler/preprocessor correctly locates and includes it. Since you disable that with -nostdinc option of gcc, you are on your own (to correctly give the location of that header).
Lets say this is my program :
#include <math.h>
#include <stdio.h>
int main(void) {
double a = sqrt(20);
return 0;
}
When we use a math function we have to include the header "math.h" file.
But when it comes to compiling with gcc, we have also have to specify the shared libraries that our program uses (in this case it is the math library). To do that we use the option -lm.
The option to add to use a shared library is not always clear (I know that it starts with -l which means lib, but I don't have any easy idea to get the letters which gets after the -l, except searching on google).
My question is : Is there a simple way that I can use to get the right option to use with gcc using the header that I have included ??
Is there a simple way that I can use to get the right option to use with gcc using the header that I have included ??
Yes: read the man page, or other documentation that came with the library.
I have a C program where I get function pointers "dynamically" by the function name (ie. I pass the function name as a string and get a pointer to the function). I already do this in Linux using dlopen and dlsym and I suppose it will also work in any other Unix-like with dlfcn.
The problems began when I tried to port this program to Windows using MinGW. When I try to find the name using "GetProcAddress(handle, symbol_name), where "symbol_name" is the name of my callback function and "handle" is a handle to the current executable returned by "GetModuleHandle(NULL)", I get nothing because the MinGW name mangling adds an "_" to my symbol name.
The obvious solution (prefix an "_" to the symbol I want) seems a bit 'dangerous' for portability (may the compiler add two underscores for some of them? I don't know), so, I ask:
There is a better way to prevent the compiler from name-mangling my symbols? (or a subset of them, only the callbacks I need to find dynamically);
Or a way to make GetProcAddress find them even when mangled?
I also tried the option -fno-leading-underscore, but it removed the mangling of all the external symbols too, making the program impossible to link with the stdlib, etc. (also, the warnings on the documentation are a bit scary).
Also, please note that I'm using pure C -- there is no C++ in any part of my code -- and all my code lives in a single ".exe".
TIA
Not sure what your problem is, as I can't reproduce it with the simplest DLL example I can think of:
/* hello_dll.c */
#include <stdio.h>
__declspec(dllexport) void hello ( void )
{
puts ( "Hello, DLL!");
}
/* hello_exe.c */
#include <windows.h>
#include <stdio.h>
int main () {
typedef void (*pfunc)(void);
HANDLE hself;
pfunc hello;
hself = GetModuleHandle(NULL);
hello = (pfunc)GetProcAddress(hdll, "hello");
hello();
return 0;
}
This is the command line using MinGW gcc with no special flags, and it all works:
gcc src\hello_dll.c src\hello_exe.c -o bin\hello.exe
$ bin\hello.exe
Hello, DLL!
$ gcc --version
gcc (GCC) 4.5.0
It doesn't work without the __declspec(dllexport) if you are getting the function from yourself; when creating a DLL with gcc -shared it doesn't appear to be necessary, but appears to be required if exporting a function from an exe.
C doesn't use name mangling. In particular, it doesn't add any type information to the name (unlike C++). But some platforms make a small modification to the name like prefixing the underscore. And unlike C++, it's only platform specific but not compiler specific.
On all the platforms I've seen so far, I've only seen either no modification or the leading underscore.
So I propose you use some ifdefs to derive whether the current platform uses an underscore or not.
(Windows has another small modification for certain Windows API functions for distinguishing the ANSI from the Unicode version. But that's probably not relevant for your case.)
Maybe somebody else can point at some official documentation for the C ABI on different platforms.
Suppose I have an ELF binary that's dynamic linked, and I want to override/redirect certain library calls. I know I can do this with LD_PRELOAD, but I want a solution that's permanent in the binary, independent of the environment, and that works for setuid/setgid binaries, none of which LD_PRELOAD can achieve.
What I'd like to do is add code from additional object files (possibly in new sections, if necessary) and add the symbols from these object files to the binary's symbol table so that the newly added version of the code gets used in place of the shared library code. I believe this should be possible without actually performing any relocations in the existing code; even though they're in the same file, these should be able to be resolved at runtime in the usual PLT way (for what it's worth I only care about functions, not data).
Please don't give me answers along the line of "You don't want to do this!" or "That's not portable!" What I'm working on is a way of interfacing binaries with slightly-ABI-incompatible alternate shared-library implementations. The platform in question is i386-linux (i.e. 32-bit) if it matters. Unless I'm mistaken about what's possible, I could write some tools to parse the ELF files and perform my hacks, but I suspect there's a fancy way to use the GNU linker and other tools to accomplish this without writing new code.
I suggest the elfsh et al. tools from the ERESI (alternate) project, if you want to instrument the ELF files themselves. Compatibility with i386-linux is not a problem, as I've used it myself for the same purpose.
The relevant how-tos are here.
You could handle some of the dynamic linking in your program itself. Read the man page for dlsym(3) in particular, and dlopen(3), dlerror(3), and dlclose(3) for the rest of the dynamic linking interface.
A simple example -- say I want to override dup2(2) from libc. I could use the following code (let's call it "dltest.c"):
#define _GNU_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <dlfcn.h>
int (*prev_dup2)(int oldfd, int newfd);
int dup2(int oldfd, int newfd) {
printf("DUP2: %d --> %d\n", oldfd, newfd);
return prev_dup2(oldfd, newfd);
}
int main(void) {
int i;
prev_dup2 = dlsym(RTLD_NEXT, "dup2");
if (!prev_dup2) {
printf("dlsym failed to find 'dup2' function!\n");
return 1;
}
if (prev_dup2 == dup2) {
printf("dlsym found our own 'dup2' function!\n");
return 1;
}
i = dup2(1,3);
if (i == -1) {
perror("dup2() failed");
}
return 0;
}
Compile with:
gcc -o dltest dltest.c -ldl
The statically linked dup2() function overrides the dup2() from the library. This works even if the function is in another .c file (and is compiled as a separate .o).
If your overriding functions are themselves dynamically linked, you may want to use dlopen() rather than trusting the linker to get the libraries in the correct order.
EDIT: I suspect that if a different function within the overridden library calls an overridden function, the original function gets called rather than the override. I don't know what will happen if one dynamic library calls another.
I don't seem to be able to just add comment to this question, so posting it as an "answer". Sorry about it, doing that just to hopefully help other folks who search an answer.
So, I seem to have similar usecase, but I explicitly find any modification to existing binaries unacceptable (for me), so I'm looking for standalone proxy approach: Proxy shared library (sharedlib, shlib, so) for ELF?