Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

scalac/fsc don't resolve symlinks before looking for standard libs #2092

Closed
scabug opened this issue Jun 25, 2009 · 16 comments
Closed

scalac/fsc don't resolve symlinks before looking for standard libs #2092

scabug opened this issue Jun 25, 2009 · 16 comments
Assignees
Milestone

Comments

@scabug
Copy link

scabug commented Jun 25, 2009

[arya@drfunkenstein path]$$ ls -l
total 1
lrwxrwxrwx 1 arya stud 55 2009-06-24 21:25 scala-2.8 -> /test/scala-2.8.0/bin/

[arya@drfunkenstein path]$$ /test/scala-2.8.0/bin/scalac -version
Scala compiler version 2.8.0.r18093-b20090624020115 -- Copyright 2002-2009, LAMP/EPFL

[arya@drfunkenstein path]$$ `realpath scala-2.8/scalac` -version
Scala compiler version 2.8.0.r18093-b20090624020115 -- Copyright 2002-2009, LAMP/EPFL

[arya@drfunkenstein path]$$ scala-2.8/scalac -version
ls: cannot access /net/hc295/arya/env/path/lib/*: No such file or directory
Exception in thread "main" java.lang.NoClassDefFoundError: scala/tools/nsc/Main
Caused by: java.lang.ClassNotFoundException: scala.tools.nsc.Main
	at java.net.URLClassLoader$$1.run(URLClassLoader.java:200)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
	at sun.misc.Launcher$$AppClassLoader.loadClass(Launcher.java:301)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
Could not find the main class: scala.tools.nsc.Main.  Program will exit.
[arya@drfunkenstein path]$$ 
@scabug
Copy link
Author

scabug commented Jun 25, 2009

Imported From: https://issues.scala-lang.org/browse/SI-2092?orig=1
Reporter: Arya Irani (refried)

@scabug
Copy link
Author

scabug commented Jun 25, 2009

Arya Irani (refried) said:
This example is also fun:

[arya@drfunkenstein ~]$$ `realpath \`which scalac\`` -version
Scala compiler version 2.8.0.r18093-b20090624020115 -- Copyright 2002-2009, LAMP/EPFL

[arya@drfunkenstein ~]$$ `which scalac` -version
ls: cannot access /net/hc295/arya/env/path/lib/*: No such file or directory
Exception in thread "main" java.lang.NoClassDefFoundError: scala/tools/nsc/Main
Caused by: java.lang.ClassNotFoundException: scala.tools.nsc.Main
	at java.net.URLClassLoader$$1.run(URLClassLoader.java:200)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
	at sun.misc.Launcher$$AppClassLoader.loadClass(Launcher.java:301)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
Could not find the main class: scala.tools.nsc.Main.  Program will exit.
[arya@drfunkenstein ~]$$ 

@scabug
Copy link
Author

scabug commented Jun 30, 2009

@paulp said:
This is something linux (or so I presume because system is not reported) or linux-distribution specific. Symlinks work fine on os x.

@scabug
Copy link
Author

scabug commented Jun 30, 2009

@refried said:
Whoops, yes it is Ubuntu Jaunty.

But just to confirm that Paul is testing the same thing: my symlink foo/bar points to the scala/bin directory. So whereas scala/bin/../lib exists, foo/bar/../lib doesn't.
But [path-pointed-to-by-foo/bar]/../lib does.

@scabug
Copy link
Author

scabug commented Jun 30, 2009

@paulp said:
Replying to [comment:5 arya]:

But just to confirm that Paul is testing the same thing: my symlink foo/bar points to the scala/bin directory. So whereas scala/bin/../lib exists, foo/bar/../lib doesn't.
But [path-pointed-to-by-foo/bar]/../lib does.

Ah. You are right, I was not testing the same thing. However I do not consider what you are reporting a bug. I vote to close this as invalid. What you are doing amounts to putting the scala scripts and the libs in different locations, and fixing it would require looking in both /path/to/link/../lib AND /path/to/file/../lib. I think it's better to say "don't do that."

@scabug
Copy link
Author

scabug commented Jun 30, 2009

@refried said:
No don't close it as invalid -- they're not actually in different locations, they are in the same physical location.

/path/to/bin-dir/../lib always works in the case where bin and lib are stored together, as they always would be after unpacking the scala distribution;

I can't think of any reasonable case where /path/to/bin-dir-link/../lib (the current behavior) would be what you want. It would mean some structure like:

/path/to/link/bin -> /path/to/scala/bin
/path/to/link/lib -> /path/to/scala/lib   
# why are you rebuilding all the root level links?

or

/path/to/link/bin -> /path/to/scala/bin
/path/to/link/lib  (physical directory)
or 
/path/to/link/lib -> /path/to/otherscala/lib
# mixing and matching different bin and lib dirs??

Even if you are trying to mix and match different components, just put them in the same physical directory, and /path/to/chimera-scala/bin/../lib will still work fine.

The reason I noticed this at all is that at my school, where we have a single home directory shared across machines of varied platforms (irix/sunos/solaris/redhat/ubuntu) which generally can't share binaries, I have an unusual setup where my path is built based on symlinks in the filesystem:

env/<arch>/path/<entries> -> various bin dirs
where <arch> is selected according to the current machine architecture

for example:

<path>/eclipse-3.4-x86_64 -> /net/hc295/arya/links/hd22-home/software/eclipse/eclipse-3.4-x86_64
<path>/jdk1.6.0_03 -> /net/hd22/pfunk/devtools/jdk1.6.0_03/bin/
<path>/scala-2.8 -> /net/hc295/arya/scala-2.8.0.r18093-b20090624020115/bin/

I know it's a weird situation, but scala is the first program I've run into trouble with on this. i.e. eclipse and javac both find their respective libraries fine.

Specifically, javac is looking for its libraries relative to the physical path to itself. Maybe the right fix is to look in both paths as you suggested (I'm not sure), but as long as we only support one or the other, I suggest switching it up, like Sun has. See:

[arya@drfunkenstein tmp4]$$ ls -l
total 0
lrwxrwxrwx 1 arya stud 24 2009-06-30 12:41 bin -> ../tmp3/jdk1.6.0_03/bin/
[arya@drfunkenstein tmp4]$$ bin/javac -version
javac 1.6.0_03
[arya@drfunkenstein tmp4]$$ mv `realpath bin`/../lib/ .
`../tmp3/jdk1.6.0_03/lib/' -> `./lib'
[arya@drfunkenstein tmp4]$$ ls -l
total 8
lrwxrwxrwx 1 arya stud  24 2009-06-30 12:41 bin -> ../tmp3/jdk1.6.0_03/bin/
drwxr-xr-x 2 arya pfunk 72 2007-11-03 20:25 lib
[arya@drfunkenstein tmp4]$$ bin/javac -version
Exception in thread "main" java.lang.NoClassDefFoundError: com/sun/tools/javac/Main
[arya@drfunkenstein tmp4]$$

@scabug
Copy link
Author

scabug commented Jun 30, 2009

@refried said:
P.S. You can see javac is not looking in both places for lib, only in /path/to/file/../lib

@scabug
Copy link
Author

scabug commented Jun 30, 2009

@refried said:
Actually I didn't realize the fix was so straightforward:

--- scalac.orig 2009-06-23 20:12:29.000000000 -0400
+++ scalac      2009-06-30 13:36:16.786948000 -0400
@@ -26,7 +26,7 @@
         SOURCE=`dirname "$SOURCE"`/${TARGET:-.};
     fi;
 done;
-SCALA_HOME=`dirname "$SOURCE"`/..;
+SCALA_HOME=`readlink \`dirname "$SOURCE"\``/..;
 SCALA_HOME=`cd "$SCALA_HOME"; pwd`;
 # Remove spaces from SCALA_HOME on windows
 if $cygwin; then

...and similarly in the other scripts where SCALA_HOME is initialized.

@scabug
Copy link
Author

scabug commented Jun 30, 2009

@cunei said:
I have not read all the details of this thread, but in any case readlink won't help much in that position: it will fail if the argument is a real dir rather than a link and your pwd will return the home dir :-). However, changing the pwd to pwd -P will resolve all the symbolic links, which is probably what you want. This should work:

  SCALA_HOME="$$(cd "$$(cd $$(dirname "$$SOURCE"); pwd -P)"/..; pwd)"

or, in simpler steps:

  SCALA_HOME=`dirname "$$SOURCE"`
  SCALA_HOME=`cd "$$SCALA_HOME"; pwd -P`
  SCALA_HOME=`cd "$$SCALA_HOME"/..; pwd`

@scabug
Copy link
Author

scabug commented Jun 30, 2009

@cunei said:
missed a pair of quotes (to deal with those pesky whitespaces in file names):

  SCALA_HOME="$$(cd "$$(cd "$$(dirname "$$SOURCE")"; pwd -P)"/..; pwd)"

@scabug
Copy link
Author

scabug commented Jun 30, 2009

@refried said:
Oops, you're right. readlink with the -f, -e, or -m options ought to work though. (At least on systems which provide readlink...)

@scabug
Copy link
Author

scabug commented Jul 1, 2009

@cunei said:
I am afraid readlink is not very portable: neither of the options you mention exist on BSD/OSX. Using pwd -P seems safer, as it is actually a bash/sh builtin command. I will commit a patch accordingly shortly.

@scabug
Copy link
Author

scabug commented Jul 1, 2009

@cunei said:
Fixed in r18176.

@scabug
Copy link
Author

scabug commented Jul 2, 2009

Arya Irani (refried) said:
Thanks guys.

@scabug
Copy link
Author

scabug commented Jul 2, 2009

Arya Irani (refried) said:
Whoops I didn't realize I had two accounts (refried and arya), sorry for any confusion.

@scabug scabug closed this as completed May 18, 2011
@scabug
Copy link
Author

scabug commented Nov 13, 2011

Commit Message Bot (anonymous) said:
(extempore in r25994) Working on the runners.

Removed assumption that bash is in /bin. Removed --posix option to bash.
Modernized shell constructs: $() instead of ``, [[ ]] instead of [ ].
Added -debug option for all runners which will show you the exact java
command line being run before running it. Added -usebootcp to complement
-nobootcp, and made regular classpath the default on cygwin. Quoted more
things to give us a fighting chance against spaces and parens in paths.

I took the waste-half-a-day step of installing vmware fusion so I could
install windows so I could install cygwin so I could install scala under
cygwin so I could see if it still worked. Seems to. We still desperately
need some way of testing not only everything I'm attempting to address
in this pile of patches but everything which is most likely now regressing.

:javap now sort of works on windows (not for repl-defined classes as yet)
if JAVA_HOME is set such that I can find tools.jar. Closes #4959.
(Risks breaking and) references #2092. References #622 since that
shouldn't be hard to get working.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants