From owner-freebsd-hackers Thu Jan 8 10:16:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA09978 for hackers-outgoing; Thu, 8 Jan 1998 10:16:35 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA09951 for ; Thu, 8 Jan 1998 10:16:18 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id LAA01378; Thu, 8 Jan 1998 11:16:10 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp04.primenet.com, id smtpd001353; Thu Jan 8 11:16:03 1998 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id LAA15148; Thu, 8 Jan 1998 11:15:59 -0700 (MST) From: Terry Lambert Message-Id: <199801081815.LAA15148@usr08.primenet.com> Subject: Re: Motif question To: hasty@rah.star-gate.com (Amancio Hasty) Date: Thu, 8 Jan 1998 18:15:59 +0000 (GMT) Cc: tlambert@primenet.com, dap@damon.com, nate@mt.sri.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199801080354.TAA03331@rah.star-gate.com> from "Amancio Hasty" at Jan 7, 98 07:54:52 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk > > 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.