#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 kcrisman):
From the discussion at #7856:
> Finally, if SAGE64 is set and we're on DARWIN, is it worth making some
of the other changes in [http://blog.hyperjeff.net/?p=160]? For example,
in src/make.osx, changing
> {{{
> CFLAGS="-arch i386 -arch ppc -I${PREFIX}/include
-I${PREFIX}/include/freetype2 -isysroot /Developer/SDKs/MacOSX10.4u.sdk"
> LDFLAGS="-arch i386 -arch ppc -L${PREFIX}/lib
-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk"
> }}}
> 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?
-arch arch
Compile for the specified target architecture arch. The allowable values
are `i386', `x86_64', `ppc' and `ppc64'. Multiple options work, and direct
the compiler to produce “universal” binaries including object code for
each architecture specified with -arch. This option only works if
assembler and libraries are available for each architecture specified.
(APPLE ONLY)
-Xarch_arch option
Apply option to the command line for architecture arch. This is useful for
specifying an option that should only apply to one architecture when
building a “universal” binary. (APPLE ONLY)
Second comment - in Sage 4.3 on Macintel 10.5:
{{{
sage: sinh(CIF(2.2))
Traceback:
...
TypeError: Unable to convert x (='2.2000000000000002?') to real number
}}}
and similarly for cosh and tanh. The reason it doesn't happen for coth
(and sech and csch) is because that is not a Ginac function, apparently -
it inherits from HyberbolicFunction, which inherits from BuiltInFunction,
but sinh and friends inherit from GinacFunction. So apparently these
errors are somehow related to Ginac trying (incorrectly) to just turn
CIF(2.2) into a real number via RealNumber._set() in real_mpfr.pyx),
though of course the abort trap is much, much worse than a fairly
informative TypeError! But anyway these are avoidable elsewhere, at least
in principle.
Please let me know if these comments are not useful. I really want to
help resolve this but don't want to cloud things with ignorance. Maybe I
should ask for an account on bsd.math to help?
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/7095#comment:33>
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.
