#9210: pkg-config prefix statements in SAGE_LOCAL/lib/pkg-config not changed
upon
Sage move
-------------------------------------------------+--------------------------
Reporter: jason | Owner: drkirkby
Type: defect | Status: positive_review
Priority: major | Milestone: sage-4.6
Component: build | Keywords:
Author: Jason Grout | Upstream: N/A
Reviewer: David Kirkby, Karl-Dieter Crisman | Merged:
Work_issues: |
-------------------------------------------------+--------------------------
Comment(by drkirkby):
I found the reason gfan has unresolved variables when moved - it is to do
with gcc and the linker run time search path.
In a Sage shell, before the move:
{{{
(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
}}}
After creating another account, and moving Sage, I must have not set
LD_LIBRARY_PATH identically, so ldd shows:
{{{
(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
}}}
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
{{{/usr/lib/libstdc++.so.6}}}. That is from gcc 3.4.3 - i.e. very old.
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.
There was one other thing I found odd. '''Before''' moving the code,
though after Sage had been run, I tried this in a Sage shell.
{{{
(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
}}}
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.
I tried it on sage.math too. Whilst it does not dump core, it is not very
elegant:
{{{
(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
}}}
And on bsd.math (OS X)
{{{
(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
}}}
So as soon as the parser sees something it does not reconise, it either
aborts or dumps core. Not very elegant.
Dave
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/9210#comment:52>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
