Hi I'm 80% done with my reorganization into a Rivet namespace (actually this was done long ago) but I hit a point I'd like to well understand before committing my work in branches/rivet-namespace for everyone to see it.
I moved the commands in librivet.so into a new package called... RivetLib. Since these commands are documented with the core commands (well, not all of them are in the manual....) I decided to let the module include them by requiring RivetLib during the phase of interp initialization (Rivet_PerInterpInit). I found out this caused segfaults all the time in an apparently unrelated callback of Rivet (Rivet_ServerConf). To add fun to the business I found out that everything was fine if init.tcl did the good usual 'package require' on RivetLib. While this proved to be a solution it bothered me a lot: the C code for requiring RivetLib was executed right after init.tcl was run in mod_rivet, so it didn't make sense and was matter of concern about something important I could be missing. Then I found in configure.ac this remark (and related macros commented away) # # stubs are causing segmentation violations when mod_rivet is getting # loaded into apache. it would be nice if we did no stubs for this and # still did stubs for librivet and librivetparser, which seem to be OK. # #AC_DEFINE(USE_TCL_STUBS,1,[Define to link against the Tcl stub library]) #AC_DEFINE(USE_TK_STUBS) I wrote a sort of null library and compiled it with the same compiler options rivetlib is compiled and linked, still my fake library get into mod_rivet gently. Why? Anyone knows if this has something to do with the stubs, like the comment above suggests? thanks -- Massimo P.S. librivet commands coded in rivetCrypt.c and rivetList.c still have to be documented. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
