Ronald Servant wrote: > On 1/31/07, Tim Ellison <[EMAIL PROTECTED]> wrote: >> Ah, the same way that we are doing the VMI library today. In fact, why >> not just make those thread functions part of the same VMI DLL, then >> there is only one stub replacement required? > > Hmmm... seems like a good idea, but we need to have the portlib link > against a shared library named hythr, so that at runtime it can in > fact find the real one provided by VM, or I am missing something > obvious?
In case of launcher this leads to a chicken-and-egg problem: launcher wants to use portlib before it parsed command line and decided what vmdir to add to PATH. If portlib will be linked to hythr.dll, then it defeats the purpose of having hythr.dll VM-specific, as VM-specific library is likely to be present in vmdir (and thus not available at the moment when hyprt.dll is loaded). Practically, at this moment this issue prevents having J9 and DRLVM installation in the same jre/ directory, as both depend on different hythr.dll, which needs to be along with hyprt.dll, and thus cannot be put into vmdir. > or perhaps we get rid of the name hythr and put those > functions in vmi as well? doesn't seem as clean to me. -- Salikh Zakirov
