Lua module - how to not include Lua core? - gcc

I need to build this Lua module and to be able to use it in another application that already has Lua core included. Module will be loaded via 'require'.
I'm using MinGW x64 on Windows 10. I successfully built Lua 5.2 with it, extracted lua.dll file and renamed it into liblua.dll.a.
Then I built the module using following Makefile:
CC = x86_64-w64-mingw32-gcc
LUA_INCDIR=$(STAGING_DIR)/usr/include
utf8.dll: lutf8lib.o
$(CC) -m64 -O -shared -fpic lutf8lib.c -o utf8.dll -llua
lutf8lib.o: lutf8lib.c
$(CC) -O2 -fpic -c -DLUA_BUILD_AS_DLL lutf8lib.c -I$(LUA_INCDIR)
The problem is file size, it's 420kb and it definetely includes Lua core (I got 'multiple VMs' error). I need to build the module without including the core.
Previously I installed usual MinGW (x86) and used following Makefile:
CC = gcc
LUA_INCDIR=$(STAGING_DIR)/usr/include
utf8.dll: lutf8lib.o
$(CC) -m32 -shared lutf8lib.c -o utf8.dll -llua
lutf8lib.o: lutf8lib.c
$(CC) -fPIC -c lutf8lib.c -I$(LUA_INCDIR)
And got 97kb file without Lua core. Unfortunately I specifically need x64 file.
UPD: I tried to build the same module using MSVC, but it seems that IDE changes luaopen_utf8 function name. If I'll add this to fix it:
int __declspec(dllexport)
IDE will include Lua core VM into DLL file. Again.

Related

Compiling my program with OpenSSL as static library on windows fail

I wrote a program that is using OpenSSL and I'm trying to compile it to executable for inwdows.
The command I'm using to compile is:
gcc -g -Ifolder1/include -Iopenssl/include -Ifolder2 -c folder1/lib/functions.c -o folder1/lib/functions.o
gcc -g -Ifolder1/include -Iopenssl/include -Ifolder2 -o myprog.exe main.o folder1/lib/myfiles.o folder1/lib/plus.o folder1/lib/functions.o -Lopenssl/windows/static -lcrypto
This works for linux but for windows i get
c:/mingw/bin/../lib/gcc/mingw32/6.3.0/../../../../mingw32/bin/ld.exe: cannot find -lcrypto
Any idea what is the corresponding flag for -lcrypto for linux?
The problem was that in path openssl/windows/static i had a library with the suffix *.lib and seems like gcc doesnt recongnize it as a library.
resolved when i change it to *.a suffix

Error when cross compiling shared so which depends on another so

I am trying to cross compile my application for a arm based system.
I have 2 libraries compiled in the following way:
$ gcc -shared --sysroot=$DIR_PATH -o $LIBPATH/libfoo.so foo.o
$ gcc -shared --sysroot=$DIR_PATH -o $LIBPATH/libbar.so bar.o
A third library is compiled:
gcc -shared -o $LIBPATH/libfoobar.so --sysroot=$DIR_PATH -L$LIBPATH -Wl,rpath=$RUN_TIME_PATH foobar.o -lfoo -lbar
Then finally I compile a binary:
gcc -o app --sysroot=$DIR_PATH -L$LIBPATH -Wl,rpath=$RUN_TIME_PATH app.o -lfoobar
However when compiling app I get
warning: libfoo.so, needed by libfoobar.so, not found (try using -rpath or -rpath-link)
I believe you need to use -Wl,-rpath-link=$LIBPATH to tell the linker where to look to resolve runtime library references during the link operation.
More info can be found in the ld documentation: https://sourceware.org/binutils/docs-2.37/ld/Options.html

How to configure GNU Autotools to compile a program in 32-bit while on Centos7?

I'm doing all this on a VLE and below is what I'm working with:
Running OS: Linux Centos 7
GCC:4.8.5 & 7.1.0
I'm trying to use GNU autotools (libtool, autoconf, automake) to build a project in 32-bit using gcc-7.1.0. Also, as a requirement, I must do this on Centos 7 and use gcc-7.1.0.
Apparently, the latest version of gcc that can be officially upgraded through yum is 4.8.5. However, I successfully installed gcc-7.1.0 from the official source and even included --enable-multiarch --with-list-multilib=m32,m64 --enable-multilib during configure.
The issue I'm running into is that the autotools seem to want to use the 64-bit libraries even though I'm including -m32 compiler switch in CXXFLAGS, CFLAGS, and LDFLAGS. The reason I think it's using 64-bit libraries at linking is that I get the error below:
libtool: link: g++ -m32 -fPIC -Wall -Wextra -Weffc++ -Werror -std=c++03 -O2 -o fldprog fldprog-icpprog.o ../../ ../seal3/fld/src/.libs/libbsp_fld.a -lpci /usr/local/lib/../lib64/libstdc++.so -lm -Wl,-rpath -Wl,/usr/local/lib /../lib64 -Wl,-rpath -Wl,/usr/local/lib/../lib64
/usr/local/lib/../lib64/libstdc++.so: error adding symbols: File in wrong format
And when I rename /usr/local/lib64 to lib64_something, the program will compile without any errors. However, I want to find a permanent solution.
I've searched the internet for answers but none of them seem to really work. I've tried including -L/usr/local/lib to AM_LDFLAGS, AM_CFLAGS in configure.ac
I'd appreciate any input. Thank you.
Edit:Revised

