I am writing a jna wrapper for a c library, compiled using gcc under cygwin. Depending on how I execute the jna wrapper the java application either just hangs (if executed as unit test under eclipse) or terminates with an Invalid memory exception. The problem seems to occur only the the c library writes something to either stdout or stderr.
Here is my minimal (not) working example:
add.c
#include <stdio.h>
int add (int x, int y)
{
fprintf(stdout, "hello world\n" );
return x + y;
}
jna wrapper
public interface Add extends Library
{
Add INSTANCE = (Add) Native.loadLibrary("add", Add.class);
int add(int x, int y);
}
Compiling the c file under cygwin as follows:
gcc -g -Wall -c add.c
gcc -shared -o add.dll add.o
If I remove the fprintf line everything works fine. Both the add.dll and cygwin1.dll are in the java target folder.
You are using wrong syntax for fprintf. It is actually
int fprintf(FILE *restrict stream, const char *restrict format, ...);
You need to pass string format specifier(%s) too.
Related
So everyone probably knows that glibc's /lib/libc.so.6 can be executed in the shell like a normal executable in which cases it prints its version information and exits. This is done via defining an entry point in the .so. For some cases it could be interesting to use this for other projects too. Unfortunately, the low-level entry point you can set by ld's -e option is a bit too low-level: the dynamic loader is not available so you cannot call any proper library functions. glibc for this reason implements the write() system call via a naked system call in this entry point.
My question now is, can anyone think of a nice way how one could bootstrap a full dynamic linker from that entry point so that one could access functions from other .so's?
Update 2: see Andrew G Morgan's slightly more complicated solution which does work for any GLIBC (that solution is also used in libc.so.6 itself (since forever), which is why you can run it as ./libc.so.6 (it prints version info when invoked that way)).
Update 1: this no longer works with newer GLIBC versions:
./a.out: error while loading shared libraries: ./pie.so: cannot dynamically load position-independent executable
Original answer from 2009:
Building your shared library with -pie option appears to give you everything you want:
/* pie.c */
#include <stdio.h>
int foo()
{
printf("in %s %s:%d\n", __func__, __FILE__, __LINE__);
return 42;
}
int main()
{
printf("in %s %s:%d\n", __func__, __FILE__, __LINE__);
return foo();
}
/* main.c */
#include <stdio.h>
extern int foo(void);
int main()
{
printf("in %s %s:%d\n", __func__, __FILE__, __LINE__);
return foo();
}
$ gcc -fPIC -pie -o pie.so pie.c -Wl,-E
$ gcc main.c ./pie.so
$ ./pie.so
in main pie.c:9
in foo pie.c:4
$ ./a.out
in main main.c:6
in foo pie.c:4
$
P.S. glibc implements write(3) via system call because it doesn't have anywhere else to call (it is the lowest level already). This has nothing to do with being able to execute libc.so.6.
I have been looking to add support for this to pam_cap.so, and found this question. As #EmployedRussian notes in a follow-up to their own post, the accepted answer stopped working at some point. It took a while to figure out how to make this work again, so here is a worked example.
This worked example involves 5 files to show how things work with some corresponding tests.
First, consider this trivial program (call it empty.c):
int main(int argc, char **argv) { return 0; }
Compiling it, we can see how it resolves the dynamic symbols on my system as follows:
$ gcc -o empty empty.c
$ objcopy --dump-section .interp=/dev/stdout empty ; echo
/lib64/ld-linux-x86-64.so.2
$ DL_LOADER=/lib64/ld-linux-x86-64.so.2
That last line sets a shell variable for use later.
Here are the two files that build my example shared library:
/* multi.h */
void multi_main(void);
void multi(const char *caller);
and
/* multi.c */
#include <stdio.h>
#include <stdlib.h>
#include "multi.h"
void multi(const char *caller) {
printf("called from %s\n", caller);
}
__attribute__((force_align_arg_pointer))
void multi_main(void) {
multi(__FILE__);
exit(42);
}
const char dl_loader[] __attribute__((section(".interp"))) =
DL_LOADER ;
(Update 2021-11-13: The forced alignment is to help __i386__ code be SSE compatible - without it we get hard to debug glibc SIGSEGV crashes.)
We can compile and run it as follows:
$ gcc -fPIC -shared -o multi.so -DDL_LOADER="\"${DL_LOADER}\"" multi.c -Wl,-e,multi_main
$ ./multi.so
called from multi.c
$ echo $?
42
So, this is a .so that can be executed as a stand alone binary. Next, we validate that it can be loaded as shared object.
/* opener.c */
#include <dlfcn.h>
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char **argv) {
void *handle = dlopen("./multi.so", RTLD_NOW);
if (handle == NULL) {
perror("no multi.so load");
exit(1);
}
void (*multi)(const char *) = dlsym(handle, "multi");
multi(__FILE__);
}
That is we dynamically load the shared-object and run a function from it:
$ gcc -o opener opener.c -ldl
$ ./opener
called from opener.c
Finally, we link against this shared object:
/* main.c */
#include "multi.h"
int main(int argc, char **argv) {
multi(__FILE__);
}
Where we compile and run it as follows:
$ gcc main.c -o main multi.so
$ LD_LIBRARY_PATH=./ ./main
called from main.c
(Note, because multi.so isn't in a standard system library location, we need to override where the runtime looks for the shared object file with the LD_LIBRARY_PATH environment variable.)
I suppose you'd have your ld -e point to an entry point which would then use the dlopen() family of functions to find and bootstrap the rest of the dynamic linker. Of course you'd have to ensure that dlopen() itself was either statically linked or you might have to implement enough of your own linker stub to get at it (using system call interfaces such as mmap() just as libc itself is doing.
None of that sounds "nice" to me. In fact just the thought of reading the glibc sources (and the ld-linux source code, as one example) enough to assess the size of the job sounds pretty hoary to me. It might also be a portability nightmare. There may be major differences between how Linux implements ld-linux and how the linkages are done under OpenSolaris, FreeBSD, and so on. (I don't know).
I'm writing a file parser in C using gcc on Windows using MSYS2.
Using pacman I've downloaded the required libraries for using libbzip2.
For some reason, I can include the bzlib.h file and use the structures it contains, but not its functions.
Here's my code so far:
#include <stdio.h>
#include <stdlib.h>
#include <bzlib.h>
void init_decompress_stream(bz_stream *stream, char *next_in, unsigned int avail_in, char *next_out, unsigned int avail_out);
int main(){
// Open FILE
FILE *ptr;
ptr = fopen("example.bin", "rb");
// Read Metadata
int metadata[10];
fread(metadata, sizeof(int), 10, ptr);
// Init stream
bz_stream *stream;
unsigned int avail_in = metadata[0] * sizeof(char);
unsigned int avail_out = metadata[1] * sizeof(int);
char *compressed_data = malloc(avail_in);
char *data = malloc(avail_out);
// Read data
fread(compressed_data, 1, avail_in, ptr);
init_decompress_stream(stream, compressed_data, avail_in, data, avail_out);
// Decompress data -- COMPILES FINE UNTIL HERE --
int bz_result = BZ2_bzDecompressInit(stream, 0, 0);
}
void init_decompress_stream(bz_stream *stream, char *next_in, unsigned int avail_in, char *next_out, unsigned int avail_out){
stream->next_in = next_in;
stream->avail_in = avail_in;
stream->next_out = next_out;
stream->avail_out = avail_out;
}
This all compiles fine until the last line of main: int bz_result = BZ2_bzDecompressInit(stream, 0, 0);
when I compile using at which point I get the error:
C:/msys64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\Users\{User Name}\AppData\Local\Temp\cct30tb5.o:test.c(.text+0xc4): undefined reference to 'BZ2_bzDecompressInit'
collect2.exe: error: ld returned 1 exit status
While troubleshooting I've used three different compile commands:
gcc test.c This compiles #include <bzlib.h> and bz_stream *stream; just fine until the last line.
gcc test.c -L/usr/lib/libbz2.a this performs same as above.
gcc test.c -libbz2 this one cannot find -libbz2
I'm totally perplexed as to what I'm doing wrong.
In gcc, -L add a directory to the library search path, and -l specifies a library to load (using the search path to find it).
Hence you probably need something like:
gcc test.c -L /usr/lib -l bz2
I'd be surprised if /usr/lib wasn't already on the library path but you may want to specify it just in case. And the toolchain is smart enough to prefix your library names with lib and suffix them with extensions as needed.
You should be aware that gcc test.c -libbz2 is probably equivalent to gcc test.c -l ibbz2 which is going to be looking for ibbz2, not what you wanted.
Suppose we have two dynamic libraries libfoo.dll and libbar.dll, given that libbar.dll depends on libfoo.dll. Further we compile an executable test.exe that loads our libbar.dll using WinAPI function LoadLibrary().
If we run text.exe on Windows XP with missing libfoo.dll, LoadLibrary() shows dialog box alerting than libfoo.dll is actually missing and sets LastError to ERROR_MOD_NOT_FOUND (126).
If we run same text.exe in same conditions on Windows 10, LoadLibrary() sets LastError to ERROR_MOD_NOT_FOUND only, no dialog box appears.
In both cases ErrorMode is 0. So is there any possibility to catch a name of missing dependency in LoadLibrary() calling process, or, at least, how to make LoadLibrary() show error dialog on Windows 10?
Here is a sample code (using MinGW):
foo.c
int foo(int a, int b)
{
return a + b;
}
Compile with: gcc foo.c -o libfoo.dll -fPIC -shared
bar.c
int foo(int a, int b);
int bar(int a, int b)
{
return foo(a, b);
}
Compile with: gcc bar.c -o libbar.dll -fPIC -shared -L. -lfoo
test.c
#include <windows.h>
#include <stdio.h>
typedef int (*pfn)(int a, int b);
int main()
{
SetErrorMode(0);
HMODULE hmod = LoadLibrary("libbar.dll");
if(!hmod)
{
fprintf(stderr, "error loading library %d\n", GetLastError());
return 1;
}
pfn bar = (pfn)GetProcAddress(hmod, "bar");
if(bar)
{
fprintf(stdout, "bar(3, 1) = %d\n", bar(3, 1));
}
else
{
fprintf(stderr, "can't load bar foonction\n");
}
FreeLibrary(hmod);
return 0;
}
Compile with: gcc test.c -o test
At the moment it seems like there is no elegant solution to the question posed.
As #DavidHeffernan noted in the comments to the original post, the problem should be solved on a fundamentally different level. As LoadLibrary() behaves just like it should behave, the key is the proper installation and error handling.
However, if the one needs to explicitly catch missing dependencies of the dynamically loaded libraries, the techniques provided by #IInspectable and #eryksun could be applied:
enabling Delay-Loded DLLs for the libraries that are going to be dynamically loaded. Such an approach provides helper callbacks for each dependent module, so missing dependencies could be handled in place. The main disadvantage of this approach is that the target library should be recompiled with proper linker flags;
the helper utility that dumps debug strings from the application could be written (see #eryksun comment to the original post for details). Disadvantages: besides the need of writing an additional module it also includes some registry manipulations.
I'm trying to intercept calls to printf using ld's -wrap option. I have the two files:
main.c:
#include <stdio.h>
int main(void) {
printf("printing\n");
printf("printing");
}
printf_wrapper.c:
int __real_printf(const char *format, ...);
int __wrap_printf(const char *format, ...) {
(void)format;
return __real_printf("WRAPPED\n");
}
And I compile with the following command:
gcc -Wl,-wrap,printf *.c
When I run the resulting a.out binary, I get this output:
printing
WRAPPED
Why does the wrapping fail if there's a newline in the string? I checked my system's stdio.h and printf isn't a macro. This is with gcc 5.3.0
Use the -fno-builtin option to tell gcc not to mess around with some specified functions. So, if you added -fno-builtin-printf it should work. In general it may cause some problems that would have been caught by the compiler to be missed. See the gcc docs for details, e.g. https://gcc.gnu.org/onlinedocs/gcc-4.2.2/gcc/C-Dialect-Options.html
I want to write a C program for implementing the include functionality of the preprocessor.
Example:
In header.h I have this code:
char *test (void);
And in program.c:
int x;
#include "header.h"
int
main (void)
{
puts (test ());
}
The input is program.c.
The output must be :
int x;
char *test (void);
int
main (void)
{
puts (test ());
}
How can I do this?
You'd need to read the input file line by line. Check to see if the line starts with #include (with optional leading whitespace). If not, print the line you've read. If so, open the specified file instead, and run this same algorithm on it (to handle secondary #includes).
you can run gcc -E "your source files", and then filter the line included "#",the left is your wanted, and the macros is replaced by its real forms.
for example:
gcc -E hello.c|sed '/# .,$/d' > a.c
a.c is your wanted file.
when use gcc
gcc -E -P program.c
or
cpp -P program.c
when use Visual c
cl /EP program.c