Sage: Ticket #9210: pkg-config's prefix statements in SAGE_LOCAL/lib/pkgconfig not changed upon Sage move
https://trac.sagemath.org/ticket/9210
<p>
The attached patch fixes the above issue which causes matplotlib to pick up the system freetype2 after moving Sage (even after <a class="closed ticket" href="https://trac.sagemath.org/ticket/9208" title="defect: Add PKG_CONFIG_PATH to sage-env so programs like matplotlib link properly. (closed: fixed)">#9208</a>). One thing led to another and I ended up restructuring and rewriting lots of the code in the file too. I hope it's cleaner and has less portability issues (I changed a lot of things to use os.path.join, for example).
</p>
en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/9210
Trac 1.1.6jasonFri, 11 Jun 2010 06:15:59 GMTstatus changed
https://trac.sagemath.org/ticket/9210#comment:1
https://trac.sagemath.org/ticket/9210#comment:1
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_review</em>
</li>
</ul>
<p>
Note that if you've already moved your build directory, you will have to move it again to trigger the code in this patch that updates the pkg-config file paths.
</p>
TicketjasonFri, 11 Jun 2010 06:42:00 GMT
https://trac.sagemath.org/ticket/9210#comment:2
https://trac.sagemath.org/ticket/9210#comment:2
<p>
<a class="closed ticket" href="https://trac.sagemath.org/ticket/5776" title="defect: sage-location ought to rewrite loads of files in $SAGE_LOCAL/bin (closed: fixed)">#5776</a> is related (it's a general ticket about the stuff that old paths that still hang around in various places).
</p>
TicketjasonFri, 11 Jun 2010 16:59:25 GMTstatus changed
https://trac.sagemath.org/ticket/9210#comment:3
https://trac.sagemath.org/ticket/9210#comment:3
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
In the R .pc file, there are still some other directories that are not changed (besides just the prefix directory).
</p>
TicketjasonFri, 11 Jun 2010 20:39:14 GMTattachment set
https://trac.sagemath.org/ticket/9210
https://trac.sagemath.org/ticket/9210
<ul>
<li><strong>attachment</strong>
set to <em>trac-9210-rewrite-sage-location.patch</em>
</li>
</ul>
<p>
apply to sage-scripts repository
</p>
TicketjasonFri, 11 Jun 2010 20:40:20 GMTstatus changed
https://trac.sagemath.org/ticket/9210#comment:4
https://trac.sagemath.org/ticket/9210#comment:4
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
</ul>
<p>
Updated script to initially set a SAGE_ROOT variable inside the file, and then just update that variable. This should take care of all paths in the file that need to be changed.
</p>
TicketdrkirkbyFri, 11 Jun 2010 21:38:07 GMT
https://trac.sagemath.org/ticket/9210#comment:5
https://trac.sagemath.org/ticket/9210#comment:5
<p>
I've started to build the binary on my old Blade 1000. It's not the fastest machine in the world, (not even the fastest SPARC I own, but its convenient at the minute). It will take a few hours to build this, unpack it, then check for hard-coded paths. But I'm working on it. If I can stay awake, I might have something by 0200 GMT on Saturday.
</p>
<p>
Dave
</p>
TicketdrkirkbyFri, 11 Jun 2010 22:28:43 GMT
https://trac.sagemath.org/ticket/9210#comment:6
https://trac.sagemath.org/ticket/9210#comment:6
<p>
It was a lot quicker than I expected.
</p>
<p>
Something has gone wrong here though. The installation worked fine before it was moved. First I create the binary.
</p>
<pre class="wiki">drkirkby@redstart:~/32/sage-4.4.3$ ./sage -bdist 4.4.3-ax
Sage works!
Copying files over to tmp directory
local/lib/python2.6/python2.6: failed to get acl entries
local/lib/libgfortran.so: failed to get acl entries
cp: cannot access *.sage
Copying Sage library over
Making empty spkg's
</pre><p>
I think we need to copy libgfortran (see <a class="closed ticket" href="https://trac.sagemath.org/ticket/8049" title="defect: libgfortran *must* get shipped with the Sage binaries (closed: fixed)">#8049</a>) though the failure to do so should not cause me a problem, as the system has it. But when I tried to move the distribution, I get:
</p>
<pre class="wiki">-bash-3.00$ ./sage
----------------------------------------------------------------------
| Sage Version 4.4.3, Release Date: 2010-06-04 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
The Sage install tree may have moved
(from /export/home/drkirkby/32/sage-4.4.3 to /export/home/sageserv/sage-4.4.3-after-rewrite-sage-location-patch-Solaris10_03_2005-sun4u-SunOS)
Changing various hardcoded paths
(please wait at most a few minutes)...
Do not interrupt this.
Done resetting paths
------------------------------------------------------------
Unhandled SIGSEGV: A segmentation fault occured in Sage.
This probably occured because a *compiled* component
of Sage has a bug in it (typically accessing invalid memory)
or is not properly wrapped with _sig_on, _sig_off.
You might want to run Sage under gdb with 'sage -gdb' to debug this.
Sage will now terminate (sorry).
------------------------------------------------------------
</pre><p>
I don't have gdb on this machine. I'll investigate, but for now, there may be a problem here.
</p>
<p>
Dave
</p>
TicketdrkirkbyFri, 11 Jun 2010 22:43:46 GMTowner changed
https://trac.sagemath.org/ticket/9210#comment:7
https://trac.sagemath.org/ticket/9210#comment:7
<ul>
<li><strong>owner</strong>
changed from <em>GeorgSWeber</em> to <em>drkirkby</em>
</li>
</ul>
<p>
On closer inspection, gdb was on the machine, so I run sage with the option -gdb.
</p>
<p>
The SIGSEGV seems to be caused by Singular failing to find a file 'tesths.cc' though that file does exist.
</p>
<pre class="wiki">-bash-3.00$ export PATH=$PATH:/usr/local/bin
-bash-3.00$ ./sage -gdb
----------------------------------------------------------------------
| Sage Version 4.4.3, Release Date: 2010-06-04 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
/export/home/sageserv/sage-4.4.3-after-rewrite-sage-location-patch-Solaris10_03_2005-sun4u-SunOS/local/bin/sage-ipython
GNU gdb (GDB) 7.0.1
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.10".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /export/home/sageserv/sage-4.4.3-after-rewrite-sage-location-patch-Solaris10_03_2005-sun4u-SunOS/local/bin/python...done.
[Thread debugging using libthread_db enabled]
[New Thread 1 (LWP 1)]
Python 2.6.4 (r264:75706, Jun 6 2010, 00:37:24)
[GCC 4.4.3] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
siInit (name=0x1e169b4 <error reading variable>) at tesths.cc:65
65 tesths.cc: No such file or directory.
in tesths.cc
Current language: auto
The current source language is "auto; currently c++".
(gdb) quit
A debugging session is active.
Inferior 1 [process 6182 ] will be killed.
Quit anyway? (y or n) y
-bash-3.00$ find . -name tesths.cc
./spkg/standard/singular-3.1.0.4.p6/src/Singular/tesths.cc
-bash-3.00$ cat ./spkg/standard/singular-3.1.0.4.p6/src/Singular/tesths.cc
/****************************************
* Computer Algebra System SINGULAR *
****************************************/
/* $Id: tesths.cc,v 1.115 2008/09/10 09:33:58 Singular Exp $ */
</pre><p>
Do you think this can be related? It was fine before the distribution was moved.
</p>
<p>
Dave
</p>
TicketjasonFri, 11 Jun 2010 23:33:06 GMT
https://trac.sagemath.org/ticket/9210#comment:8
https://trac.sagemath.org/ticket/9210#comment:8
<p>
It doesn't seem like it should be related (i.e., my guess is that you'd have this problem without the patch as well). Can you zip up the SAGE_LOCAL/lib/pkgconfig/ directory and the SAGE_LOCAL/lib/sage-current-location.txt file so I can just double-check that the paths are right?
</p>
TicketdrkirkbySat, 12 Jun 2010 00:52:47 GMT
https://trac.sagemath.org/ticket/9210#comment:9
https://trac.sagemath.org/ticket/9210#comment:9
<p>
Sure. I've attached two .tar.gz files. It should be obvious which is which from the name. Note I created a second user account to test the moved version on, so you might see different user names on the two tarballs.
</p>
TicketdrkirkbySat, 12 Jun 2010 00:53:32 GMTattachment set
https://trac.sagemath.org/ticket/9210
https://trac.sagemath.org/ticket/9210
<ul>
<li><strong>attachment</strong>
set to <em>after-moving.tar.gz</em>
</li>
</ul>
<p>
After creating a binary distribution and moving it to somewhere else.
</p>
TicketdrkirkbySat, 12 Jun 2010 00:54:33 GMTattachment set
https://trac.sagemath.org/ticket/9210
https://trac.sagemath.org/ticket/9210
<ul>
<li><strong>attachment</strong>
set to <em>before-moving.tar.gz</em>
</li>
</ul>
<p>
The files were Sage was built.
</p>
TicketjasonSat, 12 Jun 2010 02:10:05 GMT
https://trac.sagemath.org/ticket/9210#comment:10
https://trac.sagemath.org/ticket/9210#comment:10
<p>
Enough stuff looked fishy in your output that I have to ask: Are you using the most recent version of the patch? From the pkg-config files, it doesn't look like it.
</p>
<p>
What commands are you running? The following two sequences of commands should work to update the .pc files:
</p>
<ol><li>Build sage from source in directory A
</li></ol><ol start="2"><li>Run Sage (this may be optional---it depends on if the build creates a correct local/lib/sage-current-location.txt file)
</li></ol><ol start="3"><li>Move the sage build directory to directory B
</li></ol><ol start="4"><li>Run Sage in the new directory (this updates the sage-current-location.txt file, and also updates the .pc files, etc.)
</li></ol><p>
Then the file paths should be updated.
</p>
<p>
Alternatively, this should work:
</p>
<ol><li>Build sage from source in directory A
</li></ol><ol start="2"><li>Make a bdist (this automatically runs Sage, so it takes care of step 2 above)
</li></ol><ol start="3"><li>Extract the bdist
</li></ol><ol start="4"><li>Run Sage in the new directory (this updates the sage-current-location.txt file, and also updates the .pc files, etc.)
</li></ol><p>
In either situation, at the top of each local/lib/pkgconfig/*.pc file, there should be a SAGE_ROOT=new directory after step 3, and the local/lib/sage-current-location.txt file should also contain the new directory name. Neither of those are true for your attached outputs, so I think either you are using the old version of the patch or didn't follow one of the steps. Or my code has a bug :).
</p>
TicketjasonSat, 12 Jun 2010 02:12:27 GMT
https://trac.sagemath.org/ticket/9210#comment:11
https://trac.sagemath.org/ticket/9210#comment:11
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9210#comment:10" title="Comment 10">jason</a>:
</p>
<blockquote class="citation">
<p>
In either situation, at the top of each local/lib/pkgconfig/*.pc file, there should be a SAGE_ROOT=new directory after step 3
</p>
</blockquote>
<p>
I meant after step 4.
</p>
TicketdrkirkbySat, 12 Jun 2010 02:20:35 GMT
https://trac.sagemath.org/ticket/9210#comment:12
https://trac.sagemath.org/ticket/9210#comment:12
<p>
I'll have to look at this later today - it is 3:19 am here! It's possible I don't have the latest patch, or I've somehow mess up installing it. Could you attach the full file (not just the patch) of whatever you think I might have wrong. I'll then copy that in directly.
</p>
<p>
Dave
</p>
TicketdrkirkbySat, 12 Jun 2010 16:52:38 GMT
https://trac.sagemath.org/ticket/9210#comment:13
https://trac.sagemath.org/ticket/9210#comment:13
<p>
I thought I might have messed up, as I was tired, but as far as I can see, I do get a problem.
</p>
<p>
The method I used was:
</p>
<ol><li>Build sage from source in directory /export/home/drkirkby/32/sage-4.4.3
</li></ol><ol start="2"><li>Make a binary distribution using your updated sage-bdist, which I've confirmed works on other systems and mine.
</li></ol><ol start="3"><li>Log in as a different user 'sageserv' on my system.
</li></ol><ol start="4"><li>Extract the binary .tar.gz file, which was extracted to
</li></ol><p>
/export/home/sageserv/sage-4.4.3-after-rewrite-sage-location-patch-Solaris10_03_2005-sun4u-SunOS
</p>
<ol start="5"><li>Run Sage in the new directory, where upon I get the seg fault. But in the other directory, as a different user name, it works fine.
</li></ol><p>
As far as I can see, I have the latest patches. These are the sizes of the patched files.
</p>
<pre class="wiki">-rwxr-xr-x 1 drkirkby other 3680 Jun 9 23:54 sage-bdist
-rwxr-xr-x 1 drkirkby other 10216 Jun 10 20:00 sage-env
-rwxr-xr-x 1 drkirkby other 7133 Jun 12 15:40 sage-location
</pre><p>
The 'sage-location' script starts
</p>
<pre class="wiki">#!/usr/bin/env python
import os, sys
OLD_SAGE_ROOT = None
SAGE_ROOT = os.path.realpath(os.environ['SAGE_ROOT'])
location_file = os.path.join(SAGE_ROOT, 'local', 'lib', 'sage-curent-location.txt')
flags_file = os.path.join(SAGE_ROOT, 'local', 'lib', 'sage-flags.txt')
# The flags we care about recording in the local/lib/sage-flags.txt file
# In SAGE_FAT_BINARY mode we only require that ['sse', 'sse2', '3d',
# 'mmx', 'cmov'] be available, and in particular, don't require pni
# or ssse3.
try:
SAGE_FAT_BINARY = os.environ['SAGE_FAT_BINARY']
except:
SAGE_FAT_BINARY = ""
</pre><p>
Anything look wrong?
</p>
<p>
Dave
</p>
TicketjasonSat, 12 Jun 2010 17:22:45 GMTattachment set
https://trac.sagemath.org/ticket/9210
https://trac.sagemath.org/ticket/9210
<ul>
<li><strong>attachment</strong>
set to <em>sage-location</em>
</li>
</ul>
<p>
new sage-location file (after patch) - do not apply; only for reviewing convenience
</p>
TicketjasonSat, 12 Jun 2010 17:23:42 GMT
https://trac.sagemath.org/ticket/9210#comment:14
https://trac.sagemath.org/ticket/9210#comment:14
<p>
I've attached the full (new) sage-location script, for reviewing convenience.
</p>
TicketjasonSat, 12 Jun 2010 17:25:08 GMT
https://trac.sagemath.org/ticket/9210#comment:15
https://trac.sagemath.org/ticket/9210#comment:15
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9210#comment:13" title="Comment 13">drkirkby</a>:
</p>
<blockquote class="citation">
<p>
The 'sage-location' script starts
</p>
<pre class="wiki">#!/usr/bin/env python
import os, sys
OLD_SAGE_ROOT = None
SAGE_ROOT = os.path.realpath(os.environ['SAGE_ROOT'])
location_file = os.path.join(SAGE_ROOT, 'local', 'lib', 'sage-curent-location.txt')
flags_file = os.path.join(SAGE_ROOT, 'local', 'lib', 'sage-flags.txt')
# The flags we care about recording in the local/lib/sage-flags.txt file
# In SAGE_FAT_BINARY mode we only require that ['sse', 'sse2', '3d',
# 'mmx', 'cmov'] be available, and in particular, don't require pni
# or ssse3.
try:
SAGE_FAT_BINARY = os.environ['SAGE_FAT_BINARY']
except:
SAGE_FAT_BINARY = ""
</pre><p>
Anything look wrong?
</p>
</blockquote>
<p>
Yep. Notice that the sage-location file is 'sage-curent-location' (misspelled "current"). That's the old patch. I've attached the full new file for convenience, or you can pull the patch attached to this ticket currently.
</p>
<p>
Jason
</p>
TicketdrkirkbySat, 12 Jun 2010 23:14:57 GMT
https://trac.sagemath.org/ticket/9210#comment:16
https://trac.sagemath.org/ticket/9210#comment:16
<p>
I'm just building another binary distribution.
</p>
<p>
I should be able to update this within the next hour or two.
</p>
TicketdrkirkbySun, 13 Jun 2010 00:22:49 GMTstatus changed
https://trac.sagemath.org/ticket/9210#comment:17
https://trac.sagemath.org/ticket/9210#comment:17
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
Hi Jason,
</p>
<p>
I made another binary distribution, and moved it again. (I mistakenly used the number 4.4.4 in the name, rather than 4.4.3, but it makes no difference. I could call it zebra if I wanted! But this is based on the 4.4.3 in Sage, not on the 4.4.4.alpha0 source code).
</p>
<p>
Sage reports it has been moved, and an attempt to factorise a Mersenne prime behaves as expected. So there is no segmentation fault as there was before.
</p>
<pre class="wiki">-bash-3.00$ cd sage-4.4.4-revised-sage-location-without-misspelling-sun4u-SunOS
-bash-3.00$ ./sage
----------------------------------------------------------------------
| Sage Version 4.4.3, Release Date: 2010-06-04 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
The Sage install tree may have moved
(from /export/home/drkirkby/32/sage-4.4.3 to /export/home/sageserv/sage-4.4.4-revised-sage-location-without-misspelling-sun4u-SunOS)
Changing various hardcoded paths
(please wait at most a few minutes)...
Do not interrupt this.
Done resetting paths
sage: factor(2^607 -1)
531137992816767098689588206552468627329593117727031923199444138200403559860852242739162502265229285668889329486246501015346579337652707239409519978766587351943831270835393219031728127
sage:
</pre><p>
But when I look at the .pc files, the prefix is not updated. This does not look right to me.
</p>
<pre class="wiki">-bash-3.00$ pwd
/export/home/sageserv/sage-4.4.4-revised-sage-location-without-misspelling-sun4u-SunOS/local/lib/pkgconfig
-bash-3.00$ cat freetype2.pc
prefix=/export/home/drkirkby/32/sage-4.4.3/local
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
Name: FreeType 2
Description: A free, high-quality, and portable font engine.
Version: 9.16.3
Requires:
Libs: -L${libdir} -lfreetype -lz
Cflags: -I${includedir}/freetype2 -I${includedir}SAGE_ROOT=/export/home/sageserv/sage-4.4.4-revised-sage-location-without-misspelling-sun4u-SunOS
-bash-3.00$
</pre><p>
The file sage-location is the one attached to this ticket
</p>
<pre class="wiki">-bash-3.00$ digest -a md5 ./local/bin/sage-location
d73f790e23a60751f6b1b58941515744
</pre>
TicketjasonSun, 13 Jun 2010 04:50:32 GMT
https://trac.sagemath.org/ticket/9210#comment:18
https://trac.sagemath.org/ticket/9210#comment:18
<p>
You're right, that .pc file does not look right. I'll try to take a look at this early next week.
</p>
TicketjasonTue, 15 Jun 2010 02:41:55 GMT
https://trac.sagemath.org/ticket/9210#comment:19
https://trac.sagemath.org/ticket/9210#comment:19
<p>
I think we need to be more careful about how we review this patch. I know what files to delete to re-initialize things, but just to make sure, here are the new review instructions. I'm following these myself, and I'll post them in a bit.
</p>
TicketjasonTue, 15 Jun 2010 04:22:50 GMTstatus changed
https://trac.sagemath.org/ticket/9210#comment:20
https://trac.sagemath.org/ticket/9210#comment:20
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
</ul>
<p>
Okay, here are I think better instructions for reviewing this patch:
</p>
<ol><li>Download and extract the Sage 4.4.3 source tarball
</li></ol><ol start="2"><li>Download <a class="ext-link" href="http://sage.math.washington.edu/home/jason/sage_scripts-4.4.3.spkg"><span class="icon"></span>http://sage.math.washington.edu/home/jason/sage_scripts-4.4.3.spkg</a> and put it in the spkg/standard directory, replacing the existing file of the same name. This is just an spkg with the patch on this ticket applied, so that the .pc files are initialized correctly
</li></ol><ol start="3"><li>Build the source (i.e., type "make")
</li></ol><ol start="4"><li>Run Sage (this is very important, as hardcoded paths will depend on the build directory, and this step will initialize things to know what the build directory is)
</li></ol><ol start="5"><li>Then either move the sage directory, or create a bdist. Now running Sage after moving directories or extracting and running sage from the bdist should correctly update the .pc files. The freetype2.pc file, for example, should be something like:
</li></ol><pre class="wiki">SAGE_ROOT=/home/grout/sage-4.4.3-pkgconfig
prefix=${SAGE_ROOT}/local
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
Name: FreeType 2
Description: A free, high-quality, and portable font engine.
Version: 9.16.3
Requires:
Libs: -L${libdir} -lfreetype -lz
Cflags: -I${includedir}/freetype2 -I${includedir}
</pre><p>
where the SAGE_ROOT variable should update to the current sage root directory.
</p>
TicketjasonTue, 15 Jun 2010 04:42:32 GMT
https://trac.sagemath.org/ticket/9210#comment:21
https://trac.sagemath.org/ticket/9210#comment:21
<p>
FYI, in April, some discussion happened on the pkg-config mailing list about making some automatic variables to support relocation:
</p>
<p>
<a class="ext-link" href="http://lists.freedesktop.org/archives/pkg-config/2010-April/000520.html"><span class="icon"></span>http://lists.freedesktop.org/archives/pkg-config/2010-April/000520.html</a>
</p>
TicketjasonTue, 15 Jun 2010 04:43:10 GMT
https://trac.sagemath.org/ticket/9210#comment:22
https://trac.sagemath.org/ticket/9210#comment:22
<p>
(nothing came out of that discussion yet, but it might be nice to keep an eye on it in the future...)
</p>
TicketdrkirkbyFri, 25 Jun 2010 05:07:04 GMT
https://trac.sagemath.org/ticket/9210#comment:23
https://trac.sagemath.org/ticket/9210#comment:23
<p>
Since 4.4.4 has now been released, should I be able to apply trac-9210-rewrite-sage-location.patch and get this to work? I've built 4.4.4 but have not moved it yet.
</p>
<p>
Dave
</p>
TicketmpatelFri, 20 Aug 2010 06:26:25 GMTcc changed
https://trac.sagemath.org/ticket/9210#comment:24
https://trac.sagemath.org/ticket/9210#comment:24
<ul>
<li><strong>cc</strong>
<em>kcrisman</em> added
</li>
</ul>
<p>
Not updating the .pc files in <code>SAGE_LOCAL/lib/pkgconfig</code> may also cause problems during an upgrade after moving Sage. Please see <a class="ext-link" href="http://groups.google.com/group/sage-release/browse_thread/thread/67feb1b840ff2710/5499fab47d031a21#5499fab47d031a21"><span class="icon"></span>sage-release</a> for Karl-Dieter's report about a 4.5.2.rc1-4.5.3.alpha1 upgrade on PPC OS X 10.4
</p>
<p>
Also, for some packages that compile Python extension modules during the upgrade, it seems to help to update old paths in <code>SAGE_LOCAL/lib/python/config/Makefile</code>.
</p>
<p>
I checked the .pc file and <code>Makefile</code> changes on sage.math with the equivalent of
</p>
<div class="wiki-code"><div class="code"><pre><span class="nv">$ </span>tar xf /home/release/sage-4.5.2/sage-4.5.2.tar
<span class="nv">$ </span>mv sage-4.5.2 sage-FOOO
<span class="nv">$ </span><span class="nb">cd </span>sage-FOOO
<span class="nv">$ </span>make build
<span class="nv">$ </span><span class="nb">cd</span> ..
<span class="nv">$ </span>cp -a sage-FOOO/ sage-yyyy
<span class="nv">$ </span><span class="nb">cd </span>sage-yyyy
<span class="nv">$ </span>sed -i <span class="s1">'s/FOOO/yyyy/g'</span> <span class="nb">local</span>/lib/pkgconfig/*
<span class="nv">$ </span>sed -i <span class="s1">'s/FOOO/yyyy/g'</span> <span class="nb">local</span>/lib/python/config/Makefile
<span class="nv">$ </span><span class="nb">echo</span> <span class="s2">"y"</span> | ./sage -upgrade http://sage.math.washington.edu/home/release/sage-4.5.3.alpha1/sage-4.5.3.alpha1.tar | tee -a upgrade.log
<span class="nv">$ </span>grep FOOO upgrade.log
<span class="err">$</span>
</pre></div></div><p>
If I don't update the .pc files and/or the <code>Makefile</code>, I get many matches for <code>FOOO</code>.
</p>
TicketjasonThu, 09 Sep 2010 20:07:10 GMT
https://trac.sagemath.org/ticket/9210#comment:25
https://trac.sagemath.org/ticket/9210#comment:25
<p>
To review, this should be sufficient:
</p>
<ol><li>Download and build Sage (important; it must be a fresh build from source).
</li></ol><ol start="2"><li>Apply the patch at the ticket to the scripts repository (in SAGE_ROOT/local/bin):
</li></ol><p>
<a class="ext-link" href="http://trac.sagemath.org/sage_trac/raw-attachment/ticket/9210/trac-9210-rewrite-sage-location.patch"><span class="icon"></span>http://trac.sagemath.org/sage_trac/raw-attachment/ticket/9210/trac-9210-rewrite-sage-location.patch</a>
</p>
<ol start="3"><li>Delete the file SAGE_ROOT/local/lib/sage-current-location.txt, if it exists
</li></ol><ol start="4"><li>Now run Sage, then exit (this updates the sage-current-location and pkgconfig files appropriately).
</li></ol><ol start="5"><li>Move the sage directory and run Sage again. The SAGE_ROOT/local/lib/sage-current-location.txt should be updated, and the pkgconfig files in SAGE_ROOT/local/lib/pkgconfig/ should also be updated to the new path (you can check the freetype2.pc file, for example, to see the new sage directory is listed there in the SAGE_ROOT variable).
</li></ol>
TicketdrkirkbyThu, 09 Sep 2010 22:38:44 GMTstatus changed
https://trac.sagemath.org/ticket/9210#comment:26
https://trac.sagemath.org/ticket/9210#comment:26
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
This is simply not working for me. The system is a Sun Ultra 27 running OpenSolaris on an Intel Xeon processor. This is what I did.
</p>
<p>
1) Build Sage fresh in the directory
</p>
<p>
<code>/export/home/drkirkby/9/sage-4.5.3.alpha2</code>
</p>
<p>
Sage had not been run. There was no file SAGE_ROOT/local/lib/sage-current-location.txt
</p>
<p>
2) Created a tar file with all this in:
</p>
<pre class="wiki">$ tar cvf test.tar sage-4.5.3.alpha2
</pre><p>
3) Changed to the directory /tmp.
</p>
<pre class="wiki">$ cd /tmp
</pre><p>
4) Extracted the tar file in /tmp
</p>
<pre class="wiki">$ tar xf $HOME/9/test.tar
</pre><p>
5) Run Sage from /tmp.
</p>
<p>
That created
</p>
<pre class="wiki">$SAGE_LOCAL/lib/sage-current-location.txt
</pre><p>
which had <code>/tmp/sage-4.5.3.alpha2</code>
</p>
<p>
as the contents - I note there is no end of line.
</p>
<p>
6) Changed to the directory where all the .pc files are
</p>
<pre class="wiki">$ cd /tmp/sage-4.5.3.alpha2/local/lib/pkgconfig
</pre><p>
7) Now run grep, and look for my user name "drkirkby" which was in the path before, but now I'm in /tmp, it should not be there.
</p>
<pre class="wiki">drkirkby@hawk:/tmp/sage-4.5.3.alpha2/local/lib/pkgconfig$ grep drkirkby *
bdw-gc.pc:prefix=/export/home/drkirkby/9/sage-4.5.3.alpha2/local
freetype2.pc:prefix=/export/home/drkirkby/9/sage-4.5.3.alpha2/local
gnutls-extra.pc:prefix=/export/home/drkirkby/9/sage-4.5.3.alpha2/local
gnutls-extra.pc:Libs.private: -L${exec_prefix}/lib -lgnutls-extra -L/export/home/drkirkby/9/sage-4.5.3.alpha2/local/lib -lopencdk -L/export/home/drkirkby/9/sage-4.5.3.alpha2/local/lib -lgcrypt -lsocket -L/export/home/drkirkby/9/sage-4.5.3.alpha2/local/lib -lgpg-error -L/export/home/drkirkby/9/sage-4.5.3.alpha2/local/lib -lz -R/export/home/drkirkby/9/sage-4.5.3.alpha2/local/lib -L${exec_prefix}/lib -lgnutls -L/export/home/drkirkby/9/sage-4.5.3.alpha2/local/lib -lgcrypt -lgpg-error -lnsl -lsocket
gnutls.pc:prefix=/export/home/drkirkby/9/sage-4.5.3.alpha2/local
gnutls.pc:Libs.private: -L${exec_prefix}/lib -lgnutls -L/export/home/drkirkby/9/sage-4.5.3.alpha2/local/lib -lgcrypt -lgpg-error -lnsl -lsocket
gsl.pc:prefix=/export/home/drkirkby/9/sage-4.5.3.alpha2/local
gsl.pc:exec_prefix=/export/home/drkirkby/9/sage-4.5.3.alpha2/local
gsl.pc:libdir=/export/home/drkirkby/9/sage-4.5.3.alpha2/local/lib
gsl.pc:includedir=/export/home/drkirkby/9/sage-4.5.3.alpha2/local/include
gsl.pc:Libs: -L/export/home/drkirkby/9/sage-4.5.3.alpha2/local/lib -lgsl -lgslcblas -lm
gsl.pc:Cflags: -I/export/home/drkirkby/9/sage-4.5.3.alpha2/local/includeSAGE_ROOT=/tmp/sage-4.5.3.alpha2
libpng.pc:prefix=/export/home/drkirkby/9/sage-4.5.3.alpha2/local
libpng12.pc:prefix=/export/home/drkirkby/9/sage-4.5.3.alpha2/local
libR.pc:rhome=/export/home/drkirkby/9/sage-4.5.3.alpha2/local/lib/R
libR.pc:rincludedir=/export/home/drkirkby/9/sage-4.5.3.alpha2/local/lib/R/include
opencdk.pc:prefix=/export/home/drkirkby/9/sage-4.5.3.alpha2/local
opencdk.pc:Libs.private: -L${exec_prefix}/lib -lopencdk -L/export/home/drkirkby/9/sage-4.5.3.alpha2/local/lib -lgcrypt -lgpg-error -lz
pynac.pc:prefix=/export/home/drkirkby/9/sage-4.5.3.alpha2/local
sqlite3.pc:prefix=/export/home/drkirkby/9/sage-4.5.3.alpha2/local
zlib.pc:prefix=/export/home/drkirkby/9/sage-4.5.3.alpha2/local
zlib.pc:includedir=/export/home/drkirkby/9/sage-4.5.3.alpha2/local/include
</pre><p>
As you can see, there are tons of references to the old location.
</p>
<p>
Now lets see how many of those files have "tmp" in them.
</p>
<pre class="wiki">drkirkby@hawk:/tmp/sage-4.5.3.alpha2/local/lib/pkgconfig$ grep drkirkby * | grep tmp
gsl.pc:Cflags: -I/export/home/drkirkby/9/sage-4.5.3.alpha2/local/includeSAGE_ROOT=/tmp/sage-4.5.3.alpha2
drkirkby@hawk:/tmp/sage-4.5.3.alpha2/local/lib/pkgconfig$
</pre><p>
So for me at least, those .pc files are not being updated.
</p>
<p>
Would it be easier to do this with a <em>simple</em> <code>sed</code> script? I don't know precisely how to do this, but I could ask on <a class="ext-link" href="http://groups.google.com/group/comp.unix.shell/topics?hl=en"><span class="icon"></span>comp.unix.shell</a> I reckon this could be done in a very short unix shell script - it does not need loads of Python IMHO.
</p>
<p>
Dave
</p>
TicketdrkirkbyThu, 09 Sep 2010 22:39:48 GMT
https://trac.sagemath.org/ticket/9210#comment:27
https://trac.sagemath.org/ticket/9210#comment:27
<p>
I forgot to add - I did apply the patch!!
</p>
TicketkcrismanThu, 09 Sep 2010 22:44:06 GMT
https://trac.sagemath.org/ticket/9210#comment:28
https://trac.sagemath.org/ticket/9210#comment:28
<p>
Data point - this does seem to work for me.
</p>
<pre class="wiki">Crismans-Computer:~ crisman$ cd Desktop/sage-4.6/local/lib/pkgconfig/
Crismans-Computer:~/Desktop/sage-4.6/local/lib/pkgconfig crisman$ grep 4.5.3 *
</pre><p>
Though it wasn't a *totally* fresh build... I did delete everything, though. Why does this have to be totally fresh? On this computer (one of the original report computers) it takes a long time to build, that's why I ask.
</p>
TicketjasonThu, 09 Sep 2010 22:47:08 GMT
https://trac.sagemath.org/ticket/9210#comment:29
https://trac.sagemath.org/ticket/9210#comment:29
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9210#comment:28" title="Comment 28">kcrisman</a>:
</p>
<blockquote class="citation">
<p>
Data point - this does seem to work for me.
</p>
<pre class="wiki">Crismans-Computer:~ crisman$ cd Desktop/sage-4.6/local/lib/pkgconfig/
Crismans-Computer:~/Desktop/sage-4.6/local/lib/pkgconfig crisman$ grep 4.5.3 *
</pre><p>
Though it wasn't a *totally* fresh build... I did delete everything, though. Why does this have to be totally fresh? On this computer (one of the original report computers) it takes a long time to build, that's why I ask.
</p>
</blockquote>
<p>
The totally fresh part is to make sure that the initialization the first time Sage is started up is done correctly. In reality, as long as the current directory is the same as the build directory, and the sage-current-location.txt is deleted, it will probably also work.
</p>
TicketjasonThu, 09 Sep 2010 22:51:56 GMTstatus changed
https://trac.sagemath.org/ticket/9210#comment:30
https://trac.sagemath.org/ticket/9210#comment:30
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
</ul>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9210#comment:26" title="Comment 26">drkirkby</a>:
</p>
<blockquote class="citation">
<p>
This is simply not working for me. The system is a Sun Ultra 27 running OpenSolaris on an Intel Xeon processor. This is what I did.
</p>
</blockquote>
<p>
You didn't quite follow the instructions.
</p>
<blockquote class="citation">
<p>
1) Build Sage fresh in the directory
</p>
<p>
<code>/export/home/drkirkby/9/sage-4.5.3.alpha2</code>
</p>
<p>
Sage had not been run. There was no file SAGE_ROOT/local/lib/sage-current-location.txt
</p>
</blockquote>
<p>
Here you need to apply the patch and run Sage (step 4). Sage must be run, with the patch applied, from the original build directory, to properly initialize the pkconfig files and the sage-current-location.txt file.
</p>
<p>
After applying the patch, making sure there is no sage-current-location.txt file, then running Sage once, only *then* should you move the directory.
</p>
<blockquote class="citation">
<p>
Would it be easier to do this with a <em>simple</em> <code>sed</code> script? I don't know precisely how to do this, but I could ask on <a class="ext-link" href="http://groups.google.com/group/comp.unix.shell/topics?hl=en"><span class="icon"></span>comp.unix.shell</a> I reckon this could be done in a very short unix shell script - it does not need loads of Python IMHO.
</p>
</blockquote>
<p>
More than just the pkgconfig files are being updated, so it's not just that simple. However, a sufficiently talented (or un-busy) shell programmer could do the job, probably.
</p>
TicketdrkirkbyFri, 10 Sep 2010 09:07:05 GMT
https://trac.sagemath.org/ticket/9210#comment:31
https://trac.sagemath.org/ticket/9210#comment:31
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9210#comment:30" title="Comment 30">jason</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9210#comment:26" title="Comment 26">drkirkby</a>:
</p>
<blockquote class="citation">
<p>
This is simply not working for me. The system is a Sun Ultra 27 running OpenSolaris on an Intel Xeon processor. This is what I did.
</p>
</blockquote>
<p>
You didn't quite follow the instructions.
</p>
</blockquote>
<p>
I think it was a case of not exactly explaining what I did. I believe I did run Sage in the original location. When I extracted the tar file for a second time, it showed the file
</p>
<p>
<code>$SAGE_LOCAL/lib/sage-current-location.txt</code>
</p>
<p>
But prior to running Sage that file did not exist. Then when I moved Sage, the contents of
</p>
<p>
$SAGE_LOCAL/lib/sage-current-location.txt
</p>
<p>
changed, but the contents of the .pc files did not substantially change.
</p>
<p>
I will revisit this - but I'm still not convinced it is working myself. It might be a platform specific problem.
</p>
<p>
Dave
</p>
TicketjasonFri, 15 Oct 2010 00:33:20 GMT
https://trac.sagemath.org/ticket/9210#comment:32
https://trac.sagemath.org/ticket/9210#comment:32
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9210#comment:31" title="Comment 31">drkirkby</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9210#comment:30" title="Comment 30">jason</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9210#comment:26" title="Comment 26">drkirkby</a>:
</p>
<blockquote class="citation">
<p>
This is simply not working for me. The system is a Sun Ultra 27 running OpenSolaris on an Intel Xeon processor. This is what I did.
</p>
</blockquote>
<p>
You didn't quite follow the instructions.
</p>
</blockquote>
<p>
I think it was a case of not exactly explaining what I did. I believe I did run Sage in the original location. When I extracted the tar file for a second time, it showed the file
</p>
<p>
<code>$SAGE_LOCAL/lib/sage-current-location.txt</code>
</p>
<p>
But prior to running Sage that file did not exist. Then when I moved Sage, the contents of
</p>
<p>
$SAGE_LOCAL/lib/sage-current-location.txt
</p>
<p>
changed, but the contents of the .pc files did not substantially change.
</p>
<p>
I will revisit this - but I'm still not convinced it is working myself. It might be a platform specific problem.
</p>
</blockquote>
<p>
The fact that in your before tarball, the pkgconfig files did not start with SAGE_ROOT leads me to believe that the sage-current-location.txt file was created *before* the patch was applied, and was never deleted and sage run before moving the directory. With the new patch applied, when that file is created, the pkgconfig files should be modified to include a SAGE_ROOT line at the very top.
</p>
<p>
I tried to use the python OS-agnostic functions everywhere, so on the surface, I doubt it's an OS-specific problem.
</p>
<p>
So, if you have time, please try again, and make sure that after the patch is applied, the sage-current-location.txt file is deleted which for convenience, are repeated below:
</p>
<p>
To review, this should be sufficient:
</p>
<blockquote>
<p>
#. Download and build Sage (important; it must be a fresh build from source).
</p>
</blockquote>
<blockquote>
<p>
#. Apply the patch at the ticket to the scripts repository (in SAGE_ROOT/local/bin):
</p>
</blockquote>
<blockquote>
<p>
<a class="ext-link" href="http://trac.sagemath.org/sage_trac/raw-attachment/ticket/9210/trac-9210-rewrite-sage-location.patch"><span class="icon"></span>http://trac.sagemath.org/sage_trac/raw-attachment/ticket/9210/trac-9210-rewrite-sage-location.patch</a>
</p>
</blockquote>
<blockquote>
<blockquote>
<p>
#. Delete the file SAGE_ROOT/local/lib/sage-current-location.txt, if it exists
</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>
#. Now run Sage, then exit (this updates the sage-current-location and pkgconfig files appropriately). Check to make sure that sage-current-location.txt is now created, and that each pkgconfig file starts with a line "SAGE_ROOT=" (followed by the build directory)
</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>
#. Move the sage directory and run Sage again. The SAGE_ROOT/local/lib/sage-current-location.txt should be updated, and the pkgconfig files in SAGE_ROOT/local/lib/pkgconfig/ should also be updated to the new path (you can check the freetype2.pc file, for example, to see the new sage directory is listed there in the SAGE_ROOT variable).
</p>
</blockquote>
</blockquote>
<p>
Thanks!
</p>
TicketjasonFri, 15 Oct 2010 00:35:47 GMT
https://trac.sagemath.org/ticket/9210#comment:33
https://trac.sagemath.org/ticket/9210#comment:33
<p>
Apparently I don't remember the right wiki syntax. Here are the 5 steps again:
</p>
<ol><li>Download and build Sage (important; it must be a fresh build from source).
</li><li>Apply the patch at the ticket to the scripts repository (in SAGE_ROOT/local/bin):<a class="ext-link" href="http://trac.sagemath.org/raw-attachment/ticket/9210/trac-9210-rewrite-sage-location.patch"><span class="icon"></span>http://trac.sagemath.org/sage_trac/raw-attachment/ticket/9210/trac-9210-rewrite-sage-location.patch</a>
</li><li>Delete the file SAGE_ROOT/local/lib/sage-current-location.txt, if it exists
</li><li>Now run Sage, then exit (this updates the sage-current-location and pkgconfig files appropriately). Check to make sure that sage-current-location.txt is now created, and that each pkgconfig file starts with a line "SAGE_ROOT=" (followed by the build directory)
</li><li>Move the sage directory and run Sage again. The SAGE_ROOT/local/lib/sage-current-location.txt should be updated, and the pkgconfig files in SAGE_ROOT/local/lib/pkgconfig/ should also be updated to the new path (you can check the freetype2.pc file, for example, to see the new sage directory is listed there in the SAGE_ROOT variable).
</li></ol>
TicketkcrismanFri, 15 Oct 2010 02:02:09 GMT
https://trac.sagemath.org/ticket/9210#comment:34
https://trac.sagemath.org/ticket/9210#comment:34
<blockquote class="citation">
<ol><li>Apply the patch at the ticket to the scripts repository (in SAGE_ROOT/local/bin):<a class="ext-link" href="http://trac.sagemath.org/raw-attachment/ticket/9210/trac-9210-rewrite-sage-location.patch"><span class="icon"></span>http://trac.sagemath.org/sage_trac/raw-attachment/ticket/9210/trac-9210-rewrite-sage-location.patch</a>
</li></ol></blockquote>
<p>
The link is wrong but the text is right; <a class="ext-link" href="http://trac.sagemath.org/sage_trac/raw-attachment/ticket/9210/trac-9210-rewrite-sage-location.patch"><span class="icon"></span>http://trac.sagemath.org/sage_trac/raw-attachment/ticket/9210/trac-9210-rewrite-sage-location.patch</a>
</p>
TicketkcrismanFri, 15 Oct 2010 02:12:57 GMTreviewer set
https://trac.sagemath.org/ticket/9210#comment:35
https://trac.sagemath.org/ticket/9210#comment:35
<ul>
<li><strong>reviewer</strong>
set to <em>David Kirkby, Karl-Dieter Crisman</em>
</li>
</ul>
<p>
After doing this on a NON fresh build, just to fix something dumb, I get
</p>
<pre class="wiki">new-host-2:pkgconfig karl-dietercrisman$ grep 4.6 *
bdw-gc.pc:SAGE_ROOT=/Users/.../sage-4.6.alpha4
freetype2.pc:SAGE_ROOT=/Users/.../sage-4.6.alpha4
gnutls-extra.pc:SAGE_ROOT=/Users/.../sage-4.6.alpha4
gnutls.pc:SAGE_ROOT=/Users/.../sage-4.6.alpha4
gsl.pc:SAGE_ROOT=/Users/.../sage-4.6.alpha4
libR.pc:SAGE_ROOT=/Users/.../sage-4.6.alpha4
libR.pc:rhome=/Users/.../sage-4.6.alpha1/local/lib/R
libR.pc:rincludedir=/Users/.../sage-4.6.alpha1/local/lib/R/include
libpng.pc:SAGE_ROOT=/Users/.../sage-4.6.alpha4
libpng12.pc:SAGE_ROOT=/Users/.../sage-4.6.alpha4
opencdk.pc:SAGE_ROOT=/Users/.../sage-4.6.alpha4
pynac.pc:SAGE_ROOT=/Users/.../sage-4.6.alpha4
pynac.pc:prefix=/Users/.../sage-4.6.alpha2/local
sqlite3.pc:SAGE_ROOT=/Users/.../sage-4.6.alpha4
zlib.pc:SAGE_ROOT=/Users/.../sage-4.6.alpha4
new-host-2:pkgconfig karl-dietercrisman$ grep 4.5 *
bdw-gc.pc:prefix=/Users/.../sage-4.5.1/local
freetype2.pc:prefix=/Users/.../sage-4.5.1/local
gnutls-extra.pc:prefix=/Users/.../sage-4.5.1/local
gnutls-extra.pc:Libs.private: -L${exec_prefix}/lib -lgnutls-extra -L/Users/.../sage-4.5.1/local/lib -lopencdk -L/Users/.../sage-4.5.1/local/lib -lgcrypt -L/Users/.../sage-4.5.1/local/lib -lgpg-error -L/Users/.../sage-4.5.1/local/lib -lz -R/Users/.../sage-4.5.1/local/lib -L${exec_prefix}/lib -lgnutls -L/Users/.../sage-4.5.1/local/lib -lgcrypt -lgpg-error
gnutls.pc:prefix=/Users/.../sage-4.5.1/local
gnutls.pc:Libs.private: -L${exec_prefix}/lib -lgnutls -L/Users/.../sage-4.5.1/local/lib -lgcrypt -lgpg-error
gsl.pc:prefix=/Users/.../sage-4.5.2/local
gsl.pc:exec_prefix=/Users/.../sage-4.5.2/local
gsl.pc:libdir=/Users/.../sage-4.5.2/local/lib
gsl.pc:includedir=/Users/.../sage-4.5.2/local/include
gsl.pc:Libs: -L/Users/.../sage-4.5.2/local/lib -lgsl -lgslcblas -lm
gsl.pc:Cflags: -I/Users/.../sage-4.5.2/local/include
libpng.pc:prefix=/Users/.../sage-4.5.1/local
libpng12.pc:prefix=/Users/.../sage-4.5.1/local
opencdk.pc:prefix=/Users/.../sage-4.5.1/local
opencdk.pc:Libs.private: -L${exec_prefix}/lib -lopencdk -L/Users/.../sage-4.5.1/local/lib -lgcrypt -lgpg-error -lz
sqlite3.pc:prefix=/Users/.../sage-4.5.1/local
zlib.pc:prefix=/Users/.../sage-4.5.1/local
zlib.pc:includedir=/Users/.../sage-4.5.1/local/include
</pre><p>
So although it relists the <code>SAGE_ROOT</code> variable correctly, all those prefixes and includes and whatever else still are bad news. I don't know how to use <code>sed</code> like Mitesh suggested on sage-release, but I think I can change the freetype one by hand.
</p>
TicketjasonFri, 15 Oct 2010 02:20:04 GMT
https://trac.sagemath.org/ticket/9210#comment:36
https://trac.sagemath.org/ticket/9210#comment:36
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9210#comment:35" title="Comment 35">kcrisman</a>:
</p>
<blockquote class="citation">
<p>
After doing this on a NON fresh build, just to fix something dumb, I get
</p>
</blockquote>
<p>
The result is expected. The SAGE_ROOT directory is no longer the same as the build directory (as evidenced by the plethora of other build directories in the pkgconfig files). This patch only works correctly if things are initialized in the original build directory.
</p>
TicketkcrismanFri, 15 Oct 2010 02:36:42 GMT
https://trac.sagemath.org/ticket/9210#comment:37
https://trac.sagemath.org/ticket/9210#comment:37
<p>
I had a long followup, but your reply explained things. So why can't we also update those things? The new sage-location script <code>update_pkgconfig_files</code> doesn't seem to touch anything but that <code>SAGE_ROOT</code> guy, but it looks like there isn't any reason it couldn't, in theory, do those prefix statements too and just make them <code>${SAGE_ROOT}/local</code> or whatever is appropriate.
</p>
<p>
(I'm going to try that change 'by hand' on freetype, by the way.)
</p>
TicketjasonFri, 15 Oct 2010 03:58:14 GMT
https://trac.sagemath.org/ticket/9210#comment:38
https://trac.sagemath.org/ticket/9210#comment:38
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9210#comment:37" title="Comment 37">kcrisman</a>:
</p>
<blockquote class="citation">
<p>
I had a long followup, but your reply explained things. So why can't we also update those things? The new sage-location script <code>update_pkgconfig_files</code> doesn't seem to touch anything but that <code>SAGE_ROOT</code> guy, but it looks like there isn't any reason it couldn't, in theory, do those prefix statements too and just make them <code>${SAGE_ROOT}/local</code> or whatever is appropriate.
</p>
<p>
(I'm going to try that change 'by hand' on freetype, by the way.)
</p>
</blockquote>
<p>
I suppose the general problem is that we only know what the previous <code>SAGE_ROOT</code> was (given in the sage-location.txt file). We don't know what any other path in those pkgconfig files are, including the SAGE_ROOT from the time before the last move.
</p>
<p>
I suppose we could be more invasive and always change the prefix path as well. But there are other paths too. What paths do you change? In your example, you had at least 3-4 paths from old build directories, and lots of them are in things other than prefix statements. Which ones are old <code>SAGE_ROOT</code>s, and which ones are still valid locations that shouldn't be changed? For the ones that are old <code>SAGE_ROOT</code>s, which are the <code>SAGE_ROOT</code> parts and which are the parts that shouldn't be changed?
</p>
<p>
The strategy now is to replace all SAGE_ROOT paths with the SAGE_ROOT variable on the first startup, and then only change that in subsequent runs if needed. That seems *much* safer.
</p>
<p>
Right now, the strategy breaks down for pkgconfig files created after the initial build.
</p>
<p>
Another ticket should be created to update pkgconfig files that don't have <code>SAGE_ROOT</code> already defined, which takes care of spkgs installed later.
</p>
TicketkcrismanFri, 15 Oct 2010 13:22:34 GMT
https://trac.sagemath.org/ticket/9210#comment:39
https://trac.sagemath.org/ticket/9210#comment:39
<blockquote class="citation">
<blockquote class="citation">
<p>
(I'm going to try that change 'by hand' on freetype, by the way.)
</p>
</blockquote>
</blockquote>
<p>
Which worked!
</p>
<p>
On another machine, doing that wasn't enough to get out of this issue... there was still a reference to the wrong thing in libR.dylib, which is a binary file, and which I have no idea how to change. But that's not this ticket. As far as I have time to test this, it did what it said, so positive review from me. I don't have time to do the complete build from scratch, but it definitely changed what it claimed to in the right way from a non-scratch situation - and it WAS changed.
</p>
<blockquote class="citation">
<p>
Another ticket should be created to update pkgconfig files that don't have <code>SAGE_ROOT</code> already defined, which takes care of spkgs installed later.
</p>
</blockquote>
<p>
This seems reasonable, and hopefully with time won't be much of an issue. Sorry I can't give final positive review.
</p>
TicketjasonFri, 15 Oct 2010 15:03:41 GMT
https://trac.sagemath.org/ticket/9210#comment:40
https://trac.sagemath.org/ticket/9210#comment:40
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9210#comment:39" title="Comment 39">kcrisman</a>:
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
Another ticket should be created to update pkgconfig files that don't have <code>SAGE_ROOT</code> already defined, which takes care of spkgs installed later.
</p>
</blockquote>
<p>
This seems reasonable, and hopefully with time won't be much of an issue. Sorry I can't give final positive review.
</p>
</blockquote>
<p>
So I think that means we need at least one more reviewer. Dave, do you have time to look at this again?
</p>
TicketdrkirkbySat, 16 Oct 2010 05:08:02 GMT
https://trac.sagemath.org/ticket/9210#comment:41
https://trac.sagemath.org/ticket/9210#comment:41
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9210#comment:40" title="Comment 40">jason</a>:
</p>
<blockquote class="citation">
<p>
So I think that means we need at least one more reviewer. Dave, do you have time to look at this again?
</p>
</blockquote>
<p>
I won't have much time to play with this until Wednesday, but I'm just doing a fresh build. This time I'm using the 'script' command so it will have an <strong>exact</strong> record of what I did - even my typos are recorded. If there's a problem I'll make that file available, if there's not, I'll give it a positive review.
</p>
<p>
BTW, someone above said they did not know how to use 'sed'. There are plenty of references on the web, but this file I always find useful, as it normally has something there which is sufficiently similar to what I want to achieve, that I can modify it to do what I want.
</p>
<p>
<a class="ext-link" href="http://sed.sourceforge.net/sed1line.txt"><span class="icon"></span>http://sed.sourceforge.net/sed1line.txt</a>
</p>
<p>
dave
</p>
TicketdrkirkbySat, 16 Oct 2010 05:59:14 GMT
https://trac.sagemath.org/ticket/9210#comment:42
https://trac.sagemath.org/ticket/9210#comment:42
<p>
OK, Sage is built. Let's try my luck for the Nth time!
</p>
TicketdrkirkbySat, 16 Oct 2010 06:11:22 GMT
https://trac.sagemath.org/ticket/9210#comment:43
https://trac.sagemath.org/ticket/9210#comment:43
<p>
I think that has worked. I am just going to run the doctests to make sure.
</p>
<p>
Dave
</p>
TicketdrkirkbySat, 16 Oct 2010 06:34:48 GMT
https://trac.sagemath.org/ticket/9210#comment:44
https://trac.sagemath.org/ticket/9210#comment:44
<p>
Em, this is odd. I used 'mv' to move the Sage directory from:
</p>
<pre class="wiki">/export/home/drkirkby/9210/sage-4.6.alpha3/local
</pre><p>
to:
</p>
<pre class="wiki">/tmp/9210/sage-4.6.alpha3/local
</pre><p>
I got some warnings about unable to save ACLs. Now when I run the doctests, several are failing. One at least is due to the fact 'Maxima' can't run. When I look at the script $SAGE_ROOT/local/bin/maxima, I see that still have the old location:
</p>
<pre class="wiki">drkirkby@hawk:/tmp/9210/sage-4.6.alpha3$ pwd
/tmp/9210/sage-4.6.alpha3
drkirkby@hawk:/tmp/9210/sage-4.6.alpha3$ grep drkirkby local/bin/maxima
prefix=`unixize "/export/home/drkirkby/9210/sage-4.6.alpha3/local"`
top_srcdir=`unixize "/export/home/drkirkby"`
</pre><p>
So perhaps the .pc files are not the only things that need changing. I realise that's outside of the scope of this ticket, and it may be due to the warnings about unable to save ALCs, so I build Sage again and use 'tar' to move it.
</p>
<p>
Dave
</p>
TicketjasonSat, 16 Oct 2010 15:26:09 GMT
https://trac.sagemath.org/ticket/9210#comment:45
https://trac.sagemath.org/ticket/9210#comment:45
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9210#comment:44" title="Comment 44">drkirkby</a>:
</p>
<blockquote class="citation">
<p>
So perhaps the .pc files are not the only things that need changing. I realise that's outside of the scope of this ticket, and it may be due to the warnings about unable to save ALCs, so I build Sage again and use 'tar' to move it.
</p>
</blockquote>
<p>
Most definitely there are other issues besides the pkgconfig files. I'm not confident in moving my installation at all anymore. This ticket just takes care of one aspect of the problem that prevented compiling things in a new location.
</p>
TicketdrkirkbySun, 17 Oct 2010 10:38:15 GMTstatus changed
https://trac.sagemath.org/ticket/9210#comment:46
https://trac.sagemath.org/ticket/9210#comment:46
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
</ul>
<p>
I've taken another look at this. It looks like I was mistaken when I thought the .pc file were not being updated properly, since they do now need to be.
</p>
<p>
Prior to moving the distribution, there were two doctest failures - <a class="closed ticket" href="https://trac.sagemath.org/ticket/10041" title="defect: Doctest failure in sage/tensor/differential_forms.py (closed: fixed)">#10041</a> and 10042.
</p>
<pre class="wiki">sage -t -long "devel/sage/sage/rings/polynomial/polynomial_element.pyx"
sage -t -long "devel/sage/sage/tensor/differential_forms.py"
</pre><p>
After moving the location, there are 5 doctest failures.
</p>
<pre class="wiki">The following tests failed:
sage -t -long -force_lib devel/sage/doc/en/tutorial/tour_advanced.rst # 2 doctests failed
sage -t -long -force_lib devel/sage/doc/fr/tutorial/tour_advanced.rst # 2 doctests failed
sage -t -long -force_lib devel/sage/sage/tensor/differential_forms.py # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/polynomial/polynomial_element.pyx # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/polynomial/groebner_fan.py # 76 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/polynomial/multi_polynomial_ideal.py # 1 doctests failed
----------------------------------------------------------------------
Total time for all tests: 1583.2 seconds
</pre><p>
So clearly this is not a complete fix for moving Sage, but it's a step in the right direction.
</p>
<p>
So I'm giving this positive review.
</p>
<p>
I'm sorry I have dragged this ticket out so long. I was of the belief it was not working correctly, so that is why I declined to give it positive review before, but now I'm convinced it is ok.
</p>
<p>
Like Jason, I'm not happy to move Sage. It makes me wonder how good the binaries are that we distribute. Does anyone doctest the binaries after they are created before they are made public?
</p>
<p>
Dave
</p>
TicketmpatelSun, 17 Oct 2010 11:45:31 GMT
https://trac.sagemath.org/ticket/9210#comment:47
https://trac.sagemath.org/ticket/9210#comment:47
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9210#comment:46" title="Comment 46">drkirkby</a>:
</p>
<blockquote class="citation">
<pre class="wiki">The following tests failed:
sage -t -long -force_lib devel/sage/doc/en/tutorial/tour_advanced.rst # 2 doctests failed
sage -t -long -force_lib devel/sage/doc/fr/tutorial/tour_advanced.rst # 2 doctests failed
sage -t -long -force_lib devel/sage/sage/tensor/differential_forms.py # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/polynomial/polynomial_element.pyx # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/polynomial/groebner_fan.py # 76 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/polynomial/multi_polynomial_ideal.py # 1 doctests failed
----------------------------------------------------------------------
Total time for all tests: 1583.2 seconds
</pre></blockquote>
<p>
If you still have it, could you attach or give a link to the test log?
</p>
TicketdrkirkbySun, 17 Oct 2010 12:40:49 GMT
https://trac.sagemath.org/ticket/9210#comment:48
https://trac.sagemath.org/ticket/9210#comment:48
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9210#comment:47" title="Comment 47">mpatel</a>:
</p>
<blockquote class="citation">
<p>
If you still have it, could you attach or give a link to the test log?
</p>
</blockquote>
<p>
Sure, it is here. The tests were run on 'hawk', my <a class="missing wiki">OpenSolaris?</a> machine.
</p>
<p>
<a class="ext-link" href="http://boxen.math.washington.edu/home/kirkby/logs/ptestlong-sage-4.6.alpha3-after-applying-9210-and-moving-to-another-location.log"><span class="icon"></span>http://boxen.math.washington.edu/home/kirkby/logs/ptestlong-sage-4.6.alpha3-after-applying-9210-and-moving-to-another-location.log</a>
</p>
TicketmpatelSun, 17 Oct 2010 22:40:33 GMT
https://trac.sagemath.org/ticket/9210#comment:49
https://trac.sagemath.org/ticket/9210#comment:49
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9210#comment:48" title="Comment 48">drkirkby</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9210#comment:47" title="Comment 47">mpatel</a>:
</p>
<blockquote class="citation">
<p>
If you still have it, could you attach or give a link to the test log?
</p>
</blockquote>
</blockquote>
<blockquote class="citation">
<p>
Sure, it is here. The tests were run on 'hawk', my <a class="missing wiki">OpenSolaris?</a> machine.
</p>
</blockquote>
<p>
</p>
<blockquote class="citation">
<p>
<a class="ext-link" href="http://boxen.math.washington.edu/home/kirkby/logs/ptestlong-sage-4.6.alpha3-after-applying-9210-and-moving-to-another-location.log"><span class="icon"></span>http://boxen.math.washington.edu/home/kirkby/logs/ptestlong-sage-4.6.alpha3-after-applying-9210-and-moving-to-another-location.log</a>
</p>
</blockquote>
<p>
Thanks. At least, the new errors all have one "cause":
</p>
<div class="wiki-code"><div class="code"><pre><span class="ne">RuntimeError</span><span class="p">:</span> ld<span class="o">.</span>so<span class="o">.</span><span class="mi">1</span><span class="p">:</span> gfan<span class="p">:</span> fatal<span class="p">:</span> relocation error<span class="p">:</span> <span class="nb">file</span> <span class="o">/</span>export<span class="o">/</span>home<span class="o">/</span>test<span class="o">/</span>sage<span class="o">-</span><span class="mf">4.6</span><span class="o">.</span>alpha3<span class="o">/</span>local<span class="o">/</span><span class="nb">bin</span><span class="o">/</span>gfan<span class="p">:</span> symbol _ZNSt15_List_node_base7_M_hookEPS_<span class="p">:</span> referenced symbol <span class="ow">not</span> found
</pre></div></div><p>
Of course, we can make this a separate ticket, but why would this <code>fatal: relocation error</code> happen?
</p>
TicketleifWed, 20 Oct 2010 12:41:48 GMT
https://trac.sagemath.org/ticket/9210#comment:50
https://trac.sagemath.org/ticket/9210#comment:50
<p>
I wonder if this should be a blocker...
</p>
TicketjasonWed, 20 Oct 2010 13:19:27 GMT
https://trac.sagemath.org/ticket/9210#comment:51
https://trac.sagemath.org/ticket/9210#comment:51
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9210#comment:50" title="Comment 50">leif</a>:
</p>
<blockquote class="citation">
<p>
I wonder if this should be a blocker...
</p>
</blockquote>
<p>
No. At most critical. Sage certainly has been released for a long time without this fix.
</p>
TicketdrkirkbyWed, 20 Oct 2010 13:28:05 GMT
https://trac.sagemath.org/ticket/9210#comment:52
https://trac.sagemath.org/ticket/9210#comment:52
<p>
I found the reason gfan has unresolved variables when moved - it is to do with gcc and the linker run time search path.
</p>
<p>
In a Sage shell, before the move:
</p>
<pre class="wiki">(sage subshell) hawk:sage-4.6.alpha3 drkirkby$ ldd local/bin/gfan
libgmp.so.3 => /export/home/drkirkby/sage-4.6.alpha3/local/lib//libgmp.so.3
libstdc++.so.6 => /usr/local/gcc-4.5.0/lib/libstdc++.so.6
libm.so.2 => /lib/libm.so.2
libgcc_s.so.1 => /usr/local/gcc-4.5.0/lib/libgcc_s.so.1
libc.so.1 => /lib/libc.so.1
SAGE_ROOT=/export/home/drkirkby/sage-4.6.alpha3
</pre><p>
After creating another account, and moving Sage, I must have not set LD_LIBRARY_PATH identically, so ldd shows:
</p>
<pre class="wiki">(sage subshell) hawk:bin test$ ldd gfan
libgmp.so.3 => /export/home/test/sage-4.6.alpha3/local/lib//libgmp.so.3
libstdc++.so.6 => /usr/lib/libstdc++.so.6
libm.so.2 => /lib/libm.so.2
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1
libc.so.1 => /lib/libc.so.1
SAGE_ROOT=/export/home/test/sage-4.6.alpha3
</pre><p>
i.e. instead of gfan finding the C++ libary it was linked against (e..g. /usr/local/gcc-4.5.0/lib/libstdc++.so.6) if finds an older library in <code>/usr/lib/libstdc++.so.6</code>. That is from gcc 3.4.3 - i.e. very old.
</p>
<p>
This is something we have to be very weary of on Solaris. We should make available recent run-time libraries, otherwise the user will probably have trouble. I know there have been reports of this on sage-support, and other sage-developers have hit it on t2.math. If we compile Sage with a recent gcc, and the person using a binary only had old gcc libraries, and/or new libraries are not in their linker search path, Sage will not run well.
</p>
<p>
There was one other thing I found odd. <strong>Before</strong> moving the code, though after Sage had been run, I tried this in a Sage shell.
</p>
<pre class="wiki">(sage subshell) hawk:sage-4.6.alpha3 drkirkby$ local/bin/gfan
1+2
PARSER ERROR: Expected: "field" Found: "1"
Assertion failed: 0, file parser.cpp, line 509
Abort (core dumped)
SAGE_ROOT=/export/home/drkirkby/sage-4.6.alpha3
</pre><p>
I've got no idea how gfan is supposed to be used, but trying 1+2 is enough to make it dump core, which is a bug in my opinion.
</p>
<p>
I tried it on sage.math too. Whilst it does not dump core, it is not very elegant:
</p>
<pre class="wiki">(sage subshell) sage:bin kirkby$ gfan
1+2
PARSER ERROR: Expected: "field" Found: "1"
gfan: parser.cpp:509: Field CharacterBasedParser::parseField(): Assertion `0' failed.
Aborted
SAGE_ROOT=/usr/local/sage
</pre><p>
And on bsd.math (OS X)
</p>
<pre class="wiki">(sage subshell) bsd:bin kirkby$ gfan
1+1
PARSER ERROR: Expected: "field" Found: "1"
Assertion failed: (0), function parseField, file parser.cpp, line 509.
Abort trap
SAGE_ROOT=/Users/kirkby/sage-4.6.alpha0
</pre><p>
So as soon as the parser sees something it does not reconise, it either aborts or dumps core. Not very elegant.
</p>
<p>
Dave
</p>
TicketjasonWed, 20 Oct 2010 13:32:24 GMT
https://trac.sagemath.org/ticket/9210#comment:53
https://trac.sagemath.org/ticket/9210#comment:53
<p>
Dave,
</p>
<p>
Just to clarify, are you saying something more needs to be done on this ticket, or are you commenting on another issue (with valuable information that should go on another ticket to fix the gfan issue)?
</p>
TicketdrkirkbyWed, 20 Oct 2010 13:37:19 GMT
https://trac.sagemath.org/ticket/9210#comment:54
https://trac.sagemath.org/ticket/9210#comment:54
<p>
No, I'm happy with this ticket.
</p>
<p>
The gfan core dump should go on another ticket.
</p>
<p>
I'm not sure how best to handle the situation with libraries that are older than the version Sage was built with.
</p>
<p>
Neither issue is related to the ticket as such.
</p>
<p>
Dave
</p>
TicketmpatelThu, 21 Oct 2010 08:44:52 GMTpriority changed
https://trac.sagemath.org/ticket/9210#comment:55
https://trac.sagemath.org/ticket/9210#comment:55
<ul>
<li><strong>priority</strong>
changed from <em>major</em> to <em>blocker</em>
</li>
</ul>
TicketmpatelThu, 21 Oct 2010 10:07:28 GMTstatus changed; resolution, merged set
https://trac.sagemath.org/ticket/9210#comment:56
https://trac.sagemath.org/ticket/9210#comment:56
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>closed</em>
</li>
<li><strong>resolution</strong>
set to <em>fixed</em>
</li>
<li><strong>merged</strong>
set to <em>sage-4.6.rc0</em>
</li>
</ul>
TicketleifThu, 21 Oct 2010 14:10:01 GMT
https://trac.sagemath.org/ticket/9210#comment:57
https://trac.sagemath.org/ticket/9210#comment:57
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9210#comment:24" title="Comment 24">mpatel</a>:
</p>
<blockquote class="citation">
<p>
Not updating the .pc files in <code>SAGE_LOCAL/lib/pkgconfig</code> may also cause problems during an upgrade after moving Sage. Please see <a class="ext-link" href="http://groups.google.com/group/sage-release/browse_thread/thread/67feb1b840ff2710/5499fab47d031a21#5499fab47d031a21"><span class="icon"></span>sage-release</a> for Karl-Dieter's report about a 4.5.2.rc1-4.5.3.alpha1 upgrade on PPC OS X 10.4
</p>
<p>
Also, for some packages that compile Python extension modules during the upgrade, it seems to help to update old paths in <code>SAGE_LOCAL/lib/python/config/Makefile</code>. [...]
</p>
</blockquote>
<p>
Cf. <a class="closed ticket" href="https://trac.sagemath.org/ticket/9896" title="defect: Upgrading from 4.5.3 to 4.6.alpha* can fail (not limited to MacOS X) (closed: fixed)">#9896</a>. Python's Makefile and <code>pyconfig.h</code> define lots of variables that contain hard-coded paths. These all go into <code>distutils.sysconfig.get_config_vars()</code> (a dictionary), but only some are used, and not all obsolete paths are actually harmful.
</p>
<p>
My patch to <code>devel/sage/setup.py</code> at <a class="closed ticket" href="https://trac.sagemath.org/ticket/9896" title="defect: Upgrading from 4.5.3 to 4.6.alpha* can fail (not limited to MacOS X) (closed: fixed)">#9896</a> e.g. just fixes invalid / obsolete library search directories coded into distutils' dynamic linker <strong>command</strong>(!) (on Darwin).
</p>
<p>
An alternative is to patch distutils itself.
</p>
TicketleifThu, 21 Oct 2010 14:18:09 GMTsummary changed
https://trac.sagemath.org/ticket/9210#comment:58
https://trac.sagemath.org/ticket/9210#comment:58
<ul>
<li><strong>summary</strong>
changed from <em>pkg-config prefix statements in SAGE_LOCAL/lib/pkg-config not changed upon Sage move</em> to <em>pkg-config's prefix statements in SAGE_LOCAL/lib/pkgconfig not changed upon Sage move</em>
</li>
</ul>
TicketjhpalmieriSat, 23 Oct 2010 21:16:01 GMT
https://trac.sagemath.org/ticket/9210#comment:59
https://trac.sagemath.org/ticket/9210#comment:59
<p>
See <a class="closed ticket" href="https://trac.sagemath.org/ticket/10162" title="defect: sage-location: "update" library files the first time this is run (closed: fixed)">#10162</a> for a follow-up.
</p>
TicketleifTue, 02 Nov 2010 17:12:32 GMT
https://trac.sagemath.org/ticket/9210#comment:60
https://trac.sagemath.org/ticket/9210#comment:60
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9210#comment:59" title="Comment 59">jhpalmieri</a>:
</p>
<blockquote class="citation">
<p>
See <a class="closed ticket" href="https://trac.sagemath.org/ticket/10162" title="defect: sage-location: "update" library files the first time this is run (closed: fixed)">#10162</a> for a follow-up.
</p>
</blockquote>
<p>
And also (more important) <a class="closed ticket" href="https://trac.sagemath.org/ticket/10202" title="enhancement: Use pkg-config --define-variable option to set ${SAGE_ROOT} anytime ... (closed: wontfix)">#10202</a>.
</p>
Ticket