Date: Mon, 10 Jun 2002 10:44:29 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: =?iso-8859-1?q?Claus=20Guttesen?= <cguttesen@yahoo.dk> Cc: "Brian M. Kincaid" <bmk@adsl-64-174-159-18.dsl.sntc01.pacbell.net>, FreeBSD-stable <stable@FreeBSD.ORG>, bmk@adsl-64-174-159-18.dsl.sntc01.pacbell.net Subject: Re: unable to install jdk13 on 4.6 RC Message-ID: <200206101744.g5AHiTiS009282@apollo.backplane.com> References: <20020610104113.29831.qmail@web14101.mail.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Oh, I should post to stable. I had an interesting conversation with
Greg Lewis <glewis@eyesbeyond.com> (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
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200206101744.g5AHiTiS009282>