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
> 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