From owner-freebsd-stable Mon Jun 10 10:44:36 2002 Delivered-To: freebsd-stable@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id BB72E37B406 for ; Mon, 10 Jun 2002 10:44:30 -0700 (PDT) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.3/8.12.3) with ESMTP id g5AHiTCV009283; Mon, 10 Jun 2002 10:44:29 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.3/8.12.3/Submit) id g5AHiTiS009282; Mon, 10 Jun 2002 10:44:29 -0700 (PDT) (envelope-from dillon) Date: Mon, 10 Jun 2002 10:44:29 -0700 (PDT) From: Matthew Dillon Message-Id: <200206101744.g5AHiTiS009282@apollo.backplane.com> To: =?iso-8859-1?q?Claus=20Guttesen?= Cc: "Brian M. Kincaid" , FreeBSD-stable , bmk@adsl-64-174-159-18.dsl.sntc01.pacbell.net Subject: Re: unable to install jdk13 on 4.6 RC References: <20020610104113.29831.qmail@web14101.mail.yahoo.com> Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Oh, I should post to stable. I had an interesting conversation with Greg Lewis (maintainer of jdk13) and with some suggestions from him was able to track my particular problem down. What it comes down to, in a nutshell, are side effects due to the linux emulation. The emulation will attempt to prefix all paths with "/compat/linux/" when doing a lookup. So, for example, if under linux emulation you go 'cd /etc' the emulation will throw you into /compat/linux/etc. If the lookup fails the emulator falls back to the true path. So, for example, if you 'cd /usr/tmp' and there is a /usr/tmp but no /compat/linux/usr/tmp then you will wind up in the real /usr/tmp. Generally speaking this mechanism works very well, but in the case of jdk13 the port is bootstrapping java using the 'java' binary under linux emulation. The 'java' binary does not just try the class paths handed to it on the command line. It will actually try to resolve each path one element at a time. My WRKDIRPREFIX was set to /usr/tmp and I had a softlink in /compat/linux/usr/tmp pointing to the real /usr/tmp. Under any other cirumstance this would have worked just fine, but the stupid 'java' binary was scanning the class path one element at a time and attempting to resolve softlinks itself, rather then simply handing the whole path to the OS. The java binary looked up /usr/tmp, saw the softlink (/compat/usr/tmp), then did a readlink. The readlink of course returned "/usr/tmp". The java binary then looped, tring to look up the softlink's path "/usr/tmp" and wound up at the "/compat/linux/usr/tmp" softlink again (the SAME softlink). * lookup /usr (Finds /compat/linux/usr) * finds that /usr is a normal directory, so it continues * lookup /usr/tmp (Finds /compat/linux/usr/tmp softlink) * issues a read link, gets "/usr/tmp" back, loops * lookup /usr/tmp (Finds /compat/linux/usr/tmp softlink) * issues a read link, gets "/usr/tmp" back, loops * lookup /usr/tmp (Finds /compat/linux/usr/tmp softlink) * issues a read link, gets "/usr/tmp" back, loops * ... repeat until it gives up The result: The 'java' binary could not find the classes in the port's working directory even though it was being handed a perfectly valid class path. The solution in my case was to remove the /compat/linux/usr/tmp softlink I had created. This causes a lookup of '/usr/tmp' under emulation to find the real /usr/tmp and works around the 'java' binary's problem of attempting to interpret softlinks. Now the 'java' binary does this: * lookup /usr (finds /compat/linux/usr) * finds that /usr is a normal directory, so it continues * lookup /usr/tmp (finds the real /usr/tmp) * finds that /usr/tmp is a normal directory, so it continues * lookup /usr/tmp/FreeBSD ... continues from there, eventually resolving the correct ports working directory path ... I consider this a bug in 'java'. I don't know why it insists on tracking the class path down one path element at a time. It's just plain dumb. In anycase, the problem you describe looks to be quite similar. If there are fragments of obsolete directories sitting in /compat/linux or in /usr/local java can get mightily confused. Not only java, but fragments in /compat/linux can lead GCC astray as well, causing it to locate an obsolete include file in /compat/linux/usr/include (etc...) rather then a more recently installed include file. But at least GCC does not try to track the include paths down one path-element at a time :-). -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message