#7864: libfplll tries to link 64-bit objects to 32-bit libstdc++.so
----------------------------+-----------------------------------------------
Reporter: drkirkby | Owner: drkirkby
Type: defect | Status: needs_work
Priority: major | Milestone: sage-4.5
Component: solaris | Keywords:
Author: David Kirkby | Upstream: Reported upstream. Little or no
feedback.
Reviewer: | Merged:
Work_issues: |
----------------------------+-----------------------------------------------
Changes (by drkirkby):
* status: needs_review => needs_work
Comment:
Replying to [comment:8 wjp]:
> 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.)
Yes, I think so. I just checked to make sure the correct library is there
{{{
drkir...@hawk:~$ file /usr/local/gcc-4.4.4-multilib/lib/gcc/i386-pc-
solaris2.11/4.4.4/../../../amd64/libstdc++.so
/usr/local/gcc-4.4.4-multilib/lib/gcc/i386-pc-
solaris2.11/4.4.4/../../../amd64/libstdc++.so: ELF 64-bit LSB dynamic
lib AMD64 Version 1, dynamically linked, not stripped
drkir...@hawk:~$
}}}
as you can see, the 64-bit one is there.
> The question remains: why does libtool pick up the wrong path...
Yes. This is not the only package where I've had this problem. There are
two of them. But many packages use libtool ok.
> 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?
Of course I am willing. I'd like to get a better solution to this. My fix
is a hack, I know that. It allows it to build, but I'm not keen on it.
Given you have some ideas on how to resolve this, I'm going to change it
to 'needs work' so it does not get reviewed. Hopefully we can find a
better solution than this one.
I just started a fresh build of this. I'll have a shower, and by the time
I'm finished, it should have failed and I'll post the output in an half an
hour or so. (It depends somewhat on the size of the log file. It might
take me a time to upload.) Unlike 't2', this machine is pretty quick, so
it does not take long to build Sage. Excluding Maxima and R, which are not
building on !OpenSolaris, it only takes 40 minutes to build all of Sage.
Dave
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/7864#comment:9>
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.
