Several bugs

[Enrique Artal]

Hi all,

I have found several small bugs. They are unrelated but since I am not really able to solve them I put everything in the same message, hoping someone smarter than me will find the solution.

1. For the first one, it was already reported, with an open ticket, but I am worried about it since it produces wrong outputs. The problem appears working with polynomial rings with local orders, e.g., R.<x,y>=PolynomialRing(QQ,order='neglex'). If one defines a non constant polynomial with constant leading monomial,  e.g. f=1+x, the output of 1/f is 1; in general, the output of 1/(n+non-constant monomials) is 1/n (n constant different from 0). It seems that the problem comes from the fact that the algorithm to divide polynomials checks if the denominator is a unit and in that case the process is to divide every monomial of the numerator by the constant term (which is assumed to be equal to the whole denominator). This is related to the fact that the result of (1+x).is_unit() is True while the result of 1/(1+x) in R is False. Maybe the point is that for Singular the actual ring defined as R is not the polynomial ring but the localization by the order (i.e., we can divide by any non-zero polynomial whose leading term is a constant); in fact, for algorithmic purposes one always works with polynomials (taking out the possible denominators wisely), but the ring is not a polynomial. I guess that a small change in the way of dividing polynomial would suffice.
2. When doing some test for the above problem I realize that R.<x>=PolynomialRing(QQ,order='neglex') does not take into account the order (the above f is not a unit). This is not really an issue, the problem is the fact that the function accept the entry order but it ignores it silently.
3. Next one is completely different and I guess it does not have an issue solution. The symbolic integration has issues when integrating square roots. For example, the integration of sqrt(sin(x)^2) produces wrong output.
4. Finally, the last problem appeared when compiling sage-6.5 with ssl. I followed the standard instructions (which worked in the previous versions) but the compilation of pyopenssl fails. It complains for the compilation of crl.c because of the static definition of a function already declared in a file x509.h of the package openssl. This function is X509_REVOKED_dup. If one eliminates the word "static" prior to the definition, it works but I do not know if it could cause any issue.

I thank the developpers of this software and I am open to collaborate despite my poor level in programming. Best, Enrique.

[Simon King]

Hi Enrique,

On 2015-02-19, Enrique Artal <enriqu...@gmail.com> wrote:
> 1. For the first one, it was already reported, with an open ticket, but

> I am worried about it since it produces wrong outputs.

