shared libraries

[rakslice]

SVR4 shared library support is a thing iiuc, but libtool doesn't understand what to do.

Thus imlib is building here but can't actually do anything for dynamic library based image format module wanting imlib, thus things that use it exclusively (eterm) don't actually support any images

[rakslice]

libtool / libltdl obviously doesn't know what to make of this system

[rakslice]

Git is extraordinarily huge, but it's because of all of the command line tools that include the same lib -- if this could use shared libraries it would be a big win.

[rakslice]

But alas it is free of infrastructure to build shared library; it only gets the benefit of a couple external shared library dependencies like zlib

[rakslice]

I have a branch with libtool at least able to build shared libs, where I'm reworking some builds to then libtoolize and autoreconf. Fairly vanilla shared lib build and use, e.g. Libbz2 library and bzip2 program using it, works fine (with the appropriate added -rpath or -L sprinkled places for reasons I can't always pin down).

[The vanilla libtool-2.4.7's libtool is already able to work on some sysv's, it's just that the regex match for the triplet was hardcoded to match e.g. sysv4 but not sysv4.0]

However the main thing shared libs would make a functional difference for is imlib2, since it is designed to be dlopenable module based. For that, the lack of a libm.so keeps most modules from building shared. Libtool does its thing where it tries to facilitate using them statically instead, and I tried some changes to use ltdl in the loader with .la libs passed with -dlopen in pursuit of dl pre open type dlopen simulation to work with that, and it builds incl figuring out to static link the la but it doesn't functionally give the module methods.

There must be something missing I need to add or change to get the libltdl based faux loading to work.

Alternately libm functions used seem pretty self contained, maybe I can roll my own shared ver.

[rakslice]

A good example of the difficulty of -rpath/-L needs is git; even though the only thing it's getting out of it is libz basically, the absence of the rpath once it's built against the shared one makes it not run ofc...but it took an excessive amount of trial and error cycles to figure out what to pass, and due to the nature of the git build that's a full build cycle of everything every time.

[rakslice]

Pulling on the thread of libltdl some more, even when everything else is made ideal, we can't build libltdl.so free of unresolved references because of course with the real shared lib backend enabled it requires libdl and there is no libdl.so.

[rakslice]

Okay, so I was about to embark on rebuilding libm and libmp from vanilla svr4 sources elsewhere for shared library versions, but then I realized that the .o objects in the existing libraries are already identified by file as relocatable, so I just scripted creating shared library versions from the objects from the stock libraries, for both libm and libmp, as well as libld. and the libdl that is called libdl.so but is just a regular archive.

With this, I had everything necessary to, in the the dynlibs branch, get all of the remaining dependencies of the Imlib2 modules building as shared libraries. (compilers.sh and then dynlibs.sh).

However when running a program that uses the resulting Imlib2 (Eterm for testing purposes), dlopen() immediately segfaults when loading some of the modules -- which ones it segfaults on load of is inconsistent from build to build, though it's consistent from run to run for a particular build. It's unclear why, or how to even debug the failure.

[rakslice]

I've had the situation twice where going from existing builds from before the dynlibs branch to using the dynlibs repacked shared libraries rebuilding libast/Eterm gives at least an imlib2 png module that loads and works, but trying to rebuild later gives broken png module. But I don't understand of steps that made this happen; when I try to do it on purpose it doesn't work. I still have no clue how to find out what is making the dlopens segfault.