Tcl Source Code

Shared libraries providing Tcl extensions are loaded for the Unix family by the code in tclLoadDl.c, which interfaces Tcl with the dlopen(<library_path>,flags) system call. Tcl chose to set dlopen's flags argument as RTLD_NOW | RTDL_GLOBAL. Globally loading the extension symbols  was found to crash an application (Apache Rivet) that embeds a Tcl interpreter, which in turn gains access to a subset of the application commands by loading an extension library. The application successfully loads the library by calling Tcl_PkgRequire, but crashes shortly after in a function unrelated to the extension library. Replacing Tcl_PkgRequire with a direct call to dlopen and passing RTLD_NOW | RTLD_LOCAL as second argument restores mod_rivet (and Apache) full functionality. On the other hand, it was also verified that setting in tclLoadDl.c the flags argument as RTLD_NOW | RTLD_LOCAL  and building a custom Tcl installation against which Rivet gets linked, preserves Apache functioning even when the extension is loaded by calling Tcl_PkgRequire, thus fully identifying the problem with the RTLD_GLOBAL flag.

Note for people getting tripped by the reintroduced bug #1961211, notably on Darwin, i.e. OS X. 
If your library is linked using -flat_namespace and fails to load with a message like

dyld: Symbol not found: ...
   Referenced from: ...
   Expected in: flat namespace
 
 Trace/BPT trap


then this option has to be removed, and a possibly present -undefined suppress|warning as well, to make the library loadable again.

This happened for Metakit.

allow_comments - 1

See discussion about this among TCT members:
<https://sourceforge.net/mailarchive/message.php?msg_id=27211924>

Conclusion: dlopen should use: (RTLD_NOW|RTLD_LOCAL)

If this causes problems for anyone, please report this, there
sure is another solution without breaking applications
that embed Tcl (that's what this issue is about....).

Fixed on trunk and core-8-5-branch.
Untouched on core-8-4-branch.

File Added - 404492: 3216070.patch