TinyURL widget - shorten your URL's for free!

Enter a long URL to make tiny:

Thursday, November 23, 2017

Complete GNU Autotools shared library module project

What I dislike most about people posting their expertise online, is when they can't be bothered to be thorough and present a complete working anything.


It really reminds me of lonely introverts on StackExchange harassing nice people that just want a quick answer, not a sermon, and not a date.  You may remember when I read an article about lonely introverts and experimented on them by making something they couldn't resist to attack and tell me how smart they were; they couldn't help themselves but set their own hair on fire.  QED


When I solve a piece of technology I really do try to post a completed version of it so people can use it without the same effort needed to reassemble.


When someone boasts about their expertise on a topic, presents half an argument, then <hand wave - hand wave> proclaims "Ta Da!"- it works. The first thought I realize is does this person actually know how to finish this off? Where is the proof?

Leaving out details gives me no confidence in the proclaimer.

Oh yes, in theory, wave some knowledge around, and let you figure out the rest seems "helpful" but it's really more pretentious and pious than practical.

Enough soapbox.

Dynamic Modules Project

I posted on github a complete autotools project that configures a main program that dynamically loads a shareable module from another directory inside a notional apps directory.

Dynamic loadable modules are hard. GNU Autotools are hard. Few people work through an entire example start to finish.  My research led to lots of half-answers and due to the nature of the well-made interfaces of libtool and dlopen/dlsym there are many possible answers that might be the best for your application that won't look like this in the end. That's as far as I will go towards justifying others that present half solutions.  While one should cover a topic, one should also provide some answers to questions at the end.

In this project, the autotools configures shareable modules that have some of the symbol tables contain within the "app" code exposed ( see the .libs/libfoo.exp)  but some other symbols for functions and variable remain closed.

Here is the project tree inside src/:

.
├── apps
│   ├── Makefile
│   ├── Makefile.am
│   ├── Makefile.am~
│   ├── Makefile.in
│   └── test
│       ├── foo1.c
│       ├── foo1.c~
│       ├── libfoo.la
│       ├── libfoo_la-foo1.lo
│       ├── libfoo_la-foo1.o
│       ├── Makefile
│       ├── Makefile.am
│       ├── Makefile.am~
│       ├── Makefile.in
│       ├── test.c
│       └── test.c~
├── dynamic
├── dynamic-main.o
├── main.c
├── Makefile
├── Makefile.am
├── Makefile.in
└── tree.out

 Of course, the internal build is one flavour of the programming philosophy. Some developers imagine keeping the source files pristine and building outside, like RTEMS. That is justified when autotools tends to cache too much data only to ruin work down the road. Of course, one can just toast the entire folder and start over. Each school has merits.

This project is setup somewhat like a distributed, modular software build would look like. Instead of a number of main applications communicating with pipes etc. this project uses self contained "apps" that are dynamically loaded into the running main code. The apps are segmented into a sub-sub folder. The hack is direct knowledge of the shared library underneath. I can solve that too but that distracts from the point of the interfacing. You can get libtool to make .so libraries and not use the libtool lt_dlopen versions. You can configure autotools to control it.


In this case a .so library (libfoo.so) without version numbers is created in src/apps/test that is loaded somewhere else in the build tree.

The main function calls the function using a pointer to function and a variable is passed to the internal function in a closed part of the library for execution.

Notice that while the shared library may be called many times, the internal static int count is always one. That changes the assumed behaviour one might expect.