[CFT] nALFS-1.2.0-gnubuild-pre2.tar.bz2

Kevin P. Fleming kpfleming at linuxfromscratch.org
Thu Oct 9 11:30:06 PDT 2003

Neven Has wrote:

> Well, handlers are like plugins now.  The program just reads all
> *.so files from one directory at startup.  There's no central place
> where all supported handlers are listed.  If that's what you mean?

Not quite, but close. I see your point, though, without using .so 
files for the handlers, and without libtool's help, it would have been 
harder to manage the handlers themselves, because of the problem you 
mention below.

> But anyway, static linking and compiling handlers in executable itself
> will have to change that in a way, as otherwise there would be a lot
> of multiple definitions of common variables that describe handlers.

When I get the libtool stuff done later this week (probably Friday 
night or Saturday), this will handled like magic. The first step is to 
switch to using libtool's "ltdl" module (which is why the source files 
are in the new tarball) to do the dlopen-ing and dlsym-ing; by itself, 
this doesn't buy us anything, other than allowing nALFS to be built on 
platforms that don't support shared libraries (like maybe uCLinux) and 
still function properly.

The next step is to tell libtool what libraries we intend to dlopen at 
build time. If (and only if) the user has chosen to disable shared 
libraries and produce a static build, libtool will build only static 
libraries, link them all into the executable, and provide a list of 
their symbols in a structure called LIBTOOL_PRELOADED_SYMBOLS, or 
something close to that. This means that nALFS can scan for 
"preloaded" modules as well, and initialize them.

So, the final nALFS code will scan the PRELOADED_SYMBOLS list (which 
will usually be empty), then attempt to dlopen the handlers. If the 
build was done as a static build, all the handlers will be found in 
the first step, and the second step won't find anything to dlopen.

More information about the alfs-discuss mailing list