Compile Lua from source and create C module with it - c

I thought of compiling Lua from source code and then create a C module.
I compiled Lua with success but I can't build my C module.
So, I compiled Lua like this:
gcc -o Lua *.c -Os -std=c99
Compiled my module like this:
gcc -Wall -shared -fPIC -o module.so -I. module.c
But there are a few errors here:
Undefined symbols for architecture x86_64:
"_lua_pushcclosure", referenced from:
_luaopen_module in module-fb0b1f.o
"_lua_pushnumber", referenced from:
_super in module-fb0b1f.o
"_lua_setglobal", referenced from:
_luaopen_module in module-fb0b1f.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
The C module itself:
#include "lua.h"
static int super(lua_State* L) {
lua_pushnumber(L, 5);
return 1;
}
int luaopen_module(lua_State* L) {
lua_register(L, "super", super);
return 0;
}
My Lua script:
require("module")
print(super())
I'm on Unix based system (Mac), but I want it to work on Linux as well.
Edit:
Problem to compile C module was fixed by entering -bundle -undefined dynamic_lookup instead of -shared (Thanks lhf).
But I can't import the module in Lua.
> require("module")
error loading module 'module' from file './module.so':
dynamic libraries not enabled; check your Lua installation
Another thing:
This seems to be a quick fix only; -bundle -undefined dynamic_lookup. This does not work on Linux. How can I do this on linux? I wanted a solution for Unix based systems.

Download Lua from lua.org and build Lua with make macosx. See Getting started.
Use -bundle -undefined dynamic_lookup instead of -shared to build module.so.
Use require"module" to load it into Lua.
Call super.
Make sure you're running the lua program that you have built above, not some other version that is installed.

Related

Is it posible to compile Flex/Lex on a M1 Mac

In my compilers class we are writting Flex/Lex code. When I compiled the .l file and tried to compile the resultant lex.yy.c file with gcc, I got the following error:
Undefined symbols for architecture arm64:
"_yywrap", referenced from:
_yylex in lex-fb85c9.o
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Does is posible to compile it in a Apple Silicon (M1) Mac, at least in a Linux VM?
I created a test file and compiled:
% flex lex.l
% cc -o lex lex.yy.c -lc -ll
% grep 'yylex();' lex.yy.c
yylex();
The -ll on the cc command links against the libl library. Current M1 based macOS does not provide a libfl library you may see referenced.

How do I include the object files for openssl/md5 library?

