New package 'iconv' needed for Solaris and Cygwin
Dr. David Kirkby
option to disable the use of iconv, which was previously done in spkg-install,
no longer functions. R *needs* iconv, and the one in Solaris is not suitable.
Hence I propose that iconv is made a standard package.
I've created a ticket
http://trac.sagemath.org/sage_trac/ticket/8191
and have also created the package - see
http://boxen.math.washington.edu/home/kirkby/new-packages/iconv/
At this point, I've marked the ticket as 'needs info' as I have no added the
Mercurial repository, so it is not really ready for review. But the only change
I intend making is to add the repository. Hence it would be useful if people
could test this.
I've tested it on
* sage.math Linux (defaults to 64-bit)
* bsd.math OS X (defaults to 64-bit)
* OpenSolaris 06/2009 on a Sun Ultra 27 (Intel Xeon processor) - 32-bit
* OpenSolaris 06/2009 on a Sun Ultra 27 (Intel Xeon processor) - 64-bit.
* Solaris 10 03/2005 on a Sun Blade 1000 (UltraSPARC III+ processor) - 32-bit
* Solaris 10 03/2005 on a Sun Blade 1000 (UltraSPARC III+ processor) - 64-bit
All tests pass, except on Solaris 10 (SPARC) where one dumps core. I'll just
have to live with that for now. I will report it to the developers.
So can this go into the standard distribution?
Have I overlooked anything in SPKG.txt or spkg-install?
Dave
William Stein
Wow, thanks for all this work getting this together.
I personally think that iconv should be much more easily allowed in as
a standard Sage package (no big waiting period when it is optional
etc.) since it is now _required_ by a standard Sage package (namely
R).
-- William
Dr. David Kirkby
OK, I've created the package, updated spkg/install and spkg/standard/deps. All I
need to do now is resolve the issue of whether I should have a spkg-check, or
whether the check for SAGE_CHECK can be put in spkg-install.
Then hopefully, we will have a working iconv in 4.3.3.
Dave
William Stein
That's easy: have an spkg-check like all the other spkg's should have.
-- William
> Then hopefully, we will have a working iconv in 4.3.3.
>
>
> Dave
>
> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to
> sage-devel+...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
Dr. David Kirkby
> On Sun, Feb 14, 2010 at 5:28 PM, Dr. David Kirkby
>> OK, I've created the package, updated spkg/install and spkg/standard/deps.
>> All I need to do now is resolve the issue of whether I should have a
>> spkg-check, or whether the check for SAGE_CHECK can be put in spkg-install.
>>
>
> That's easy: have an spkg-check like all the other spkg's should have.
>
> -- William
Well, many do not.
Dave
Dr. David Kirkby
spkg-check now exists, along with the Mercurial repositories.
The files $SAGE_ROOT/spkg/install and $SAGE_ROOT/spkg/standard/deps are attached
to the ticket.
Please review
http://trac.sagemath.org/sage_trac/ticket/8191
which should be useful on both Solaris and Cygwin.
Dave
kcrisman
On Feb 15, 7:02 am, "Dr. David Kirkby" <david.kir...@onetel.net>
wrote:
One could then update the R spkg for adding iconv support. There is
currently a ticket with a .p0 spkg for R adding Mac graphics support
(removing the no-aqua options) and some other graphics-related stuff
which is on hold for some other stuff, but it would instead make sense
to just get that one out the door with the iconv added (assuming it
built properly everywhere) and make even better R graphics support a
different ticket.
- kcrisman
Dima Pasechnik
Did you check that Cygwin does not have its own iconv patches?
It used to have patches...
Dmitrii
On Feb 15, 5:02 am, "Dr. David Kirkby" <david.kir...@onetel.net>
wrote:
Dr. David Kirkby
> One could then update the R spkg for adding iconv support. There is
> currently a ticket with a .p0 spkg for R adding Mac graphics support
> (removing the no-aqua options) and some other graphics-related stuff
> which is on hold for some other stuff, but it would instead make sense
> to just get that one out the door with the iconv added (assuming it
> built properly everywhere) and make even better R graphics support a
> different ticket.
>
> - kcrisman
There is a ticket for this
http://trac.sagemath.org/sage_trac/ticket/8272
which covers the iconv case (but not aqua) on both Solaris and OS X.
However, iconv support is *mandatory* now for R, so the previous option used to
disable iconv (--with-iconv=no) is no longer a valid option to configure.
Here is the result from the build on Solaris, where Sun's cut-down iconv was
installed, but the option to disable it was given:
checking iconv.h usability... yes
checking iconv.h presence... yes
checking for iconv.h... yes
checking for iconv... yes
checking whether iconv accepts "UTF-8", "latin1" and "UCS-*"... no
configure: error: a suitable iconv is essential
The R manual makes it clear iconv is required. (Previous versions permitted
iconv to be disabled, but gave a warning:
configure: WARNING: --with-iconv=no is deprecated and will be withdrawn shortly
If you type
configure --help
you will no longer see any option listed to disable iconv.
Unfortunately, it seems the R package does not exit if you give it silly
options, so giving --with-iconv=no is silently ignored.
I can only assume that there is iconv on OS X, like there was on Solaris.
However, the previous R manual made it clear a 'powerful' version of iconv was
needed, and the one on Solaris was not suitable. Hence it was necessary to
disable iconv support on Solaris.
Whether the new iconv package will allow any extra functionality to be added on
OS X I do not know, but there must be some iconv support in OS X, otherwise R
would not build at all.
Dave
Dr. David Kirkby
> Dave,
> Did you check that Cygwin does not have its own iconv patches?
> It used to have patches...
>
> Dmitrii
I've not specifically checked Cygwin myself, but this ticket, created by Mike
Hansen 4 months ago:
http://trac.sagemath.org/sage_trac/ticket/7319
("gdmodule requires libiconv on cygwin")
said iconv was needed on Cygwin and that one would uploaded, but so far it has
not, so I created one.
Dave
kcrisman
On Feb 15, 9:26 am, "Dr. David Kirkby" <david.kir...@onetel.net>
wrote:
I know little of such things, but you must be right, I guess. Note
that iconv is only disabled for 64-bit builds:
if [ "$SAGE64" = "yes" ]; then
echo "Disabling iconv on 64 bit OSX"
OSXFW="--enable-R-framework=no --with-iconv=no"; export OSXFW
The history of this disabling is at http://trac.sagemath.org/sage_trac/ticket/3196.
Interesting that no one has reported problems with the updated R spkg
on 64-bit OSX, that I can remember, but apparently you are right that
this flag is simply now ignored *and* that there must now be 64-bit
libiconv support (whatever that is).
- kcrisman
Dr. David Kirkby
R's spkg-install needs an overhaul, as noted in my previous email (which It
seems to have invalid options, invalid comments, and various other issues. It
would appear we could potentially get better performance too, at the cost of
installing other libraries.
It would appear to me that there are a collection of desirable things for Sage,
like latex, additonal libraries for R, which could be listed on a:
'Nice oo have, but not essential' page.
Dave
kcrisman
> R's spkg-install needs an overhaul, as noted in my previous email (which It
> seems to have invalid options, invalid comments, and various other issues. It
> would appear we could potentially get better performance too, at the cost of
> installing other libraries.
If you could point those out explicitly on the new ticket you created,
that would be awesome.
With regard to the R graphics ticket, does Solaris automatically (or
Linux, for that matter) have Xwindows support?
- kcrisman
Dr. David Kirkby
>> R's spkg-install needs an overhaul, as noted in my previous email (which It
>> seems to have invalid options, invalid comments, and various other issues. It
>> would appear we could potentially get better performance too, at the cost of
>> installing other libraries.
>
> If you could point those out explicitly on the new ticket you created,
> that would be awesome.
Actually, I think I should create a new ticket, for
"R's spkg-install needs a good overhaul"
or something like that, as the ticket I created is very specific to the iconv
code. The problems with R's spkg-install appear to go far beyond that.
> With regard to the R graphics ticket, does Solaris automatically (or
> Linux, for that matter) have Xwindows support?
Solaris supports X. There is a directory /usr/include/X11, which has loads of X
related files. However, R's spkg-install has these 7 lines of code:
------------------------------------------------------------------
# I have problems with this on OSX Intel 10.5.1 -- for now just turn it off.
# It will be good to get something fully working before worrying about X.
if [ -f /usr/include/X11/Xwindows.h ]; then
XSUPPORT=yes
else
XSUPPORT=no
fi
---------------------------------------------------------------------
I don't have the file /usr/include/X11/Xwindows.h on my Solaris boxes, so X is
disabled. I noticed sage.math does have that file, so I assume X is enabled on
Linux (at least on sage.math).
The fact the problem mentioned in spkg-install appeared to have been on OSX
Intel 10.5.1, has not stopped someone disabling X on every platform if
/usr/include/X11/Xwindows.h does not exist.
I don't know if the file /usr/include/X11/Xwindows.h is mandatory for R to
support X.
I know next to nothing about R, but it would seem to mean the package
maintainers should look carefully at it, and see if spkg-install can be improved
somewhat.
I'm a bit concerned at the comment in R's manual that early versions of gcc 4
cause problems on Linux.
It strikes me that packages get updated, and nobody actually looks *carefully*
at what implications that update might have. In this case, the update broke the
build on Solaris, has useless options, patches that might not be needed, and
might be undesirable .... etc.
As a non-mathematician, who will probably make use of only a very small subset
of Sage's features (though statistics being one I would use), it is easy for me
to want to see more emphasis on quality, and less on quantity.
I do feel quite strongly that more testing should be done on the code in Sage.
There seems to be too much emphasis on adding packages, updating packages, but
not doing so too carefully.
Of course, the R developers have not helped in this case, as their code accepts
the option --with-iconv=no, although the option is no longer documented. But
using that option finally gives the message:
configure: error: a suitable iconv is essential
which is stated in the R manual.
Dave
kcrisman
On Feb 15, 12:23 pm, "Dr. David Kirkby" <david.kir...@onetel.net>
wrote:
See the ticket about R graphics (don't have the # in front of me) for
an update on this, and a link to an spkg. However, I know nothing
about X; the current spkg changes things to use quartz for Mac and
continue to look for this file for Xwindows. Any comments you have
about graphics-specific things like this you should put on that
ticket.
> It strikes me that packages get updated, and nobody actually looks *carefully*
> at what implications that update might have. In this case, the update broke the
> build on Solaris, has useless options, patches that might not be needed, and
> might be undesirable .... etc.
>
Yes, please let us know about the other stuff (problems not related to
iconv or X) on a new ticket.
<unrelated-to-R>
But in response to the other comments, the reality is that often
someone updating an spkg needs the new functionality on a few
platforms, and knows very little about configuration and/or other
platforms. If it doesn't break something on currently supported
platforms, we seem to go with upgrades. If we had an easier way to do
it automatically, that would help a lot, as we've both mentioned
before. I certainly know there is no way I would every contribute to
Sage if I needed to test things on Solaris, Linux, Mac, and Cygwin; I
barely have the time to do it on Mac for patches, and Mac and Linux
for spkgs.
</unrelated-to-R>
Thanks for your valuable help on this stuff! It will make Sage so
much more stable long-term, I think.
- kcrisman
Dr. David Kirkby
I don't know much about this.
>> It strikes me that packages get updated, and nobody actually looks *carefully*
>> at what implications that update might have. In this case, the update broke the
>> build on Solaris, has useless options, patches that might not be needed, and
>> might be undesirable .... etc.
>>
>
> Yes, please let us know about the other stuff (problems not related to
> iconv or X) on a new ticket.
I created a new ticket, which lists some of the issues I see with R. It needs
someone with more knowledge of R, and who is willing to read the installation
guide, to tackle this.
http://trac.sagemath.org/sage_trac/ticket/8274
> <unrelated-to-R>
> But in response to the other comments, the reality is that often
> someone updating an spkg needs the new functionality on a few
> platforms, and knows very little about configuration and/or other
> platforms. If it doesn't break something on currently supported
> platforms, we seem to go with upgrades.
IMHO, if someone can't get these tested on supported platforms (which includes
Solaris), then it should go into experimental until properly tested.
http://www.sagemath.org/doc/developer/inclusion.html?highlight=solaris
says
"Some Sage developers are willing to help you port to OSX, Solaris and Windows.
But this is no guarantee and you or your project are expected to do the heavy
lifting and also support those ports upstream if there is no Sage developer who
is willing to share the burden."
But it seems to me, that this is not happening. Packages get updated, without
being tested on other platforms, and break builds.
Would it not seem more reasonable that updates to standard packages go into
"optional" until fully tested? Debian do this - they have 3 in fact. Stable,
testing and unstable.
If person X wants some extra functionality, they should be happy to use an
optional package unless they are willing to either test it themselves more
fully, or get acknowledgment from others that it has been tested.
> Thanks for your valuable help on this stuff! It will make Sage so
> much more stable long-term, I think.
>
> - kcrisman
>
Well, if Sage is ever to become a viable alternative to the commercial products,
I think it needs more testing. I do not believe Wolfram Research would compile
Mathematica on all platforms they support (which includes Solaris), and never
test it on Solaris before making a new release!
Dave