I have a simple example:
#include "mruby.h"
#include <mruby/compile.h>
int main()
{
mrb_int i;
mrb_value c;
mrb_state *mrb = mrb_open();
char kod[] = "def suma(a,b) (a+b).to_i end";
if (!mrb) { /* problemy */ }
mrb_load_string(mrb, kod);
for(i=0; i<9; i++)
{
c = mrb_funcall(mrb, mrb_top_self(mrb), "suma", 2,
mrb_fixnum_value(i), mrb_fixnum_value(i));
}
mrb_close(mrb);
return 0;
}
How can I compile it in static mode, without the library libmruby.a?
I only want to add /src/*.c file(s).
I don't need Array. No file access, no other gems (time, test, sprintf, random, etc.)
Which files are important and which can I pass by?
I do not need the gem compiler. I can run only bytecode if it is possible.
How can I do this?
You must run rake in the mruby source directory. You will have produce libmruby.a in the build/host/lib directory. (in a specyfic architecture)
Next you compile your program with -I option and you link your program with -lmruby specified to the linker.
Is no possible making normal static like as lua
Related
I wrote a matrix multiplication program in C and compiled it using Emscripten with the following command
emcc matrix.c -o matrix.wasm -s STANDALONE_WASM
And the C program is as follows,
#include <stdlib.h>
#include <time.h>
#include <stdio.h>
int matrix() {
int a[101][101];
int b[101][101];
int r[101][101];
for(int i = 0; i<101; i++) {
for(int j = 0; j<101; j++) {
a[i][j] = rand()%1000+1;
b[i][j] = rand()%1000+1;
}
}
for(int i = 0; i<101; i++) {
for(int j = 0; j<101; j++) {
r[i][j] = 0;
for(int k = 0; k<101; k++) {
r[i][j] += a[i][k] * b[k][j];
}
}
}
return 0;
}
int main(){
clock_t start, finish;
double duration;
start = clock();
matrix();
finish = clock();
duration = (double)(finish - start) / CLOCKS_PER_SEC;
printf("computing duration: %fs\n", duration);
return 0;
}
Then I used wasmer to directly run this webassembly file:
wasmer matrix.wasm.
It returned the expected result. Then I wanted to execute this file with a specific function, that is the export function in webassembly file.
I used wasm2wat to translate this executable file into a wat file.Then I found (export "_start" (func 6)). By the way, I did not found any code about export the matrix function. Then I executed the matrix.wasm with the command:
wasmer matrix.wasm -i _start
However, the error appeared. It said:
error: failed to run `matrix.wasm`
╰─> 1: Error while importing "wasi_snapshot_preview1"."clock_time_get": unknown import. Expected Function(FunctionType { params: [I32, I64, I32], results: [I32] })
Then I tried Rust to write a simple program, which just contained a main function and a add function. I used cargo to compile it to two kinds of targets, which is wasm32-unknown-unknown and wasm32-wasi. I compiled them into wat file. This time I found (export "add" (func $add.command_export)). When I executed the wasm32-wasi programm with
wasmer add.wasm -i add
There was also errors appearing. It said:
error: failed to run `hello.wasm`
╰─> 1: Error while importing "wasi_snapshot_preview1"."args_get": unknown import. Expected Function(FunctionType { params: [I32, I32], results: [I32] })
I could execute the file whose target was wasm32-unknown-unknown correctly but I could not use lib function in this kind of target.
I think there are something wrong with my wasm32-wasi file but I do not know why it is and how to deal with it. Could you please tell me how I can call an export function in wasm32-wasi file and how I can call a lib function in wasm32-unknown-unknown file. Also I have some questions about why I use Emscripten compile the C file but the matrix function does not export in wat file. Thank you!
Compilers will often inline functions and remove code that isn't used, this is why your C program ends up with everything inside a _start function. As explained in the FAQ you may list functions to export using emcc -s EXPORTED_FUNCTIONS=_main,_matrix in order to prevent them from being inlined or removed. Adding this results in a wasm module with the function correctly exported.
As for running functions directly, the source code for wasmer run has logic to determine which runtime environment should be exposed to the module. However, if you pass -i function, it entirely skips the environment setup and runs your function directly. In this case, the modules fails to initialize because it imports functions from WASI (in order to write things to the console, and get the current clock time).
I believe the reason why wasm32-unknown-unknown works is that it doesn't link to any runtime, and implements dummy interfaces for things that it can't simulate (all filesystem calls result in errors, etc.)
In summary, wasmer run -i function isn't meant to run functions from modules that have imports, it might be possible to patch wasmer-cli for that, but I'm not sure if it would work across all runtime environments.
The Actual Problem
I have an executable that by default uses EGL and SDL 1.2 to handle graphics and user input respectively. Using LD_PRELOAD, I have replaced both with GLFW.
This works normally unless the user has installed the Wayland version of GLFW, which depends on EGL itself. Because all the EGL calls are either stubbed to do nothing or call GLFW equivalents, it doesn't work (ie. eglSwapBuffers calls glfwSwapBuffers which calls eglSwapBuffers and so on). I can't remove the EGL stubs because then it would call both EGL and GLFW and the main executable is closed-source so I can't modify that.
Is there any way to make LD_PRELOAD affect the main executable but not GLFW? Or any other solution to obtain the same effect?
The Simplified Problem
I made a simplified example to demonstrate the problem.
Main Executable:
#include <stdio.h>
extern void do_something();
int main() {
do_something();
fputs("testing B\n", stderr);
}
Shared Library:
#include <stdio.h>
void do_something() {
fputs("testing A\n", stderr);
}
Preloaded Library:
#include <stdio.h>
int fputs(const char *str, FILE *file) {
// Do Nothing
return 0;
}
When the preloaded library isn't used, the output is:
testing A
testing B
When it is used, the output is nothing.
I'm looking for a way to make the preloaded library only affect the main executable, that the output would be:
testing A
Thank you!
You can check if the return address is in the executable or the library, and then call either the "real" function or do your stub code, like this:
#define _GNU_SOURCE
#include <dlfcn.h>
#include <link.h>
#include <stdio.h>
#include <stdlib.h>
static struct {
ElfW(Addr) start, end;
} *segments;
static int n;
static int (*real_fputs)(const char *, FILE *);
static int callback(struct dl_phdr_info *info, size_t size, void *data) {
n = info->dlpi_phnum;
segments = malloc(n * sizeof *segments);
for(int i = 0; i < n; ++i) {
segments[i].start = info->dlpi_addr + info->dlpi_phdr[i].p_vaddr;
segments[i].end = info->dlpi_addr + info->dlpi_phdr[i].p_vaddr + info->dlpi_phdr[i].p_memsz;
}
return 1;
}
__attribute__((__constructor__))
static void setup(void) {
real_fputs = dlsym(RTLD_NEXT, "fputs");
dl_iterate_phdr(callback, NULL);
}
__attribute__((__destructor__))
static void teardown(void) {
free(segments);
}
__attribute__((__noinline__))
int fputs(const char *str, FILE *file) {
ElfW(Addr) addr = (ElfW(Addr))__builtin_extract_return_addr(__builtin_return_address(0));
for(int i = 0; i < n; ++i) {
if(addr >= segments[i].start && addr < segments[i].end) {
// Do Nothing
return 0;
}
}
return real_fputs(str, file);
}
This has some caveats, though. For example, if your executable calls a library function that tail-calls a function you're hooking, then this will incorrectly consider that library call an executable call. (You could mitigate this problem by adding wrappers for those library functions too, that unconditionally forward to the "real" function, and compiling the wrapper code with -fno-optimize-sibling-calls.) Also, there's no way to distinguish whether anonymous executable memory (e.g., JITted code) originally came from the executable or a library.
To test this, save my code as hook_fputs.c, your main executable as main.c, and your shared library as libfoo.c. Then run these commands:
clang -fPIC -shared hook_fputs.c -ldl -o hook_fputs.so
clang -fPIC -shared libfoo.c -o libfoo.so
clang main.c ./libfoo.so
LD_PRELOAD=./hook_fputs.so ./a.out
Implement the interposing library separately for the two cases.
Create a wrapper script or program that uses ldd to find out the exact EGL library version and their paths the target binary is dynamically linked against; then, using ldd on the the GLFW library, to find out whether it is linked against EGL or not. Finally, have it execute the target binary with the path to the appropriate interposing library in LD_PRELOAD environment variable.
For my program I am linking 3 files in total. A main.c, sortfile.c and my.h(header file). For my sortfile.c I am implementing a OddEven Sort. I am unsure whether my coding algorithm is correct. Also would like to know what information usually goes in a header file. Is it only the other two c files vide #include?
#include <stdio.h>
void swap(int *, int *);
void Odd_Even_Sort(int *);
/* swaps the elements */
void swap(int * x, int * y)
{
int temp;
temp = *x;
*x = *y;
*y = temp;
}
/* sorts the array using oddeven algorithm */
void Odd_Even_Sort(int * x)
{
int sort = 0, i;
while (!sort)
{
sort = 1;
for (i = 1;i < MAX;i += 2)
{
if (x[i] > x[i+1])
{
swap(&x[i], &x[i+1]);
sort = 0;
}
}
for (i = 0;i < MAX - 1;i += 2)
{
if (x[i] > x[i + 1])
{
swap(&x[i], &x[i + 1]);
sort = 0;
}
}
}
I did not include a main in the sortfile.c because I intended to put main in the main.c file.
You look confused. Read first the wikipage on linkers and on compilers. You don't link source files, but only object files and libraries.
(I am guessing and supposing and hoping for you that you are using Linux)
You also compile translation units into object files.
Header files are for the preprocessor (the first "phase" of the compilation). The preprocessing is a textual operation. See this answer for some hint.
So you probably want to compile your main.c into main.o with
gcc -Wall -g -c main.c -o main.o
(the -Wall asks for all warnings, so never forget that; the -g asks for debugging information; -c asks to compile some source into some object file; order of program arguments to gcc matters a big lot).
Likewise, you want to compile your sortfile.c into sortfile.o. I leave as an exercise to get the right command doing that.
Finally, you want to get an executable program myprogsort, by linking both object files. Do that with
gcc -g main.o sortfile.o -o myprogsort
But you really want to use some build automation tool. Learn about GNU make. Write your Makefile (beware, tabs are important in it). See this example. Don't forget to try make -p to understand (and take advantage of) all the builtin rules make is knowing.
Also would like to know what information usually goes in a header file.
Conventionally you want only declarations in your common header file (which you would #include in every source file composing a translation unit). You can also add definitions of static inline functions. Read more about inline functions (you probably don't need them at first).
Don't forget to learn how to use the gdb debugger. You probably will run
gdb ./myprogsort
more than once. Don't forget to rebuild your thing after changes to source code.
Look also inside the source code of some medium sized free software project coded in C on github. You'll learn a big lot.
I'm new to this site & not highly experienced in C,so pl pardon any mistakes I might commit unknowingly.
Ok,so I've got two files in C, one containing a function, & other one using that function.I think I'll need to create a header file for it,but I somehow cannot make it & need help.
here's file 1 :
#include<stdio.h>
int tempc=25,tempf;
int c2f(int c);
void main()
{
tempf=c2f(tempc);
printf("Celsius = %d,Farenheit=%d \n",tempc,tempf);
}
int c2f(int c)
{
int f;
f=9*c/5 + 32;
return f;
}
Here's file 2:
#include<stdio.h>
int tempc=25,tempf;
extern int c2f(int c);
void extern show(void);
void main()
{
tempf=c2f(tempc);
show();
}
The main question comes here. you might as well be thinking about the show function.
Actually, I'm asked to convert f1 into .asm file (using tcc -S f1.c) then add a module for show fn using assembly language, create .obj file of the .asm file, & with .obj file of f2, I've to put them in project & then build all to create .exe file.But I believe if I can simply run the program using 2 files as .c(ie with header part solved) I can do the rest.
One last question is, instead of creating header I'm wanting to do above, is it possible to keep these two files as they are, & create a header file-> make it .obj & add it to the project & build ?
A Sincere thanks to whoever tries to help.
A header file is meant to be used as a mechanism to "expose" functions to other C modules. For instance, you define a c2f() function in c2f.c and then create a prototype (essentially just a placeholder) in c2f.h. The prototype in c2f.h would look like the following:
int c2f(int c); /* Note the semicolon */
It shouldn't matter if the implementation of c2f() is in an assembly or c file. The header file simply allows C modules to make calls to c2f(). This is because you are providing the linker information to find the actual implementation of a function. The linker will then match all calls to that function to the actual address of the implementation. So, to use c2f just reference c2f.h in the file that is using it:
/* main.c */
#include "c2f.h"
...
You need to put c2f in a header and source files as such:
c2f.h:
int c2f(int c);
c2f.c:
int c2f(int c) {
return 9*c/5 + 32;
}
then compile that so you have a c2f.o file, include c2f.h in your two main() files that use it and linktheir compilation to the c2f.o file.
Suppose you created a main() to deal with an exercise you asked your students.
Every student is supposed to write their own function, with the same API. And a single file will be created, with all functions and the main calling them.
Lets say: int studentname(int a, int b) is the function pattern.
One way I deal with it was using a vector of pointer to functions int (*func[MAX])(). But you need to fulfill the vector one by one func[0]=studentname;.
I wonder, is there a way a function can be called by its name somehow?
Something like: int student1(int a , int b), student2(), etc.
And in main somehow we could just call sscanf(funcname,"student%d",i); funcname();.
Do you have any other idea? Maybe
int studentname(int a, int b, char *fname)
{
strcpy(fname, "studentname");
Anything creative will do! :)
Thanks!
Beco
PS. I tried just a vector of functions, but C won't allow me! :)
int func[2]()={{;},{;}};
This way I could just give to each student a number, and voilá... But no way. It was funny though.
Edited: I'm using linux.
Edited 2: Thanks! I've accepted an answer that helped me, but I've also documented a complete example as an answer bellow.
Maybe a bit overcomplicating it, but spontaneous idea:
Compile all student source files into one shared library with the students' functions being exports.
Then enumerate all exposed functions, call and test them.
As an alternative:
Write a small tool that will compile all "student units" using a preprocessor define to replace a predefined function name with an unique name ("func1", "func2", etc.).
Then let the tool write a small unit calling all these functions while performing tests, etc.
And yet another idea:
Use C++ to write a special class template that's going to register derived classes in a object factory and just embed student's code using extern "C". Depending on the implementation this might look a bit confusing and overcomplicated though.
Then use the factory to create one instance of each and run the code.
Example for the approach with dlopen() and dlsym() (whether only one function per library or all - doesn't matter):
void *pluginlib = dlopen("student1.so", RTLD_NOW); // RTLD_NOW will load the file right away
if (!pluginlib)
; // failed to load
studentproc func = (studentproc)dlsym(pluginlib, "student1"); // this loads the function called "student1"
if (!func)
; // failed to resolve
func("hello world!"); // call the lib
dlclose(pluginlib); // unloads the dll (this will make all further calls invalid)
Similar to what #Jamey-Sharp proposed:
ask each student to provide .c file with entry function of a given name/signature
compile each .c into a shared library, named by the student name, or given whatever unique name. This step can be easily automated with make or simple script.
make a simple host application which enumerates all .so files in a given directory, and uses dlopen() and dlsym() to get to the entry point function.
now you can simply call each student's implementation.
BTW, that's how plug-ins are implemented usually, isn't it?
Edit: Here's a working proof of concept (and a proof, that each student can use the same name of the entry point function).
Here's student1.c:
#include <stdio.h>
void student_task()
{
printf("Hello, I'm Student #1\n");
}
Here's student2.c:
#include <stdio.h>
void student_task()
{
printf("Hello, I'm Student #2\n");
}
And here's the main program, tester.c:
#include <stdio.h>
#include <dlfcn.h>
/* NOTE: Error handling intentionally skipped for brevity!
* It's not a production code!
*/
/* Type of the entry point function implemented by students */
typedef void (*entry_point_t)(void);
/* For each student we have to store... */
typedef struct student_lib_tag {
/* .. pointer to the entry point function, */
entry_point_t entry;
/* and a library handle, so we can play nice and close it eventually */
void* library_handle;
} student_solution_t;
void load(const char* lib_name, student_solution_t* solution)
{
/* Again - all error handling skipped, I only want to show the idea! */
/* Open the library. RTLD_LOCAL is quite important, it keeps the libs separated */
solution->library_handle = dlopen(lib_name, RTLD_NOW | RTLD_LOCAL);
/* Now we ask for 'student_task' function. Every student uses the same name.
* strange void** is needed for C99, see dlsym() manual.
*/
*(void**) (&solution->entry) = dlsym(solution->library_handle, "student_task");
/* We have to keep the library open */
}
int main()
{
/* Two entries hardcoded - you need some code here that would scan
* the directory for .so files, allocate array dynamically and load
* them all.
*/
student_solution_t solutions[2];
/* Load both solutions */
load("./student1.so", &solutions[0]);
load("./student2.so", &solutions[1]);
/* Now we can call them both, despite the same name of the entry point function! */
(solutions[0].entry)();
(solutions[1].entry)();
/* Eventually it's safe to close the libs */
dlclose(solutions[0].library_handle);
dlclose(solutions[1].library_handle);
return 0;
}
Let's compile it all:
czajnik#czajnik:~/test$ gcc -shared -fPIC student1.c -o student1.so -Wall
czajnik#czajnik:~/test$ gcc -shared -fPIC student2.c -o student2.so -Wall
czajnik#czajnik:~/test$ gcc tester.c -g -O0 -o tester -ldl -Wall
And see it works:
czajnik#czajnik:~/test$ ./tester
Hello, I'm Student #1
Hello, I'm Student #2
I'd take a different approach:
Require every student to use the same function name, and place each student's code in a separate source file.
Write one more source file with a main that calls the standard name.
Produce a separate executable from linking main.c with student1.c, then main.c with student2.c, and so on. You might be able to use wildcards in a makefile or shell script to automate this.
That said, at least on Unix-like OSes, you can do what you asked for.
Call dlopen(NULL) to get a handle on the symbols in the main program.
Pass that handle and the function name you want to dlsym. Coerce the resulting pointer to a function pointer of the right type, and call it.
Here is an ugly preprocessor hack:
#Makefile
FILE_NAME=student
${FILE_NAME}: main.c
cc -Wall -DFILE_NAME=\"${FILE_NAME}.c\" -o $# main.c -lm
Teacher's main.c:
#include <math.h>
#include <stdio.h>
#include FILE_NAME
char *my_name(void);
double my_sin(double val);
int main(void)
{
double dd;
dd = my_sin(3.1415923563);
printf("%s: %f\n", my_name(), dd);
return 0;
}
Student's .c File:
#include <math.h>
char * my_name(void);
double my_sin(double val);
char * my_name(void)
{
return "Wildplasser-1.0";
}
double my_sin(double val)
{
return sin (val);
}
The trick lies i the literal inclusion of the student's .c file.
To avoid this, you could also use a different make line, like:
cc -Wall -o $# ${FILE_NAME}.c main.c -lm
(and remove the ugly #include FILENAME, of course)
Thanks you all. I've accepted an answer that gave me the inspiration to solve the question. Here, just to document it, is my complete solution:
File shamain.c
/* Uses shared library shalib.so
* Compile with:
* gcc shamain.c -o shamain -ldl -Wall
*/
#include <stdio.h>
#include <stdlib.h>
#include <dlfcn.h>
int main(void)
{
void *libstud;
int (*student[2])(int, int);
char fname[32];
int i,r;
libstud = dlopen("./shalib.so", RTLD_NOW);
if (!libstud)
{
fprintf(stderr, "error: %s\n", dlerror());
exit(EXIT_FAILURE);
}
dlerror(); /* Clear any existing error */
for(i=0; i<2; i++)
{
sprintf(fname, "func%d", i);
*(void **) (&student[i]) = dlsym(libstud, fname); /* c99 crap */
//student[i] = (int (*)(int, int)) dlsym(libstud, fname); /* c89 format */
}
for(i=0; i<2; i++)
{
r=student[i](i, i);
printf("i=%d,r=%d\n", i, r);
}
return 0;
}
File shalib.c
/* Shared library.
* Compile with:
* gcc -shared -fPIC shalib.c -o shalib.so -Wall
*/
#include <stdio.h>
int func0(int one, int jadv)
{
printf("%d = Smith\n", one);
return 0;
}
int func1(int one, int jadv)
{
printf("%d = John\n", one);
return 0;
}
It is a while since I have used shared libraries, but I have a feeling you can extract named functions from a DLL/shlib. Could you create a DLL/shared library containing all of the implementations and then access them by name from the main?
Per #william-morris's suggestion, you might have luck using dlsym() to do a dynamic lookup of the functions. (dlsym() may or may not be the library call to use on your particular platform.)