Date: Thu, 8 Jan 1998 18:15:59 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: hasty@rah.star-gate.com (Amancio Hasty) Cc: tlambert@primenet.com, dap@damon.com, nate@mt.sri.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Motif question Message-ID: <199801081815.LAA15148@usr08.primenet.com> In-Reply-To: <199801080354.TAA03331@rah.star-gate.com> from "Amancio Hasty" at Jan 7, 98 07:54:52 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Heh. My main issue was the infernal "dladdr" that the FreeBSD dynamic > > loading code doesn't provide. The 1.1.5 stuff uses it to get the path > > of the shared library that's calling it so that it can go up two > > directories and down one to find where it left it's classes.zip. 8-(. > > Stupid way to do it... > > Terry, all you need to do is replace the dladdr kludge with argv[0] 8) You mean the path you get back from dladdr, right? The dladdr call is tricky. What it's actually looking for is the path to the shared library, NOT the path to the java program. If you create a program with a dladdr call for the address of a function in libc, you'll actually get back something other than what you expect; the path won't be filled out because the program image is not mapped in by the shared library -- and the name reference will actually reference a stub linked into your program. What you have to do is dlopen the path (ld.so does this), and then access the symbolic name to get the address in the shared image instead of the address of the stub. Then you call dladdr on the address, and it gives you the path to the shared library. This is basically for the JNI code to be able to associate shared libraries with class files; they are assumed to be located in the same relative location in all cases. You can hardcode the path (which the posted patches have always done), but you can't really derive it from argv[ 0]. Also, even if you could, you wouldn't want to, since it would prevent you from making a java image activator for the kernel -- which can't get at the process environment, or we'd have working variant symbolic links by now; another stupidity prevents that: POSIX's assumption of envp in evecve. This is actually related to the discussion at hand, since what you get as argv[0] is what was passed in the execve. Even if you can trust argv[ 0], you can't trust the envp to allow you to do the same path search off the same PATH variable. 8-(. Really, FreeBSD needs to support dladdr. The java stuff is big enough that it should run without modification on FreeBSD to incent use of FreeBSD -- ie: treat it as a validation suite. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801081815.LAA15148>