On 9/11/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote:
2006/9/11, Evgueni Brevnov <[EMAIL PROTECTED]>: > On 9/11/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote: > > 2006/9/11, Geir Magnusson Jr. <[EMAIL PROTECTED]>: > > > > > > > > > Evgueni Brevnov wrote: > > > > On 9/9/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > > >> There seems to be no easy solution, other than parse LD_LIBRARY_PATH or > > > >> PATH... > > > > > > > > Is vmcore.dll (now harmonyvm.dll) and kernel.jar should always reside > > > > in one directory? > > > > > > I was thinking about this for packaging - that way you can have : > > > > > > jre/ > > > bin/ > > > j9/ > > > drlvm/ > > > > > > and setup a symlink if you wish. > > > > > > if we have kernel.jar in jre/lib/boot as we do now, it's must less > > > convenient and probably error prone to switch back and forth. > > > > > > > If yes then we can take vmcore.dll base path as a > > > > location of kerenel.jar. > > > > > > Sure - where will you get that? and what do you w/ .so's in unix? I've > > > come to the conclusion that the only way will be to manually run the > > > PATH (win) and LD_LIBRARY_PATH (linux) > > > Geir, it seems you are right. I failed to find appropriate solution on > Linux. Parsing LD_LIBRARY_PATH can be an option here. Or we can use > deployment process to set up application specific environment > variable.Well, with a bit of googling I've managed to obtain the following snippet [1]: if (dladdr( addr, &info ) != 0) { strncpy( path, info.dli_fname, PATH_MAX ); *(strrchr( path, '/' )) = '\0'; } "The dladdr() function shall query the dynamic linker for information about the shared object containing the address addr." [2] Moreover, google reports about "dladdr" in a variety of manuals, including BSD, SGI, MacOS, Solaris etc, I've listed some of the links below. So this looks like a silver bullet for us :)
Great! It should work for us. With this approach it is possible not to depend on LD_LIBRARY_PATH and PATH at all.
[1] http://lists.trolltech.com/qt-interest/2003-11/msg00380.html [2] http://refspecs.freestandards.org/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/baselib-dladdr-3.html [3] http://developer.apple.com/documentation/Darwin/Reference/ManPages/man3/dladdr.3.html [4] http://docs.sun.com/app/docs/doc/816-5168/6mbb3hr4c?a=view > > > IIUC, j9 does this in astonishingly simple way - it just specifies > > "-Xbootclasspath/p:%LAUNCHER_HOME%/default/luni-kernel.jar" in the > > "<vmdir>/harmonyvm.properties" file, and the launcher does the rest. > > Namely, it automatically reads that file, replaces %LAUNCHER_HOME% > > with actual location and feeds extra arguments to VM among user's > > ones. > > This solution looks sufficient for now, but it seems to be only > > partial: it does not work for pure Invocation API usecase. Besides, > > those hardcoded arguments to VM appear confusing in some cases - e.g. > > it is impossible to override kernel.jar via command-line. Also note > > hardcoded "default" vmdir. > > > > As for the .so locations, I'm not sure if there is portable solution > > (parsing LD_LIBRARY_PATH looks error-prone). Maybe better solution > > would be leave this to user - for setting JAVA_HOME or such... > > > > -- > > Alexey > > > > > > > > geir > > > > > > > > > > > > > > >> > > > >> geir > > > >> > > > >> Geir Magnusson Jr. wrote: > > > >> > I'll figure this out myself if I don't get a quick answer, but I think > > > >> > we should put the DRLVM kernel classes jar(s) in the same directory as > > > >> > the rest of the DRLVM artifacts so that it's easy to switch between VMs > > > >> > using the launcher. (J9 does this). > > > >> > > > > >> > How does DRLVM decide where to look? > > > >> > > > > >> > (I'm re-doing the DRLVM build to finish integrating the launcher > > > >> > properly, and figure that a nice thing to add is a DRLVM-snapshot that > > > >> > just drops into classlib/deploy/jdk/jre/bin the same way J9 does for > > > >> > developers.... > > > >> > > > > >> > geir > > > >> > > > > >> > --------------------------------------------------------------------- > > > >> > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > >> > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > >> > For additional commands, e-mail: [EMAIL PROTECTED] > > > >> > > > > >> > > > >> --------------------------------------------------------------------- > > > >> Terms of use : http://incubator.apache.org/harmony/mailing.html > > > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > > > >> For additional commands, e-mail: [EMAIL PROTECTED] > > > >> > > > >> > > > > > > > > --------------------------------------------------------------------- > > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
