The returned zero is clearly bogus; it should return a placeholder object. The problem is that code in the master does things like
if (objects[prog]) ...
which doesn't cope with objects with tricky `!. Fixed in many places.
Your kludge seems very adhoc. A better fix would be to delay the cyclic check one step further, so that the resolver can return the placeholder object.
/ Martin Stjernholm, Roxen IS
Previous text:
2002-11-27 17:47: Subject: Image.SSL?
Aha. Turning on RESOLV_DEBUG gave this insight:
BEGIN_CYCLIC(Array, 322eb8 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) Resolv("Array", "/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod") Resolv("Array", "/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod") => found 0 END_CYCLIC(Array, 322eb8 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod])
The resolv of "Array" short-circuits to a 0 in this case. This does not happen when dumping. In order for dumping of a module to work when the source file is in the module path, the masters resolve_cache must first be populated with an entry for the module name, so that the resolve() call can short-circuit. Adding
mkmodulename(0, file);
to the beginning of the dumpit function is enough to make this happen, although there might be a more obvious way to do it... :-)
This fix makes `make dump_modules' work decidedly better (X509 now has content again), so unless someone can think of a more beautiful fix RSN, I'm going to commit it.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)