This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
In my experience, it is almost always best, in the long run, to stay away from all things system-specific, when there is a less graceful but workable portable solution at hand. I am concerned that _init functions will not work outside of ELF shared libraries. I am concerned that C++ constructors (or GCC's constructor attributes) are not portable to other compilers. Suppose the name of the library's entry point function is computed from the module name (not the library name). I'm not convinced that modules are renamed often enough that this is a problem. Any errors will be caught early (since you can't use the library at all), and are easy to fix. >In a dynamically linked environment, the registration function >immediately calls the initialization function. In a statically linked >environment, the registration function accumulates all initialization >functions and call them once Guile has been booted. The choice >between the two can be made automatic. A global flag (initially zero) >indicates whether Guile has been booted. If not, then the >registration procedure accumulates pointers in a table, otherwise it >calls its argument. Whenever Guile has been booted, the flag is set >to one and the accumulated pointers are called. I believe Marius's scm_register_module_xxx function implements an arrangement like this.