If there is an open ticket for it, then there is no need to report it
again. However, if it gives wrong results and is not fixed soon then I think
there should be a different ticket adding a "stopgap" (that will print a
warning to the user that the computation may have a wrong result. Has
the stopgap ticket not been opened as well?

> Maybe the point is that for Singular the actual ring defined as
> R is not the polynomial ring but the localization by the order

That's very likely the problem. And I think that the cleanest solution
would be to take this into account by changing the string representation of a
polynomial ring in local ordering: It should not be called
"polynomial ring over ... with generators ..." but "localisation at ...
of polynomial ring over ... with generators ...".

> (i.e., we
> can divide by any non-zero polynomial whose leading term is a constant); in
> fact, for algorithmic purposes one always works with polynomials (taking
> out the possible denominators wisely), but the ring is not a polynomial. I
> guess that a small change in the way of dividing polynomial would suffice.

Very probably not. We would need to deviate from the polynomial backend
(i.e., Singular) fairly much to implement this, which would be
complicated and slow.

> 2. When doing some test for the above problem I realize that *R.<x>=PolynomialRing(QQ,order='neglex')
> *does not take into account the order (the above *f* is not a unit).

Yes, it is, since the ring is in fact localised.

> This is not really an issue, the problem is the fact that the function

> accept the entry *order* but it ignores it silently.

Ahm, why do you think it is ignored?

Best regards,
Simon

[Enrique Artal]

Hi Simon,

Thanks for the feedback

El jueves, 19 de febrero de 2015, 18:23:27 (UTC+1), Simon King escribió:

Hi Enrique,

On 2015-02-19, Enrique Artal <enriqu...@gmail.com> wrote:
>    1. For the first one, it was already reported, with an open ticket, but
>    I am worried about it since it produces wrong outputs.

If there is an open ticket for it, then there is no need to report it
again. However, if it gives wrong results and is not fixed soon then I think
there should be a different ticket adding a "stopgap" (that will print a
warning to the user that the computation may have a wrong result. Has
the stopgap ticket not been opened as well?

Not really. I do not know how to do it but I hope I will have some help tomorrow in my University 

>    Maybe the point is that for Singular the actual ring defined as
>    R is not the polynomial ring but the localization by the order

That's very likely the problem. And I think that the cleanest solution
would be to take this into account by changing the string representation of a
polynomial ring in local ordering: It should not be called
"polynomial ring over ... with generators ..." but "localisation at ...
of polynomial ring over ... with generators ...".

 

I agree 

> (i.e., we
>    can divide by any non-zero polynomial whose leading term is a constant); in
>    fact, for algorithmic purposes one always works with polynomials (taking
>    out the possible denominators wisely), but the ring is not a polynomial. I
>    guess that a small change in the way of dividing polynomial would suffice.

Very probably not. We would need to deviate from the polynomial backend
(i.e., Singular) fairly much to implement this, which would be
complicated and slow.

I think you are right; I think that Singular performs only polynomial computations while knowing that the actual ring is larger and this is OK for any point of view. I do not know if providing the right mathematical answer to division may force to complicate somehow the types of elements in the local rings.

 

>    2. When doing some test for the above problem I realize that *R.<x>=PolynomialRing(QQ,order='neglex')
>    *does not take into account the order (the above *f* is not a unit).

Yes, it is, since the ring is in fact localised.

>    This is not really an issue, the problem is the fact that the function
>    accept the entry *order* but it ignores it silently.

Ahm, why do you think it is ignored?

I have rechecked that  R.<t>=PolynomialRing(QQ,order='neglex');(1+t).is_unit() yields False

Best regards,
Simon

Best regards, Enrique 

[Nils Bruin]

On Thursday, February 19, 2015 at 8:46:19 AM UTC-8, Enrique Artal wrote:

For the first one, it was already reported, with an open ticket, but I am worried about it since it produces wrong outputs. The problem appears working with polynomial rings with local orders, e.g., R.<x,y>=PolynomialRing(QQ,order='neglex'). If one defines a non constant polynomial with constant leading monomial,  e.g. f=1+x, the output of 1/f is 1;

I assume you are referring to http://trac.sagemath.org/ticket/10708 . Indeed, that is rather worrying behaviour.

[Enrique Artal]

I did not know this ticket but it is a related problem. I guess, following also Simon, that the best choice is to create something like LocalPolynomialRing admitting local orderings since even if all the algorithms can be performed inside the polynomials (as Singular does) the actual rings are different. In the example of ticket #10708, the ideal generated by 1-x is the unit ideal, i.e. the total local ring, and hence its Krull dimension is -1.

[Bruno Grenet]

Dear all,

>    2. When doing some test for the above problem I realize that *R.<x>=PolynomialRing(QQ,order='neglex')
>    *does not take into account the order (the above *f* is not a unit).

Yes, it is, since the ring is in fact localised.

>    This is not really an issue, the problem is the fact that the function
>    accept the entry *order* but it ignores it silently.

Ahm, why do you think it is ignored?

I have rechecked that  R.<t>=PolynomialRing(QQ,order='neglex');(1+t).is_unit() yields False

My impression is that Enrique is right: in the constructor PolynomialRing, for univariate polynomial rings the argument `order` seem indeed to be ignored: see `sage/src/rings/polynomial/polynomial_ring_constructor.py` at line 465, the function called in this case is `_single_variate` that does not have an `order` argument. Or to state it otherwise, we have

sage: R.<t>=PolynomialRing(QQ,order='neglex')
sage: R.parent()
<class 'sage.rings.polynomial.polynomial_ring.PolynomialRing_field_with_category'>

And `PolynomialRing`s are *univariate* polynomial rings, without an order argument.

A possibility could be to define a *multivariate* polynomial ring in just one variable (!) when an `order` is given. This is possible with the current implementation I think, though the results do not seem to be correct for the particular question of whether (1+t) is a unit:

sage: from sage.rings.polynomial.multi_polynomial_ring import MPolynomialRing_polydict
sage: R = MPolynomialRing_polydict(QQ, 1, ('t',), "neglex"); R
Multivariate Polynomial Ring in t over Rational Field
sage: R.inject_variables()
Defining t
sage: (1+t).is_unit()
False

Best,
Bruno

[Nils Bruin]

On Thursday, February 19, 2015 at 9:53:18 AM UTC-8, Bruno Grenet wrote:

And `PolynomialRing`s are *univariate* polynomial rings, without an order argument.

Indeed, because different term orders are generally uninteresting on univariate polynomial rings, unless we're allowing term orders that aren't term orders in the usual sense (such as neglex):

A possibility could be to define a *multivariate* polynomial ring in just one variable (!) when an `order` is given. This is possible with the current implementation I think, though the results do not seem to be correct for the particular question of whether (1+t) is a unit:

sage: from sage.rings.polynomial.multi_polynomial_ring import MPolynomialRing_polydict

Right idea, wrong type (highlighting even further why we shouldn't expose Singular's "local rings" via our normal polynomial ring interface):

sage: R.<x>=sage.rings.polynomial.multi_polynomial_libsingular.MPolynomialRing_libsingular(QQ,1,order="neglex")
sage: (1+x).is_unit()
True

[Simon King]

Hi Enrique,

On 2015-02-19, Enrique Artal <enriqu...@gmail.com> wrote:

>> > This is not really an issue, the problem is the fact that the=20
>> function=20
>> > accept the entry *order* but it ignores it silently.=20
>>
>> Ahm, why do you think it is ignored?=20
>>
> I have rechecked that =20
> *R.<t>=3DPolynomialRing(QQ,order=3D'neglex');(1+t).is_unit()* yields False

The problem here is that you are constructing a univariate
polynomial ring, for which Sage does not use Singular. If you want
to use different term orderings or a localisation, you should construct
a "multivariate polynomial ring with a single variable" (I know, this it
sounds silly and is not obvious).

To do so, you should not only provide the list of generator names (this
is what you implicitly do when you write "R.<t> = ..."), but also the
number of generators. Hence:

sage: R.<t> = PolynomialRing(QQ, 1, order='negdeglex')
sage: R # Note: It is MULTIvariate

Multivariate Polynomial Ring in t over Rational Field

sage: R.term_order()
Negative degree lexicographic term order
sage: (1+t).is_unit()
True

in contrast to
sage: R.<t> = PolynomialRing(QQ, order='negdeglex')
sage: R # Note: It is UNIvariate
Univariate Polynomial Ring in t over Rational Field
sage: R.term_order()
Traceback (most recent call last):
...
AttributeError: ...

Same for "neglex" (I actually didn't know that this exists, it is not
mentioned in the docstring):
sage: R.<t> = PolynomialRing(QQ, 1, order='neglex')
sage: R.term_order()
Negative lexicographic term order
sage: (1+t).is_unit()
True

Best regards,
Simon

[Jakob Kroeker]

>If you want
>to use different term orderings or a localisation, you should construct
>a "multivariate polynomial ring with a single variable" (I know, this it
>sounds silly and is not obvious).

@Simon
As state above, the ordering is _silently_ ignored. Thus it is a bug from my point of view. Eof.
Or, did I overlook something?


Jakob

[Simon King]

Hi Bruno,

On 2015-02-19, Bruno Grenet <bruno....@gmail.com> wrote:
> My impression is that Enrique is right: in the constructor
> PolynomialRing, for univariate polynomial rings the argument `order`
> seem indeed to be ignored:

Yes, see my previous post.

> A possibility could be to define a *multivariate* polynomial ring in
> just one variable (!) when an `order` is given. This is possible with
> the current implementation I think, though the results do not seem to be
> correct for the particular question of whether (1+t) is a unit:
>
> sage: from sage.rings.polynomial.multi_polynomial_ring import
> MPolynomialRing_polydict

PLEASE DON'T DO THIS, unless you know what you are doing! Reason: If you
use the various boilerplate polynomial ring constructors directly, you
might break the cache and create several distinct instances of "the
same" polynomial ring, which has a high probability of confusing the
coercion framework and thus compromising the Sage session.

> sage: R = MPolynomialRing_polydict(QQ, 1, ('t',), "neglex"); R
> Multivariate Polynomial Ring in t over Rational Field
> sage: R.inject_variables()
> Defining t
> sage: (1+t).is_unit()
> False

In addition to the above potential disaster, you are constructing here a
ring in the "polydict" implementation, which does not know anything
about localisation. You want a ring in "libsingular" implementation, and
it can be obtained by using the default polynomial ring constructor
(thus, no high danger of desaster) with additional indication of the
number of variables (which returns a multivariate ring):

[Simon King]

Hi Jakob,

On 2015-02-19, Jakob Kroeker <kro...@uni-math.gwdg.de> wrote:
> As state above, the ordering is _silently_ ignored. Thus it is a bug from
> my point of view.

Would it make sense to return a libsingular multivariate polynomial ring
whenever the number of variables is explicitly prescribed OR an ordering
is prescribed OR an implementation is explicitly chosen?

It would be relatively easy to refactor the polynomial ring constructor
so that it only returns something when the chosen implementation
supports all given arguments (such as order).

Best regards,
Simon

[Bruno Grenet]

Hi Simon,

> PLEASE DON'T DO THIS, unless you know what you are doing! Reason: If you
> use the various boilerplate polynomial ring constructors directly, you
> might break the cache and create several distinct instances of "the
> same" polynomial ring, which has a high probability of confusing the
> coercion framework and thus compromising the Sage session.

It was more like a (not so good apparently) example of thing that could
be done in the PolynomialRing constructor, to handle this case. I was
not aware of the possibility you mentioned:

sage: R.<t> = PolynomialRing(QQ, 1, order='neglex')

> Would it make sense to return a libsingular multivariate polynomial ring
> whenever the number of variables is explicitly prescribed OR an ordering
> is prescribed OR an implementation is explicitly chosen?
>
> It would be relatively easy to refactor the polynomial ring constructor
> so that it only returns something when the chosen implementation
> supports all given arguments (such as order).

It would definitely make sense to me to have a simpler way to obtain the
same result as above, for instance with the simpler invocation:

sage: R.<t> = PolynomialRing(QQ, order='neglex')

To me it would make sense to return a libsingular multivariate
polynomial ring whenever an ordering is prescribed or an implementation
is explicitly chosen. But I think I've seen quite often people writing

sage: R.<t> = PolynomialRing(QQ, 1)

and I do not think they wanted to get a Multivariate 1-variable
Polynomial Ring. While whenever a user writes "order=..." or
"implementation=singluar", it seems quite clear that s/he knows what
s/he wants!

Cheers,
Bruno

[Simon King]

Hi Bruno,

On 2015-02-19, Bruno Grenet <bruno....@gmail.com> wrote:

> It would definitely make sense to me to have a simpler way to obtain the
> same result as above, for instance with the simpler invocation:
>
> sage: R.<t> = PolynomialRing(QQ, order='neglex')
>
> To me it would make sense to return a libsingular multivariate
> polynomial ring whenever an ordering is prescribed or an implementation
> is explicitly chosen. But I think I've seen quite often people writing
>
> sage: R.<t> = PolynomialRing(QQ, 1)
>
> and I do not think they wanted to get a Multivariate 1-variable
> Polynomial Ring. While whenever a user writes "order=..." or
> "implementation=singluar", it seems quite clear that s/he knows what
> s/he wants!

While I totally agree that using arguments "order=..." or
"implementation=libsingular" should in future be sufficient to create a
(multivariate and potentially localised) libsingular polynomial ring, I
am not so sure about changing the meaning of "PolynomialRing(QQ,1)". It
would be a backward incompatible change, and some people out in the wild
use it. So, to the very least we'd need a deprecation period.

Best regards,
Simon

[Nils Bruin]

On Thursday, February 19, 2015 at 10:29:08 AM UTC-8, Jakob Kroeker wrote:

>If you want
>to use different term orderings or a localisation, you should construct
>a "multivariate polynomial ring with a single variable" (I know, this it
>sounds silly and is not obvious).

@Simon
As state above, the ordering is _silently_ ignored. Thus it is a bug from my point of view. Eof.
Or, did I overlook something?

Don't all term orderings (in the usual sense) produce the same ordering on a univariate polynomial ring? I think the bug is that there is a term ordering accepted for multivariate polynomial rings that turn it into something that is not a multivariate polynomial ring.

[Simon King]

Hi Nils,

On 2015-02-19, Nils Bruin <nbr...@sfu.ca> wrote:
> Don't all term orderings (in the usual sense) produce the same ordering on
> a univariate polynomial ring?

No. You can have x>1 or x<1 (i.e., a global or a local ordering).

Cheers,
Simon

[Bruno Grenet]

Hi Simon,

I was so sure that the current behavior is

sage: R.<t> = PolynomialRing(QQ, 1); R

Univariate Polynomial Ring in t over Rational Field

that I didn't check, so I thought you propose to change the behavior...
and was reluctant for the exact same reason as you are now: backward
incompatibility. So I agree with you.

Still, I find the following behavior (this time I tested!) a bit a shame:

sage: R.<t> = PolynomialRing(ZZ, 1, implementation="NTL")
Traceback (most recent call first):
...
ValueError: The NTL implementation is not known for multivariate
polynomial rings

And actually, as well as I find the above behavior not the best, I would
also be in favor of raising an error for instance for

sage: R.<t> = PolynomialRing(QQ, implementation="whatever")

At the very least, there is an inconsistency here that should be
corrected to my mind.

Cheers,
Bruno

P.S.: I find the PolynomialRing constructor a bit a mess, maybe we could
give it a refresh, and at the same time make things as consistent as
possible between the different use of it.

[Nils Bruin]

Doesn't the second (local) ordering violate the "usual" part? You would have 1>x>x^2>... etc., which is not allowed according to, for instance, the definition in [Section 15.2 in Eisenbud, Commutative Algebra with a view towards Algebraic Geometry, GTM 150, Springer 2004]]

 

[Simon King]

Hi Nils,

On 2015-02-19, Nils Bruin <nbr...@sfu.ca> wrote:
> Doesn't the second (local) ordering violate the "usual" part? You would
> have 1>x>x^2>... etc., which is not allowed according to, for instance, the
> definition in [Section 15.2 in Eisenbud, Commutative Algebra with a view
> towards Algebraic Geometry, GTM 150, Springer 2004]]

Have a look at the book of Greuel, Pfister et al ("A Singular
introduction to commutative algebra"). Local orderings of course have
the problem that reductions may not be as easily to handle (think of the
relation x=x^2 with x^2<x and try to compute the normal forma of x with
respect to that relation). But if you compute so-called *weak* normal
forms in a localisation (i.e. 1-x is a unit), then local orderings are a
good tool.

Best regards,
Simon

[mmarco]

+1 to writing a class for localizations of polynomial rings with respect to orderings. 

[Daniel Krenn]

Am 2015-02-19 um 17:46 schrieb Enrique Artal:
> 4. Finally, the last problem appeared when compiling sage-6.5 with ssl.

> I followed the standard instructions (which worked in the previous
> versions) but the compilation of pyopenssl fails. It complains for
> the compilation of crl.c because of the static definition of a
> function already declared in a file x509.h of the package openssl.
> This function is X509_REVOKED_dup. If one eliminates the word
> "static" prior to the definition, it works but I do not know if it
> could cause any issue.

Same problem on current Debian stable in a fresh Sage-installation:

git checkout 6.5
make
./sage -i openssl
./sage -i pyopenssl

This fails with the output given below.

Best wishes

Daniel


user@host:/local/data/krenn/sage/6.5.rc2$ ./sage -i pyopenssl
Attempting to download package pyopenssl
>>> Checking online list of optional packages.
[.]
>>> Found pyopenssl-0.13.p0
>>> Trying to download
http://www.sagemath.org/spkg/optional/pyopenssl-0.13.p0.spkg
[............................]
pyopenssl-0.13.p0
====================================================
Extracting package
/local/data/krenn/sage/6.5.rc2/upstream/pyopenssl-0.13.p0.spkg
-rw-rw-r-- 1 krenn krenn 226048 Feb 20 10:25
/local/data/krenn/sage/6.5.rc2/upstream/pyopenssl-0.13.p0.spkg
Finished extraction
****************************************************
Host system:
Linux host 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u3 x86_64 GNU/Linux
****************************************************
C compiler: gcc
C compiler version:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5'
--with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-gnu-unique-object --enable-plugin --enable-objc-gc
--with-arch-32=i586 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.2 (Debian 4.7.2-5)
****************************************************
patching file OpenSSL/ssl/connection.c
patching file OpenSSL/ssl/context.c
/local/data/krenn/sage/6.5.rc2/local/lib/python/distutils/dist.py:267:
UserWarning: Unknown distribution option: 'zip_safe'
warnings.warn(msg)
running build_ext
building 'OpenSSL.crypto' extension
creating build
creating build/temp.linux-x86_64-2.7
creating build/temp.linux-x86_64-2.7/OpenSSL
creating build/temp.linux-x86_64-2.7/OpenSSL/crypto
gcc -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -fPIC
-I'/local/data/krenn/sage/6.5.rc2/local'/include
-I/local/data/krenn/sage/6.5.rc2/local/include/python2.7 -c
OpenSSL/crypto/crypto.c -o
build/temp.linux-x86_64-2.7/OpenSSL/crypto/crypto.o
gcc -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -fPIC
-I'/local/data/krenn/sage/6.5.rc2/local'/include
-I/local/data/krenn/sage/6.5.rc2/local/include/python2.7 -c
OpenSSL/crypto/x509.c -o build/temp.linux-x86_64-2.7/OpenSSL/crypto/x509.o
gcc -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -fPIC
-I'/local/data/krenn/sage/6.5.rc2/local'/include
-I/local/data/krenn/sage/6.5.rc2/local/include/python2.7 -c
OpenSSL/crypto/x509name.c -o
build/temp.linux-x86_64-2.7/OpenSSL/crypto/x509name.o
gcc -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -fPIC
-I'/local/data/krenn/sage/6.5.rc2/local'/include
-I/local/data/krenn/sage/6.5.rc2/local/include/python2.7 -c
OpenSSL/crypto/pkey.c -o build/temp.linux-x86_64-2.7/OpenSSL/crypto/pkey.o
gcc -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -fPIC
-I'/local/data/krenn/sage/6.5.rc2/local'/include
-I/local/data/krenn/sage/6.5.rc2/local/include/python2.7 -c
OpenSSL/crypto/x509store.c -o
build/temp.linux-x86_64-2.7/OpenSSL/crypto/x509store.o
gcc -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -fPIC
-I'/local/data/krenn/sage/6.5.rc2/local'/include
-I/local/data/krenn/sage/6.5.rc2/local/include/python2.7 -c
OpenSSL/crypto/x509req.c -o
build/temp.linux-x86_64-2.7/OpenSSL/crypto/x509req.o
gcc -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -fPIC
-I'/local/data/krenn/sage/6.5.rc2/local'/include
-I/local/data/krenn/sage/6.5.rc2/local/include/python2.7 -c
OpenSSL/crypto/x509ext.c -o
build/temp.linux-x86_64-2.7/OpenSSL/crypto/x509ext.o
gcc -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -fPIC
-I'/local/data/krenn/sage/6.5.rc2/local'/include
-I/local/data/krenn/sage/6.5.rc2/local/include/python2.7 -c
OpenSSL/crypto/pkcs7.c -o build/temp.linux-x86_64-2.7/OpenSSL/crypto/pkcs7.o
gcc -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -fPIC
-I'/local/data/krenn/sage/6.5.rc2/local'/include
-I/local/data/krenn/sage/6.5.rc2/local/include/python2.7 -c
OpenSSL/crypto/pkcs12.c -o
build/temp.linux-x86_64-2.7/OpenSSL/crypto/pkcs12.o
gcc -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -fPIC
-I'/local/data/krenn/sage/6.5.rc2/local'/include
-I/local/data/krenn/sage/6.5.rc2/local/include/python2.7 -c
OpenSSL/crypto/netscape_spki.c -o
build/temp.linux-x86_64-2.7/OpenSSL/crypto/netscape_spki.o
gcc -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -fPIC
-I'/local/data/krenn/sage/6.5.rc2/local'/include
-I/local/data/krenn/sage/6.5.rc2/local/include/python2.7 -c
OpenSSL/crypto/revoked.c -o
build/temp.linux-x86_64-2.7/OpenSSL/crypto/revoked.o
gcc -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -fPIC
-I'/local/data/krenn/sage/6.5.rc2/local'/include
-I/local/data/krenn/sage/6.5.rc2/local/include/python2.7 -c
OpenSSL/crypto/crl.c -o build/temp.linux-x86_64-2.7/OpenSSL/crypto/crl.o
OpenSSL/crypto/crl.c:6:23: error: static declaration of
'X509_REVOKED_dup' follows non-static declaration
In file included from
/local/data/krenn/sage/6.5.rc2/local/include/openssl/ssl.h:156:0,
from OpenSSL/crypto/x509.h:17,
from OpenSSL/crypto/crypto.h:30,
from OpenSSL/crypto/crl.c:3:
/local/data/krenn/sage/6.5.rc2/local/include/openssl/x509.h:751:15:
note: previous declaration of 'X509_REVOKED_dup' was here
error: command 'gcc' failed with exit status 1

Error building pyOpenSSL!
Check that OpenSSL development headers are installed,
or install the OpenSSL SPKG into your Sage installation.

real 0m1.913s
user 0m1.412s
sys 0m0.196s
************************************************************************
Error installing package pyopenssl-0.13.p0
************************************************************************
Please email sage-devel (http://groups.google.com/group/sage-devel)
explaining the problem and including the relevant part of the log file
/local/data/krenn/sage/6.5.rc2/logs/pkgs/pyopenssl-0.13.p0.log
Describe your computer, operating system, etc.
If you want to try to fix the problem yourself, *don't* just cd to
/local/data/krenn/sage/6.5.rc2/local/var/tmp/sage/build/pyopenssl-0.13.p0 and
type 'make' or whatever is appropriate.
Instead, the following commands setup all environment variables
correctly and load a subshell for you to debug the error:
(cd
'/local/data/krenn/sage/6.5.rc2/local/var/tmp/sage/build/pyopenssl-0.13.p0'
&& '/local/data/krenn/sage/6.5.rc2/sage' --sh)
When you are done debugging, you can type "exit" to leave the subshell.
************************************************************************