> So it appears that on any OS without an ruserpass(), if the order is
> "libmh.a libmts.a", the build will fail with:
> > Undefined first referenced
> > symbol in file
> > ruserpass ../mts/libmts.a(smtp.o)
> If the order is "libmts.a libmh.a", on the other hand, the build will fail
> with:
> > m_getfld.c:555: undefined reference to `mmdlm2'
> > m_getfld.c(.pr+0xd62): undefined reference to `mmdlm2'
> > m_getfld.c:556: undefined reference to `mmdlm2'
> > m_getfld.c:557: undefined reference to `mmdlm2'
Ok, so the dependency graph appears to be (forgive my ASCII art):
anno
____| |____
| |
| smtp
| |
libmh_____ |
|
generic
I picked "anno" simply as an example. smtp needs libmh for
ruserpass, and libmh need generic for some mmdl* stuff. This
was not a problem before, since the generic mts code was in zotnet
and the dependencies could be resolved at link time via the proper
ordering. With generic and smtp both in the same archive, this
can't be done.
When I merged the generic and smtp into a libmts, I mistakenly
thought that libmh wouldn't have dependencies on other code, which
I would say is not an unreasonable assumption. Two solutions present
themselves:
1) split the generic code back into another archive and handle the
problem by changing the order in the Makefiles.
2) move the generic code into sbr/ and add it to libmh
I personally would prefer 2) as it makes libmh more self-contained
and we don't need to worry about dependency graphs as much. I have
some concerns that the code may not play nicely as a part of libmh because
it appears to try to override some functions, but we'll know for sure
whether it's a real problem soon.
1) would probably be the safest option, since it was known to work with
the libzot stuff. But I don't particularly care for the approach. And if
anyone chooses to use some of this code, they will need to spend time
figuring out dependencies that we should really make transparent.
Thoughts?
Shantonu
