#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.2
Component: solaris | Keywords:
Author: David Kirkby, Willem Jan Palenstijn | Upstream: Reported
upstream. Little or no feedback.
Reviewer: | Merged:
Work_issues: |
---------------------------------------------------+------------------------
Comment(by drkirkby):
Replying to [comment:22 wjp]:
> I don't think William was involved in this ticket, so I'm going to
assume you mean me :-)
Sorry Willem, I did mean you.
> I don't really like how all this logic is going into spkg-install files.
If this keeps up, every spkg-install file will end up having pages and
pages of code which is common to (almost) every spkg-install, and this
will make maintaining that common code a mess. Additionally, it makes it
very untransparent what effect the various environment variables that can
be set have (and for that matter _which_ environment variables affect the
build).
I do agree in principle, but we have tried in the past (e.g. #7818) to set
things like CFLAGS globally, and it just failed - totally messing up
Cython in particular.
Different packages in Sage have different ways of how to specify 64-bit
builds. ATLAS takes a command line option (-b64), zlib takes a command
line option (--64), some need CFLAGS set, some need an ABI set.
Some (in fact most) packages use "gcc" irrespective of the setting of the
variable CC, so setting CC is pointless, as packages have "gcc" hard-coded
in them. At one point I started fixing some of these, so they would use
$CC, but I gave up, as there are so many of them - see for example #7024,
#7027, #7038, #7041, #7048, #7066, #7069, #7071, etc etc.)
To my knowledge, there are only three tickets that need this change of
adding -m64 to $CC.
* This ticket
* Pynac #7861
* Numpy #8086
I don't think there will be any more either, as I have managed to build a
64-bit Sage on Solaris 10 on the SPARC processor using this change.
Implementing a global change is likely to cause more problems than on 3
tickets.
Dave
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/7864#comment:23>
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.
