[Iup-users] lglicua, dynamic linking and Linux [was: Problem linking with scintilla]
Brought to you by:
scuri
Menu
▾
▴
[Iup-users] lglicua, dynamic linking and Linux [was: Problem linking with scintilla]
|
From: sur-behoffski <sur...@gr...> - 2023-07-18 05:51:52
|
G'day,
A long(ish?) description of lglicua installation, build, and then,
finally, narrowing in on both lglicua's GNU/Linux shared object (.so)
model, plus some thoughts/comparisons to Windows shared dynamic link
libraries (.dll).
1. Clone a "master" VM into a "work" VM, then use qemu-nbd to unpack
lglicua-0.1-beta1.tar.gz into /home/qm/lglicua-0.1-beta1/:
2. Use the following string of commands within the VM to install and
select Lua 5.4, along with LuaRocks 3.9.2, also configured for 5.4:
cd /home/qm/*/install/ && ./i lua-install 5.4 && ./i lua-environment-force 5.4 fer-real && ./i reboot-now
The final reboot is because LuaRocks needs to have both LUA_PATH and
LUA_CPATH reference Lua 5.4, and so, upon login after startup, we run:
/etc/profile.d/17-LuaRocks-3.9.2-LUA_PATH-and-LUA_CPATH.sh
3. After reboot, we now have a working Lua environment, so the scripts
switch to relying on Lua resources, especially the Assistant database:
/home/qm/*/svn/assistant-database.lua
So, we re-enter the installation directory, and do:
3a. Install third-party packaged (OS) libraries needed by CD/IM/IUP.
(See e.g. DistroEnvStatic.ubuntu.Dependencies.);
./i imcdiup-osdepend-install
- im: libfftw3-dev libpng-dev
- pdflib7:
- ftgl: *im + libfreetype6-dev libglu1-mesa-dev
- cd: *im:ubuntu *pdflib7:ubuntu *ftgl:ubuntu + libgtk-3-dev
- iup: *im:ubuntu *cd:ubuntu + libwebkit2gtk-4.0-dev
[Of special note to your GTK problems, note that both CD and IUP
install libgtk-3-dev.]
[We only name the principal required packages; the Distribution's
packaging system will pull in downstream required packages.]
3b. Fetch the latest IM/CD/IUP Subversion sources from SourceForge;
./i imcdiup-svn-fetch
3c. Switch to the Assistant build directory, and:
- Nuke any existing workspace;
- Unpack the latest Subversion repository versions fetched in the
previous step;
- Build, in order: im, pdflib7, ftgl, cd, iup;
- Create a new runtime workspace "1":
/home/qm/*/1
/home/qm/*/1/play/
/home/qm/*/1/support/
- Gather the generated runtime objects from each package into
the "1/support" directory. The files are spelt out by the
Assistant in the "Runfiles" table; more entries (.a libraries?)
could be added here if desired:
- im: libimlua{LUALIBSFX}.so ../libim.so
- pdflib7: ../libpdflib.so
- ftgl:
- cd: ibcdlua{LUALIBSFX}.so libcdluapdf{LUALIBSFX}.so ../libcd.so ../libcdpdf.so
The command line for doing all of step 3 is:
cd /home/qm/*/install && ./i imcdiup-osdepend-install && ./i imcdiup-svn-fetch && cd ../build && ./q nuke,unpack,build,gather fer-real
4. The workspace "support" directory is set up to do all of the
background slogging, so scripts in the "play" directory can offload
all details to "../1/support/play-lua-tec":
$ pushd ../1/play
$ ls -al ../support
total 7768
drwxr-xr-x 2 x x 4096 Jul 18 14:15 .
drwxr-xr-x 9 x x 4096 Jul 18 14:09 ..
-rwxr-xr-x 1 x x 212120 Jul 18 14:11 libcdlua54.so
-rwxr-xr-x 1 x x 16288 Jul 18 14:11 libcdluapdf54.so
-rwxr-xr-x 1 x x 47328 Jul 18 14:11 libcdpdf.so
-rwxr-xr-x 1 x x 928912 Jul 18 14:11 libcd.so
-rwxr-xr-x 1 x x 103088 Jul 18 14:10 libimlua54.so
-rwxr-xr-x 1 x x 1585288 Jul 18 14:09 libim.so
-rwxr-xr-x 1 x x 230944 Jul 18 14:14 libiuplua54.so
-rwxr-xr-x 1 x x 1303648 Jul 18 14:11 libiup.so
-rw-r--r-- 1 x x 307480 Jul 18 13:06 liblua5.4.so
-rw-r--r-- 1 x x 307480 Jul 18 13:06 liblua5.4.so.0
-rw-r--r-- 1 x x 307480 Jul 18 13:06 liblua5.4.so.0.0.0
-rwxr-xr-x 1 x x 1482128 Jul 18 14:10 libpdflib.so
-rwxr-xr-x 1 x x 311656 Jul 18 13:06 lua
-rwxr-xr-x 1 x x 311656 Jul 18 13:06 lua5.4
-rwxr-xr-x 1 x x 222560 Jul 18 13:06 luac
-rwxr-xr-x 1 x x 222560 Jul 18 13:06 luac5.4
-rwxr-xr-x 1 x x 1332 Jul 18 14:09 play-lua-tec
$
"play-lua-tec" is the key script that links up resources in
the "../1/support" directory with client scripts in the
"../1/play" directory. Here's a terse version:
LUAVER="5.4"
LUASFX="54"
LOCAL_SUPPORT_PACKAGE_CPATH=$(cat <<EOF
package.cpath = table.concat({
'../support/?.so',
'../support/lib?.so',
'../support/lib?${LUASFX}.so',
package.cpath}, ';')
EOF
LD_LIBRARY_PATH="../support:${LD_LIBRARY_PATH}" \
"../support/lua${LUAVER}" \
-e "$LOCAL_SUPPORT_PACKAGE_CPATH" \
"$@"
* We run Lua: "../support/lua${LUAVER}");
* We extend package.cpath to include various
"../support/*.so" library files generated during
installation, mainly Lua/CD/IM/IUP;
* We edit the dynamic linking library path, LD_LIBRARY_PATH,
for one command only (the Lua run command); and
* All the original script parameters are presented to the
calling client via the "$@" parameter.
--------
Whew! There's a lot above... but we can now write a two-line
"hello, world" GUI script, with the first line being a Bash shebang
line to invoke ../support/play-lua-tec, and the remainder of the
script (the second line) being Lua code to import IUP and put up a
"hello, world" MessageBox:
/home/qm/*/1/play$ cat ./hello-world
#!/bin/bash ../support/play-lua-tec
iup=require("iuplua"); iup.Message("MyApp", "hello, world")
/home/qm/*/1/play$ ./hello-world
Other demo files include creating a PDF, a PowerPoint file, and
even patching the IUP MessageBox C code to subvert the ASCII characters
being displayed ("silly-iup", along with "../../patches/iup-silly-patch"),
using the "patch" subcommand:
1/play $ ./silly-iup
1/play $ popd
build$ ./q iup:nuke,unpack,patch,build,gather
build$ pushd ../1/play
1/play$ ./silly-iup
--------
If we remove "build/q::HackTecmakeConfigFiles", so that tecmake.mak
is version 4.21 (downloaded from the Subversion repository), instead
of 4.31 (Kernel 6+ fixes), and then try to build IUP, we get:
Tecmake: compiling iup_flattree.c ...
gcc -c -Wall -O2 -m64 -fPIC -I../include -I. -Igtk -I/usr/include/lua5.4 -I/usr/include/atk-1.0 -I/usr/include/gtk-2.0 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/lib64/gtk-2.0/include -I/usr/lib/glib-2.0/include -I/usr/lib/gtk-2.0/include -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/lib/arm-linux-gnueabihf/glib-2.0/include -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/X11R6/include -DGTK_DISABLE_DEPRECATED -DTEC_UNAME=Linux60_64 -DTEC_SYSNAME=Linux -DLinux=6.0 -DTEC_LITTLEENDIAN -DTEC_64 -DFUNCPROTO=15 -DNDEBUG -o ../obj/Linux60_64/iup_flattree.o iup_flattree.c
Tecmake: compiling iupgtk_focus.c ...
gcc -c -Wall -O2 -m64 -fPIC -I../include -I. -Igtk -I/usr/include/lua5.4 -I/usr/include/atk-1.0 -I/usr/include/gtk-2.0 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/lib64/gtk-2.0/include -I/usr/lib/glib-2.0/include -I/usr/lib/gtk-2.0/include -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/lib/arm-linux-gnueabihf/glib-2.0/include -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/X11R6/include -DGTK_DISABLE_DEPRECATED -DTEC_UNAME=Linux60_64 -DTEC_SYSNAME=Linux -DLinux=6.0 -DTEC_LITTLEENDIAN -DTEC_64 -DFUNCPROTO=15 -DNDEBUG -o ../obj/Linux60_64/iupgtk_focus.o gtk/iupgtk_focus.c
gtk/iupgtk_focus.c:7:10: fatal error: gtk/gtk.h: No such file or directory
7 | #include <gtk/gtk.h>
| ^~~~~~~~~~~
compilation terminated.
make[2]: *** [../tecmake.mak:1771: ../obj/Linux60_64/iupgtk_focus.o] Error 1
make[1]: *** [Makefile:12: iup] Error 2
make: *** [Makefile:13: iup] Error 2
Execution of iup build failed:
Note Linux 6 and GTK 2 directives:
"-DLinux6.0";
"-I/usr/lib64/gtk-2.0/include";
"-I/usr/lib/gtk-2.0/include"; and
"-I/usr/lib/x86_64-linux-gnu/gtk-2.0/include"
in the compiler directives above. Tecmake.mak 4.21 has stuffed up the
GTK 3.0 selection for Kernel 6.0.
------------------------
Finally, I am uncomfortable about any set-up where a DLL in a stray
path can be loaded by the OS (Windows DLL in current directory?).
Where this is true, it might open a path for a malicious actor to
inject a subverted file, which, depending on the circumstances,
might be able to do undesirable things.
------------------------
Okay... hope that all of the above helps.
cheers,
sur-behoffski (Brenton Hoff)
programmer, Grouse Software
|