Compiling OpenMP to WebAssembly

I am trying to compile a multi threaded application to WebAssembly. The application uses OpenMP for multithreading.
To compile I am using the Emscripten framework.
I have already downloaded the source files for OpenMP and compiled it for my host machine using make. With the following command I can get it to link with a simple demo application on my machine:
g++ -Wall -Werror -pedantic main.o -o main.x /$PATH_TO_OPENMP/build/runtime/src/libgomp.a -pthread -lstdc++ -Wl,--no-as-needed -ldl
I then tried to compile OpenMP to the llvm bytecode format used by Emscripten. To do so I tried to run 'emmake make', so that the emscripten framework executes the OpenMP makefiles with a suitable compiler. As emscripten does not like shared object files I compiled it to static library .a files.
This works and actually gives me object files to which I can link.
I then wanted to link my demo application with the following command
em++ -Wall -Werror -pedantic main.o -o main.html /home/main/data/Programming/openMP/openmp_web/build/runtime/src/libgomp.a -pthread -lstdc++ -Wl,--no-as-needed -ldl
But I get these warnings, that it couldn't link to OpenMP files:
shared:WARNING: object /tmp/emscripten_temp_ONa0eU_archive_contents/kmp_atomic.cpp.o is not a valid object file for emscripten, cannot link
.
.
shared:WARNING: object /tmp/emscripten_temp_ONa0eU_archive_contents/kmp_str.cpp.o is not a valid object file for emscripten, cannot link
shared:WARNING: object /tmp/emscripten_temp_ONa0eU_archive_contents
So I figured I must have compiled OpenMP with the wrong compiler. I then tried to change the compiler when building the library by using the following commands:
cmake -DCMAKE_C_COMPILER=emcc -DCMAKE_CXX_COMPILER=em++ -DLIBOMP_LIB_TYPE=normal -DLIBOMP_ENABLE_SHARED=OFF -DCMAKE_BUILD_TYPE=Release -DLIBOMP_ARCH=x86_64 OPENMP_STANDALONE_BUILD=1 ..
emmake make
But this just gives strange errors on some missing system variables
/home/main/data/Programming/openMP/openmp_web/runtime/src/kmp_platform.h:82:2: error: Unknown OS
/home/main/data/Programming/openMP/openmp_web/runtime/src/kmp_platform.h:203:2: error: Unknown or unsupported architecture
In file included from /home/main/data/Programming/openMP/openmp_web/runtime/src/kmp_alloc.cpp:13:
In file included from /home/main/data/Programming/openMP/openmp_web/runtime/src/kmp.h:77:
/home/main/data/Programming/openMP/openmp_web/runtime/src/kmp_os.h:171:2: error: "Can't determine size_t printf format specifier."
Does anyone have an idea on what I could do differently?

Compiling a dynamically linked library

I'm currently trying to compile a dynamically linked library (for a plugin system) using Windows and MinGW.
I compile each objects using this command line :
mingw-g++ -fPIC test.cpp
And the library using this line:
mingw-g++ -rdynamic -shared -Wl,-soname,test.so.1 -o test.so test.o
It doesn't work at all (using GCC with Linux, a similar line works though) : fPIC and rdynamic are ignored for some reason.
And while trying to make the library, it fails because the compiler try to link it with objects that are supposed to be resolved as I dynamically link it with the main binary.
So how do you compile this using MinGW?
Thanks :) !
-fPIC and -rdynamic are ignored because they are unused for Windows.
Also, .so is not the correct output extension for libraries on Windows.
To make a shared library for/on windows with GCC:
mingw-g++ -c file.cpp -o file.o
mingw-g++ -shared -Wl,--out-implib,libfile.a -o file.dll file.o
No more, no less.
And, documentation is always lovely to have: http://www.mingw.org/wiki/sampleDLL

Resources