package.loadlib for specific cases

[blog...@gmail.com]

1 - Im known what package.loadlib  lowlevel call

2 - Im known what package.loadlib OS depend call

I have 2 cases for package.loadlib first case just for fun

Im have 2 C modules for example

A.c -> A.so

B.c -> B.so

But Im need one AB.so with two (or more!) modules inside one library

thanks package.loadlib I can do it

Make module functions and structs as static and build

gcc -c moda.c `pkg-config --libs --cflags lua5.4` -o liba.o
gcc -c modb.c `pkg-config --libs --cflags lua5.4` -o libb.o
gcc liba.o libb.o -shared -o A.so

Now just local and call functions from two modules from single library

print(package.loadlib("./A.so","luaopen_A")().fromc_a());
print(package.loadlib("./A.so","luaopen_B")().fromc_a());

Awesome, thanks for package.loadlib! 

Next another way for example I need call C function from libname.so

without compile It with Lua API. 

For now its realy posible, aka pseudo FFI =)

NOTICE DO NOT DO THAT!!!!!!!!!!!! HTIS IS HACK THIS IS BAD!!!! THIS BROKE C STACK BROKE!!! JUST FUN EXAMPLE!! IF YOU LAUNCH THIS THE EARTH WILL STOP AND THE MOON WILL FALL ON YOUR FLOWER BEDS, NOOOOOOOOO :D

print(package.loadlib("/lib/x86_64-linux-gnu/libc.so.6","puts")("hello"));

But it works  :) Okey this is bad, this is hack, but I can compile just C library without

Lua API, just for call C function without communicate with Lua, just call as lua_CFunction, and and that's all, never more.

for example 

       #include <stdio.h>

int example_func(void * empty) /* This void* for no break C stack for place Lua state*/

{

...

very_very_hard_c_working /*some hard work inside func*/

...

printf("Work done\n"); /*just notice*/

return 0; /*send to Lua CFunc_call no values return*/

}

Now build it

gcc mod.c -shared -o mod.so

Now call it

print(package.loadlib("./mod.so","example_func")());

My question is, since the function example_func as a whole is designed correctly from the point of view lua_CFunction this is my NoLuaAPI C NotModule correct or not? :D

Or is it the same stupidity as the broken stack in the example above for directly puts call?

There are just cases when I don't need to exchange data between languages, I just need to call functions.

That's all from me :) Lua cool hehe

 

[涵曦]

You can use lua-ffi load mod.so file. https://github.com/zhaojh329/lua-ffi/blob/main/tests/test.lua

blog...@gmail.com <blog...@gmail.com> 于 2025年5月11日周日 23:22写道：

--
You received this message because you are subscribed to the Google Groups "lua-l" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lua-l+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/lua-l/fca32379-7678-4fb1-8fea-f463ddccd87fn%40googlegroups.com.

[Scott Morgan]

On 11/05/2025 16:22, blog...@gmail.com wrote:
> 1 - Im known what package.loadlib  lowlevel call
> 2 - Im known what package.loadlib OS depend call
>
> I have 2 cases for package.loadlib first case just for fun
> Im have 2 C modules for example
>
> A.c -> A.so
> B.c -> B.so
>
> But Im need one AB.so with two (or more!) modules inside one library
> thanks package.loadlib I can do it
>

> Make module functions and structs as *static *and build

>
> gcc -c moda.c `pkg-config --libs --cflags lua5.4` -o liba.o
> gcc -c modb.c `pkg-config --libs --cflags lua5.4` -o libb.o
> gcc liba.o libb.o -shared -o A.so
>
> Now just local and call functions from two modules from single library
>
> print(package.loadlib("./A.so","luaopen_A")().fromc_a());
> print(package.loadlib("./A.so","luaopen_B")().fromc_a());
>
> Awesome, thanks for package.loadlib!

From the Lua manual for chapter 6.3 'Modules' under the
'package.searchers' section:

https://www.lua.org/manual/5.4/manual.html#pdf-package.searchers
> The fourth searcher tries an all-in-one loader. It searches the C path for a library for the root name of the given module. For instance, when requiring a.b.c, it will search for a C library for a. If found, it looks into it for an open function for the submodule; in our example, that would be luaopen_a_b_c. With this facility, a package can pack several C submodules into one single library, with each submodule keeping its original open function.

Sound like it'd fit your needs, and be perfectly natural for the end users.

Scott