Remove "warning: Replacing library search directory..." if caused by symbolic links

[jhpalmieri]

This follows up on #9896.

If there are symbolic links pointing to SAGE_ROOT, then running "sage -b" may cause a warning message like

warning: Replacing library search directory in linker command:
    "[actual SAGE_ROOT directory]/local/lib" -> "[link]/local/lib"

It can be distracting having warning messages print when there is actually nothing wrong, so the attached patch removes this warning. The warning will of course still print if the Sage library has actually been moved.

[leif]

Would perhaps look nicer (in the code) if you just replaced the two occurrences of os.path.normpath() by os.path.realpath(), but I'm ok with your solution, since it does preserve more of the "given" directory names.

os.path.normpath(SAGE_LOCAL+"/lib") should already be a fully dereferenced path (because SAGE_ROOT is), so you could omit the change into os.path.realpath(sage_libdir).

The warning will only show up on MacOS X anyway.

Unfortunately, on Darwin afaik os.path.realpath() does not necessarily return a unique name; perhaps this has meanwhile been fixed, but distutils still implement their own canonicalize_path() (or whatever it is called) for Darwin.

[jhpalmieri]

Would perhaps look nicer ...

Okay, here's a new patch.

Regarding SAGE_ROOT: note that on my Mac, '/Applications/sage' is a link pointing to the real directory '/Applications/sage_builds/sage-4.6/'.

sage: SAGE_ROOT
'/Applications/sage'

From the command line:

$ sage -sh

Starting subshell with Sage environment variables set.
Be sure to exit when you are done and do not do anything
with other copies of Sage!

Bypassing shell configuration files ...

SAGE_ROOT=/Applications/sage

So SAGE_ROOT is not actually "fully dereferenced", if that means what I think it means. In case it doesn't mean what I think it means:

sage: os.path.realpath(SAGE_ROOT) == SAGE_ROOT
False

So I think we need os.path.realpath in both places.

Unfortunately, on Darwin afaik os.path.realpath() does not necessarily return a unique name; perhaps this has meanwhile been fixed, but distutils still implement their own canonicalize_path() (or whatever it is called) for Darwin.

I don't know about this in general, but using os.path.realpath seems to fix this particular problem on my OS X machine.

[jhpalmieri]

(sage library patch)

[leif]

Replying to jhpalmieri:

Regarding SAGE_ROOT: note that on my Mac, '/Applications/sage' is a link pointing to the real directory '/Applications/sage_builds/sage-4.6/'. So SAGE_ROOT is not actually "fully dereferenced", if that means what I think it means.

sage: os.path.realpath(SAGE_ROOT) == SAGE_ROOT
False

So I think we need os.path.realpath in both places.

Ok, then (at least your) MacOS X lacks the readlink and realpath commands, or you've set SAGE_ROOT manually.

In general, I think it would be better to also assign os.path.realpath(...) to the Python variables SAGE_ROOT, SAGE_LOCAL etc. at the top of setup.py (line 32 ff.), which would also remove some redundant slashs.

Unfortunately, on Darwin afaik os.path.realpath() does not necessarily return a unique name; perhaps this has meanwhile been fixed, but distutils still implement their own canonicalize_path() (or whatever it is called) for Darwin.

I don't know about this in general, but using os.path.realpath seems to fix this particular problem on my OS X machine.

Me either. Perhaps just history (when distutils were not part of the Python distribution), otherwise wouldn't make much sense to have distutils use their own version, leaving the standard Python function limited.

[leif]

Ok, works as advertised. (I've only tested it on Linux by setting LDSHARED.)

[leif]

Hmmm, I just noticed if the paths are equivalent the "given" path doesn't get normalized, i.e. redundant slashs and ..././ etc. removed, so in the messages still the unnormalized rather than the effective path appears.

But that's an even minor issue.

[jhpalmieri]

Replying to leif:

Ok, then (at least your) MacOS X lacks the readlink and realpath commands, or you've set SAGE_ROOT manually.

I think that SAGE_ROOT is set in the script sage-env, by running "pwd" in an appropriate directory. Perhaps with the GNU version of this, it resolves all links. On Darwin, and it seems perhaps also on Solaris, you need to run "pwd -P" to do this. On sage.math, 'pwd -P' also resolves links. So we might also consider something like this change to sage-env:

sage-env

@@ -23 +23 @@
 ##########################################################################
 
 # GUESS SAGE_ROOT from pwd
-SAVEDIR="`pwd`"
+PWD="pwd -P"
+SAVEDIR="`$PWD`"
 if [ -f sage -a -d spkg ]; then
-    GUESSED_SAGE_ROOT="`pwd`"
+    GUESSED_SAGE_ROOT="`$PWD`"
 else 
     if [ -f ../../sage -a -d ../../spkg ]; then
         cd ../../
-        GUESSED_SAGE_ROOT="`pwd`"
+        GUESSED_SAGE_ROOT="`$PWD`"
     else
         GUESSED_SAGE_ROOT=""
     fi
 fi
 cd "$SAVEDIR"
 
-
 if [ "$SAGE_ROOT" = "" ]; then
     if [ "$GUESSED_SAGE_ROOT" = "" ]; then
         echo "Error: You must set the SAGE_ROOT environment"

(On the other hand, I don't understand why on sage.math, running 'pwd' from the command line in /scratch/palmieri/sage gives me "/scratch/palmieri/sage", while running it from sage-env gives me "/mnt/usb1/scratch/palmieri/sage-4.6".)

[leif]

Replying to jhpalmieri:

Replying to leif:

Ok, then (at least your) MacOS X lacks the readlink and realpath commands, or you've set SAGE_ROOT manually.

I think that SAGE_ROOT is set in the script sage-env, by running "pwd" in an appropriate directory.

But only if SAGE_ROOT is not already set, which isn't the case if you run some ./sage ... command, so it's a bit inconsistent.

Oh, but I see: $SAGE_ROOT/sage does not use readlink -e (which dereferences any symlink contained in its argument); without that, it returns an error if the last component is not a link. So if you have just links "in the middle", sage uses the basename of itself.

Perhaps with the GNU version of this, it resolves all links. On Darwin, and it seems perhaps also on Solaris, you need to run "pwd -P" to do this. On sage.math, 'pwd -P' also resolves links. So we might also consider something like this change to sage-env...

I wonder what new strange side-effects that would have... ;-)

(On the other hand, I don't understand why on sage.math, running 'pwd' from the command line in /scratch/palmieri/sage gives me "/scratch/palmieri/sage", while running it from sage-env gives me "/mnt/usb1/scratch/palmieri/sage-4.6".)

That depends on how you cd to a directory, or how a script is called. Which directory do you have in your path?

$0 should be set according to that inside a script, i.e. its basename should be the one where it was (first) found in your $PATH (i.e. even relative if you happen to have "." in your path and the script is in the current directory).