I have included the openssl/md5.h in my source.
#include <openssl/md5.h>
This is my (part of) my code:
char *pf_generate_pfdhr_string(int firstfree, int numpages)
{
const int md5_digest_len = 16;
char hash[md5_digest_len];
MD5_CTX md5_ctx;
MD5_Init(&md5_ctx);
int hdr_arr[2] = {firstfree, numpages};
MD5_Update(&md5_ctx, hdr_arr, 2*sizeof(int));
MD5_Final(hash, &md5_ctx);
return hash;
}
And this is my output
ranlib build/libpf.a
cc -g -O2 -Wall -Wextra -Isrc -rdynamic tests/pf_tests.c build/libpf.a -o tests/pf_tests
Undefined symbols for architecture x86_64:
"_MD5_Final", referenced from:
_pf_generate_pfdhr_string in libpf.a(pf.o)
"_MD5_Init", referenced from:
_pf_generate_pfdhr_string in libpf.a(pf.o)
"_MD5_Update", referenced from:
_pf_generate_pfdhr_string in libpf.a(pf.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [tests/pf_tests] Error 1
I have included the header file so the compiler knows the function exists. However, it seems unable to find the object files for the md5 library. How can I include it in my build?
If I am using Make, what is the best way to do so?
Thank you.
Check the documentation for your platform. It may be -lcrypto -lssl. It may not be. If your platform supports pkg-config, use pkg-config --libs openssl.

Compiling a c application that links to a static library on AIX

I'm trying to compile my application to link to a static library (.a file)
The command I use to build is this:
gcc -DUNIX -maix32 -o Release/bin/testApp Release/obj/main.o -ltestLib
When I build I get the following errors:
ld: 0711-317 ERROR: Undefined symbol: .test
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
Where test is a method in libtestLib.a
Also if I try and build with a dynamic lib then it is successful.
gcc -DUNIX -maix32 -o Release/bin/testApp Release/obj/main.o libtestLib.so
Can you see where I am going wrong?
Can you try specifying a path to the archive file, rather than -ltestLib?
gcc -DUNIX -maix32 /path/to/testLib.a -o Release/bin/testApp Release/obj/main.o

Macosx, C and embedded lua

Ok, what we have:
Program written on C which compiling and running without problems in Linux and MacOSX (leopard).
I embedded lua code today. Linux: compiled lua 5.1 from source. Everything works and compiles without any problems. Macos: compiled the same lua 5.1 package.
Linked with --llua.
Started compile and got an error:
CC=gcc-4.0 make
ld: warning: in /usr/local/lib/liblua.a, file is not of required architecture
Also tried reinstall, complete remove and installing from macports. The same.
So is there any fix for that?
The error "file is not of required architecture" hints to the fact that you're trying to mix architectures.
Check the architecture of the /usr/local/lib/liblua.a and make sure it matches the architecture or the object you're trying to build.
E.g.
We have a i386 object:
==== cat fun.c ====
#include <stdio.h>
void fun()
{
printf("%s", "foobar\n");
}
gcc -arch i386 -c fun.c -o fun.o
if we try to use it when compiling a x86_64 object (default architecture in Mac OS X):
===== cat test.c ==
extern void fun();
int main()
{
fun();
}
we get:
$ gcc test.c fun.o
ld: warning: ignoring file fun.o, file was built for i386 which is not the architecture being linked (x86_64)
Undefined symbols for architecture x86_64:
"_fun", referenced from:
_main in ccXVCQhG.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status

Underbars in symbol names when linking against an external library

I'm trying to compile a C library and then some external C code liked against it and I'm having issues with my external code finding the symbols within the library. I don't understand the big flick and am hoping someone can help. Here are the details:
1) I'm working on a Mac. I've compiled the library as a static .a library in xcode.
2) I'm attempting to compile external code calling functions from the library. I've included the header file and I'm specifying it's location and the library in the gcc call. The compilation seems to complete ok, but the linking fails stating that symbols cannot be found.
3) The missing symbols are listed as _FunctionName where FunctionName is the name of the function I called.
It is not clear to me why the compiler/linker has added underbars to my function names. But my naive guess is that is why the symbols can not be found in the library.
The external code compilation is being done through MATLAB's mex() function which is making the gcc calls below in the background.
I'd be thankful for any thoughts anyone might have.
gcc-4.2 -c -Igsf_0303/ -I/Applications/MATLAB_R2011b.app/extern/include \
-DMATLAB_MEX_FILE -fno-common -no-cpp-precomp -arch x86_64 -isysroot \
/Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.5 -fexceptions \
-DMX_COMPAT_32 -O2 -DNDEBUG "gsf_tester.c"
gcc-4.2 -O -Wl,-twolevel_namespace -undefined error -arch x86_64 -Wl, \
-syslibroot,/Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.5 -bundle -Wl,\
-exported_symbols_list,/Applications/MATLAB_R2011b.app/extern/lib/maci64/mexFunction.map \
-o "gsf_tester.mexmaci64" gsf_tester.o gsf_0303/libgsf.a \
-L/Applications/MATLAB_R2011b.app/bin/maci64 -lmx -lmex -lmat -lstdc++
Undefined symbols:
"_gsfOpen", referenced from:
_mexFunction in gsf_tester.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
mex: link of ' "gsf_tester.mexmaci64"' failed.
Here's a guess. Firstly, Joachim's comment is correct. C function names will always be prepended with an underscore. So that's not the issue.
So either gfsOpen() is missing from the library or it's not visible or it can't be seen when gfs_tester.o is linked.
So check that gfsOpen is in the library. This should do it
otool -t -v sgsf_0303/libgsf.a | grep gsfOpen
The above disassembles the file and then greps the symbol you are interested in from it. There's probably a better way, but I haven't bothered to research it.
Check it's not declared static.
Make sure the architecture of the library matches (otool -fv)

Resources