102 |
asked to load a frozen file that requires versions of modules with |
asked to load a frozen file that requires versions of modules with |
103 |
interface versions unsupported by the current release. |
interface versions unsupported by the current release. |
104 |
|
|
105 |
|
+ Some liberties are take with preloaded modules using one another's |
106 |
|
symbols. This only works (portably) because the modules that do it |
107 |
|
(m4.so and gnu.so) are both statically linked into the core. Need to |
108 |
|
investigate how this can be supported for any module, on platforms that |
109 |
|
don't support backlinking. Maybe exporting symbol name/address pairs |
110 |
|
into a table maintained by libm4, and only using module symbols through |
111 |
|
that table in other modules. |
112 |
|
|
113 |
|
+ On a related note, modules should be able to declare that they require |
114 |
|
other modules to be loaded before they can work -- and the module loader |
115 |
|
should take care of that. Should such required modules be fully loaded |
116 |
|
into the symbol table? Or merely loaded into memory so that the C level |
117 |
|
code is callable? |
118 |
|
|
119 |
+ Setting of the module search path within m4 scripts: |
+ Setting of the module search path within m4 scripts: |
120 |
|
|
121 |
append(__modulepath__, `/some/modules/live/here') |
append(__modulepath__, `/some/modules/live/here') |