#7095: os x 10.6 port -- numerous mysterious errors caused by weird "abort trap"
issue
------------------------+---------------------------------------------------
Reporter: was | Owner: tbd
Type: defect | Status: new
Priority: critical | Milestone: sage-4.3.1
Component: porting | Keywords:
Work_issues: | Author:
Upstream: N/A | Reviewer:
Merged: |
------------------------+---------------------------------------------------
Comment(by drkirkby):
Replying to [comment:33 kcrisman]:
> From the discussion at #7856:
> > so that "-arch ppc" gets changed to "-arch x86_64"? (That web page
also suggests adding "FFLAGS", and making a few other changes. We can
defer these until later, also.)
> Several posts I saw elsewhere seem to indicate that one possible fix to
problems of this sort is to use -arch i386 instead of no -arch option to
fix some compiling problems on Snow Leopard; it seems like the -m64 is
really the option that is important for actually doing 64-bit. Note that
-arch is an apple only compiler option, and in theory makes universal
binaries, so that one could do -arch i386 -arch x86_64 -arch ppc. It
seems like removing -arch ppc might break PPC support, though?
Since I don't use OS X (though I do have an account on bsd.math), I don't
really claim to know what compiler options may or may not be appropriate
on that platform. Ask me about Solaris and I'd be more help!
However, if it is felt desirable to set specific options like -arch, then
I would suggest you would want to do that on '''all''' binaries in Sage.
In which case, the recent updates to 'sage-env' (#7818) would be the place
to put such options.
sage-env could easily be modified to inject specific flags for specific
versions of OS X. I currently add -m64 if SAGE64 is set to yes, but there
is no reason it could not behave differently on different versions of OS
X.
Since the options set by sage-env are harmless (-g, -Wall and -m64 if
SAGE64 is set to "yes"), it would be necessary to ensure any packages
start by using $CFLAGS, and not simply set CFLAGS to something they want.
(Currently this is not consistent from package to package.)
If you think forcing options on people might be a bad idea, then you could
document that they set them their self. Another option would be to set
them in sage-env, but have an option where potentially risky flags could
be overridden with an environment variable.
A quick way to try a set of options on all package might be to make use of
the gcc -dumpspecs and create a ''specs file''. Then add options to the
specs file. I've done this to force -Wall on gcc, but you could probably
do likewise to force a set of options. It would be a fast way to test this
idea. Otherwise, you are going to have to loads of spkg-install files,
which gets very tedious!
I've tried to force specific options on gcc with a wrapper script, but
that has not been totally successful. Some packages break - sqlite being
the first one.
Dave
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/7095#comment:34>
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.
