#7864: libfplll tries to link 64-bit objects to 32-bit libstdc++.so
----------------------------+-----------------------------------------------
Reporter: drkirkby | Owner: drkirkby
Type: defect | Status: needs_review
Priority: major | Milestone: sage-4.5
Component: solaris | Keywords:
Author: David Kirkby | Upstream: Reported upstream. Little or no
feedback.
Reviewer: | Merged:
Work_issues: |
----------------------------+-----------------------------------------------
Comment(by wjp):
Replying to [comment:7 drkirkby]:
> As noted above (10 days ago), I'm now using a different compiler,
/usr/local/gcc-4.4.4-multilib/bin/gcc I've shown the error with the new
compiler above, so I don't need to repeat it. So I'm not typing exactly
what you said.
Oh, sorry, I copy/pasted the gcc path from your message (8 days ago) about
t2. I'm glad you were more awake than me :-)
If I'm reading this right, then in the 64-bit "libraries" section, the
correct path
{{{/usr/local/gcc-4.4.4-multilib/lib/gcc/i386-pc-
solaris2.11/4.4.4/../../../amd64/}}}
shows up before the wrong path that it's using
{{{
/usr/local/gcc-4.4.4-multilib/lib/gcc/i386-pc-solaris2.11/4.4.4/../../../
}}}
(Which is not unexpected.)
The question remains: why does libtool pick up the wrong path...
If you're willing to try one more (last ditch effort) command, could you
put the (very lengthy) output of the failing libtool command online
somewhere (maybe as a .gz'ed attachment or on a webserver somewhere), but
with a {{{--debug}}} switch added?
(In a sage shell, right after the failed build, from
{{{/export/home/drkirkby/sage-4.5.alpha0/spkg/build/libfplll-3.0.12.p1/src}}}
)
This is the failing libtool command with an extra {{{--debug}}} switch,
hopefully copy-pasted from the right output message above this time :-)
{{{
/bin/sh ./libtool --debug --tag=CXX --mode=link g++ -fPIC
-I/export/home/drkirkby/sage-4.5.alpha0/local/include/
-L/export/home/drkirkby/sage-4.5.alpha0/local/lib -m64 -m64 -o
libfplll.la -rpath /export/home/drkirkby/sage-4.5.alpha0/local/lib
-version-info 1:0:1 dummy.lo -lgmp -lmpfr -lmpfr -lgmp -lmpfr -lgmp
}}}
It should be possible to trace back the origin of the offending path from
that dump.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/7864#comment:8>
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.
