I think I've somewhat misunderstood the issue. --export-dynamic appears to not truly be necessary, and when building from upstream sources the build now includes a few sample loadable modules.
When building the upstream source (the "master" branch of https://github.com/att/ast, which is still identified as 93u+ 2012-08-01) using its own build script ("bin/package make"), ksh is not linked with --export-dynamic (I don't quite understand how its loadable modules work without ksh being linked --export-dynamic), but it does build the sample loadable modules that are included with the distribution (including "open.c" which I used as an example in the bug report) - and that build of Korn Shell will be able to load and run those modules: $ ./bin/package make # And then wait a while for it to build... $ ./arch/linux.i386-64/bin/ksh --version # Copy I built from Git version sh (AT&T Research) 93u+ 2012-08-01 $ ./arch/linux.i386-64/bin/ksh $ builtin -f arch/linux.i386-64/lib/ksh/libopen.so open $ open # Runs the builtin from libopen.so Usage: open [-abcirwx] [-m mode] var file But loading this module from the version from Debian (93u+20120801-2+b1) fails: $ ksh --version # Installed copy version sh (AT&T Research) 93u+ 2012-08-01 $ ksh $ builtin -f arch/linux.i386-64/lib/ksh/libopen.so open # Loading the libopen.so built from git builtin: arch/linux.i386-64/lib/ksh/libopen.so: libshell.so: cannot open shared object file: No such file or directory If I download the Debian ksh source package and build it, and try that, I get a similar failure. I'm not entirely sure why it works on the one from upstream (with no --export-dynamic) or why it doesn't work on the packaged one (which describes itself as the same version from the package...) So it's hard for me to gauge exactly what's going on here: - The installed copy of "ksh" is stripped, and stripping "ksh" apparently makes it incompatible with modules built from a non-stripped build. (I don't know if stripping ksh makes it incompatible with modules entirely...) - I also rebuilt ksh in the Debian package source tree without using the Debian build rules, yielding an unstripped 93u+ with Debian patches. This was also incompatible with the loadable module built from git. - I attempted to manually build libopen.so in the Debian build tree, using compile and link commands from another successful build, and that also didn't work, so I can't determine if the feature really was broken on that version, and has since been fixed, or if it's just a build issue. The upshot is that it's pretty easy to get a working demonstration of this feature from the upstream copy in git now. I'll see if I can figure out why it's still not working with the packaged version.
