You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Libgcrypt is a package which has some assembly code routines. An option to the configure script
--disable-asm
will disable the use of assembly code. This is mandatory on some platforms such as OS X and 64-bit SPARC, and would appear to be desirable on others, unless we can be sure it works.
On my Sun Ultra 27, which has a quad core Xeon, running OpenSolaris 06/2009, libgrcypt would not build. The error message indicated it was related to the use of assembly code.
However, I believe libgcrypt did not cause an issue on 'disk.math', so I'm somewhat surprised it did on my Ultra 27. But I think it is safer to disable assembly code on all Solaris x86 systems.
I disabled the assembly code on 64-bit SPARC too, as I know that is broken - see #7127. Disabling the assembly code does not allow libgcrypt to be built as 64-bit code on Solaris, but the build does get further with the assembly code disabled. (It ultimately fails, as both 32-bit and 64-bit objects are created).
I also added some tests for other platforms (AIX, HP-UX, Tru64 and IRIX) and disabled assembly language on them all except HP-UX, where I could verify it did not cause any problems.
Hence assembler code is disabled on
OS X (both 32 and 64-bit)
Solaris x86 (both 32 and 64-bit)
Solaris SPARC (32-bit only)
IRIX (as a precaution, as untested)
AIX (as a precaution, as untested)
Tru64 (as a precaution, as untested)
'''
Assembly code is enabled on:'''
Linux
Solaris SPARC (32-bit only)
HP-UX
Anything else, not mentioned above. This would include Cygwin.
The updated package has been tested on
sage.math
bsd.math
Sun Ultra 27, Intel Xeon processor, running OpenSolaris (x86)
Sun Blade 2000, SPARC processor in 32-bit mode.
Sun Blade 2000, SPARC processor in 64-bit mode. The code does not build fully in this case, as explained above.
HP C3600 running HP-UX 11.11. The code builds fully.
It should be noted, the HP C3600 uses a PA-RISC processor. More modern HP-UX machines use the Itanium processor. These would certainly not use the same assembly code.
sagetrac-drkirkbymannequin
changed the title
Disable assembly code in libgcrypt on Solaris x86 & rare platforms.
Disable assembly code in libgcrypt on risky platforms.
Nov 2, 2009
Libgcrypt is a package which has some assembly code routines. An option to the configure script
will disable the use of assembly code. This is mandatory on some platforms such as OS X and 64-bit SPARC, and would appear to be desirable on others, unless we can be sure it works.
On my Sun Ultra 27, which has a quad core Xeon, running OpenSolaris 06/2009, libgrcypt would not build. The error message indicated it was related to the use of assembly code.
However, I believe libgcrypt did not cause an issue on 'disk.math', so I'm somewhat surprised it did on my Ultra 27. But I think it is safer to disable assembly code on all Solaris x86 systems.
I disabled the assembly code on 64-bit SPARC too, as I know that is broken - see #7127. Disabling the assembly code does not allow libgcrypt to be built as 64-bit code on Solaris, but the build does get further with the assembly code disabled. (It ultimately fails, as both 32-bit and 64-bit objects are created).
I also added some tests for other platforms (AIX, HP-UX, Tru64 and IRIX) and disabled assembly language on them all except HP-UX, where I could verify it did not cause any problems.
Hence assembler code is disabled on
'''
Assembly code is enabled on:'''
The updated package has been tested on
It should be noted, the HP C3600 uses a PA-RISC processor. More modern HP-UX machines use the Itanium processor. These would certainly not use the same assembly code.
The code may be found here.
http://sage.math.washington.edu/home/kirkby/Solaris-fixes/libgcrypt-1.4.4.p1
Dave
Component: porting
Author: David Kirkby
Reviewer: Mike Hansen
Merged: sage-4.2.1.alpha0
Issue created by migration from https://trac.sagemath.org/ticket/7373
The text was updated successfully, but these errors were encountered: