#15316: Make gf2x respect SAGE_FAT_BINARY and use --libdir
-------------------------------------+-------------------------------------
Reporter: jpflori | Owner:
Type: defect | Status: needs_work
Priority: critical | Milestone: sage-6.1
Component: packages: | Resolution:
standard | Merged in:
Keywords: spkg gf2x | Reviewers: Jeroen Demeyer
Authors: Jean-Pierre Flori | Work issues:
Report Upstream: N/A | Commit:
Branch: | 2371b3586b7b656293f036dc6e0d467946d02ad8
u/jpflori/ticket/15316 | Stopgaps:
Dependencies: |
-------------------------------------+-------------------------------------
Comment (by jpflori):
Replying to [comment:7 jdemeyer]:
> Perhaps SSE2 is not part of the official standard, but at least all
x86_64 CPUs support it, so it would say it is "de facto" standard. Also
GCC will generate SSE+SSE2 code by default on x86_64, which is a very
strong precedent.
I agree, and that's what I defended upstream, but Emmanuel didn't hear it
that way...
>
> Is this not just a matter of '''not''' replacing the symlink?
In fact, if SSE2 is enabled, then we don't even need to replace the
symlinks.
Apart from the feedback from upstream which does not want to provide a
build system with an option to disable optimizations which would build an
SSE2 lib but without further optimizations on x86_64, but just one which
would simply point to the generic32/64 folders (so no assembly at all
whatever the platform) when enabled.
The other issue is that I did not feel the need to add a bunch of code to
spkg-install tyo detect if the system targeted is 32/64 bits, x86 or sparc
or whatever, and then pass the correct value to the "hwdir" var (let's say
x86, x86_64 and so on depending on the system, which is what I asked for
upstream but got as a response: "we'll pass generic32/64 and nothing more
depending on the bit length"), when passing unconditionnaly "--disable-
sse2 --disable-pclmul" would more or less do the trick (except for the
fact it broke the build on x86_64...).
Indeed this would really fit in the upstream autotools project, not within
our spkg-install script.
But you nearly convinced me to submit that upstream....
--
Ticket URL: <http://trac.sagemath.org/ticket/15316#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 unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/groups/opt_out.
