[Rd] Corrections for the R manual on Solaris
There are a few errors in the R manual about Solaris. 1) Firstly you may know that Sun is now owned by Oracle. 2) "(Recent Sun machines are Opterons (‘amd64’) rather than ‘x86’, but 32-bit ‘x86’ executables are the default.) " It's not true to say that recent machines are Opterons rather than x86. Many new Sun machines are based on 64-bit Intel CPUs (often called x64). The machine I'm using, a Sun Ultra 27 http://www.sun.com/desktop/workstation/ultra27/index.xml is less than 6 months old and has a quad core 3.33 GHz Intel Xeon in it. It is certainly true that some recent machine are Opterons. Note, 64-bit libraries for 64-bit systems, even those based on Intel CPUs, go in /usr/lib/amd64. Likewise many open-source software will install the 64-bit libraries in /usr/local/lib/amd64. There's no "intel64" or anything like that. 3) "Modern Solaris systems allow a large selection of Open Source software to be installed from http://www.opencsw.org (formerly http://www.blastwave.org) via pkg-get, " It should be noted that OpenCSW and Blastwave are both still in existence. There's a lot of animosity between the two camps, but both do exist. So one is not formally the other. Unfortunately, they both install software in /opt/csw, so I would be very weary of using both sites, as there is no coordination between them. Dave __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Corrections for the R manual on Solaris
On 06/17/10 12:53 PM, Dr. David Kirkby wrote: There are a few errors in the R manual about Solaris. 1) Firstly you may know that Sun is now owned by Oracle. 2) "(Recent Sun machines are Opterons (‘amd64’) rather than ‘x86’, but 32-bit ‘x86’ executables are the default.) " It's not true to say that recent machines are Opterons rather than x86. Many new Sun machines are based on 64-bit Intel CPUs (often called x64). The machine I'm using, a Sun Ultra 27 http://www.sun.com/desktop/workstation/ultra27/index.xml is less than 6 months old and has a quad core 3.33 GHz Intel Xeon in it. It is certainly true that some recent machine are Opterons. Note, 64-bit libraries for 64-bit systems, even those based on Intel CPUs, go in /usr/lib/amd64. Likewise many open-source software will install the 64-bit libraries in /usr/local/lib/amd64. There's no "intel64" or anything like that. 3) "Modern Solaris systems allow a large selection of Open Source software to be installed from http://www.opencsw.org (formerly http://www.blastwave.org) via pkg-get, " It should be noted that OpenCSW and Blastwave are both still in existence. There's a lot of animosity between the two camps, but both do exist. So one is not formally the other. Unfortunately, they both install software in /opt/csw, so I would be very weary of using both sites, as there is no coordination between them. Dave Did nobody have any comments on this? Should I report this as a bug? I first posted this on r-help, where I was told r-devel would be more appropriate. But I've yet to get any response. Dave __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] No RTFM?
On 08/20/10 01:08 AM, Spencer Graves wrote:
What do you think about adding a "No RTFM" policy to the R mailing
lists? Per, "http://en.wikipedia.org/wiki/RTFM":
The Ubuntu Forums and LinuxQuestions.org, for instance, have instituted
"no RTFM" policies to promote a welcoming atmosphere.[8][9].
RTFM [and] "Go look on google" are two inappropriate responses to a
question. If you don't know the answer or don't wish to help, please say
nothing instead of brushing off someone's question. Politely showing
someone how you searched or obtained the answer to a question is
acceptable, even encouraged.
...
If you wish to remind a user to use search tools or other resources when
they have asked a question you feel is basic or common, please be very
polite. Any replies for help that contain language disrespectful towards
the user asking the question, i.e. "STFU" or "RTFM" are unacceptable and
will not be tolerated. —Ubuntu Forums
Gavin Simpson and I recently provided examples answering a question from
"r.ookie" that had previously elicited responses, ""You want us to read
the help page to you?" and "It yet again appears that you are asking us
to read the help pages for you."
I can appreciate the sentiment in fortunes('rtfm'). In this case,
however, "r.ookie" had RTFM (and said so), but evidently the manual was
not sufficiently clear.
Best Wishes,
Spencer Graves
I've personally found the R community somewhat unhelpful at times. In fact, of
all the resources I use:
* Newsgroups like comp.unix.shell, sci.math.symbolic, comp.unix.aix,
comp.unix.solaris
* Mailing lists for autoconf, automake, gcc, sage maths, ecl, time-nuts.
* Forums for OpenSolaris
I've found the r-devel about the least helpful of the lot.
My most recent example was when I created a bug report about a version of R that
was about 4 months old. The bug was that the configure test failed to detect the
version of libicu was unsuitable on Solaris. (Since it was the version of the
library shipped with Solaris, I would personally have thought the configure
script should detect its too old if it is).
When submitting the bug, I selected the particular R version from the pull-down
menu, as it was listed.
Then I got some snotty reply about reading the FAQ and not submitting bug
reports for old versions of R. At the time I submitted it, I suspect the version
I had was about 4 months old. Ask on a Solaris mailing list about a 5 year old
version of Solaris and you will get civil replies. Likewise, the gcc lists don't
expect everyone to be running very recent versions.
I would have like to have responded on the technical content of the message, as
I believe the autoconf test is flawed if it can't detect that a version of a
library installed by Sun is unsuitable. But I decided that such responses were
best ignored.
There's quite a bit in the R manual about Solaris that is just plain wrong, but
although I've reported some of the problems, these were ignored, so I can't even
be bothered to report the rest.
I must admit, I do sometimes give people links to
http://justfuckinggoogleit.com/
when I think they are being particularly dumb in not using Google, so I do
appreciate it can get annoying when people ask questions they should be able to
get answered themselves.
But it seems to me that arrogance is more normal on r-devel than on other lists
I use.
Thankfully, I don't have to use r-devel much.
Flames to /dev/null.
Dave
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Does R use "computed gotos" - a gcc extension of C?
The R manual says R will not build with gcc on 64-bit Solaris x86 with gcc http://cran.r-project.org/doc/manuals/R-admin.html#Solaris "Tests with gcc32 on ‘x86’ and ‘amd64’ have been less successful: ‘x86’ builds have failed on tests using complex arithmetic33, whereas on ‘amd64’ the builds have failed to complete in several different ways, most recently with relocation errors for libRblas.so. " I know what the "relocation errors" problem is. That library (and in fact two other R libraries) all have non-PIC code in them, despite the fact the source is compiled with the -fPIC option. http://blogs.sun.com/rie/entry/my_relocations_don_t_fit shows how to prove this. If one runs this command on Solaris: $ elfdump -d libRblas.so | fgrep TEXTREL there is some output showing that theres non-PIC code present in the R library. R is compiled with -fPIC on Solaris, but certain things can cause non-PIC code to be generated even with that option. One is by the use of "computed gotos" which is a gcc extension. I'm wondering if R uses any of these. I'd love to track down this problem, so R can build with gcc. R is used in the Sage maths project http://www.sagemath.org/ and R is the only component of Sage which will not build with gcc on 64-bit Solaris x86. Many components will not build with Sun Studio, but this R issue means we need to have two compilers, not just one. -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? Dave __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Does R use "computed gotos" - a gcc extension of C?
On 03/ 4/11 11:40 PM, luke-tier...@uiowa.edu wrote:
On Fri, 4 Mar 2011, Dr. David Kirkby wrote:
The R manual says R will not build with gcc on 64-bit Solaris x86 with
gcc
http://cran.r-project.org/doc/manuals/R-admin.html#Solaris
"Tests with gcc32 on ‘x86’ and ‘amd64’ have been less successful:
‘x86’ builds have failed on tests using complex arithmetic33, whereas
on ‘amd64’ the builds have failed to complete in several different
ways, most recently with relocation errors for libRblas.so. "
I know what the "relocation errors" problem is. That library (and in
fact two other R libraries) all have non-PIC code in them, despite the
fact the source is compiled with the -fPIC option.
http://blogs.sun.com/rie/entry/my_relocations_don_t_fit
shows how to prove this. If one runs this command on Solaris:
$ elfdump -d libRblas.so | fgrep TEXTREL
there is some output showing that theres non-PIC code present in the R
library.
R is compiled with -fPIC on Solaris, but certain things can cause
non-PIC code to be generated even with that option. One is by the use
of "computed gotos" which is a gcc extension. I'm wondering if R uses
any of these.
Yes -- in the byte code interpreter in eval.c
luke
Thank you Luke. Do you know if there may be any others?
Do you know if that bit of code gets compiled into all 3 of the R libraries? I
tried replacing
#define NEXT() (__extension__ ({goto *(*pc++).v;}))
by a function which did absolutely nothing. The code built, but still had the
library issues.
I'm almost certain that the definition of NEXT will cause problems, but I'm not
convinced it is the only issue.
What happens if a non-GNU compiler is used? I assume these GNU extensions don't
get used, so how comes the code builds? Is there any way I can disable the use
of the GNU extensions, while still building with gcc.
It is rather annoying that the code has __extension__ in it, which disables the
warnings about the use of GCC extensions.
http://gcc.gnu.org/onlinedocs/gcc/Alternate-Keywords.html
Why is there a need to hide the use of the extensions? I'd personally like to
see just standard C used, without any extensions. Then problems like I'm having
would be less likely to occur.
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
Dave
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Does R use "computed gotos" - a gcc extension of C?
On 03/ 5/11 09:31 PM, luke-tier...@uiowa.edu wrote:
On Sat, 5 Mar 2011, Dr. David Kirkby wrote:
Yes -- in the byte code interpreter in eval.c
luke
Thank you Luke. Do you know if there may be any others?
I do not.
Do you know if that bit of code gets compiled into all 3 of the R
libraries? I tried replacing
I do not know
#define NEXT() (__extension__ ({goto *(*pc++).v;}))
by a function which did absolutely nothing. The code built, but still
had the library issues.
I'm almost certain that the definition of NEXT will cause problems,
but I'm not convinced it is the only issue.
What happens if a non-GNU compiler is used? I assume these GNU
extensions don't get used, so how comes the code builds? Is there any
way I can disable the use of the GNU extensions, while still building
with gcc.
This particular bit It only uses the gcc extensions for gcc compilers,
and this can be turned off by defining NO_THREADED_CODE.
Does that have a significant impact on performance? I would normally associate
"threaded" with meaning doing things in parallel.
Could that be defined when compiling just this one file, or should it be done
when building the whole of R?
It is rather annoying that the code has __extension__ in it, which
disables the warnings about the use of GCC extensions.
http://gcc.gnu.org/onlinedocs/gcc/Alternate-Keywords.html
Why is there a need to hide the use of the extensions?
To avoid spurious warnings
I'd personally like to see just standard C used, without any
extensions. Then problems like I'm having would be less likely to occur.
This extention is very useful for implementing byte code interpreters,
which is why it is being used. As mentioned above, its use can be
turned off.
If this does solve the Solaris problem, that would be worth mentioning in the R
installation guide. I'll let you know of the result of that.
luke
Thank you for your help Luke.
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
Dave
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Does R use "computed gotos" - a gcc extension of C?
On 03/ 5/11 09:31 PM, luke-tier...@uiowa.edu wrote:
On Sat, 5 Mar 2011, Dr. David Kirkby wrote:
On 03/ 4/11 11:40 PM, luke-tier...@uiowa.edu wrote:
On Fri, 4 Mar 2011, Dr. David Kirkby wrote:
The R manual says R will not build with gcc on 64-bit Solaris x86 with
gcc
http://cran.r-project.org/doc/manuals/R-admin.html#Solaris
"Tests with gcc32 on ‘x86’ and ‘amd64’ have been less successful:
‘x86’ builds have failed on tests using complex arithmetic33, whereas
on ‘amd64’ the builds have failed to complete in several different
ways, most recently with relocation errors for libRblas.so. "
I know what the "relocation errors" problem is. That library (and in
fact two other R libraries) all have non-PIC code in them, despite the
fact the source is compiled with the -fPIC option.
http://blogs.sun.com/rie/entry/my_relocations_don_t_fit
shows how to prove this. If one runs this command on Solaris:
$ elfdump -d libRblas.so | fgrep TEXTREL
there is some output showing that theres non-PIC code present in the R
library.
R is compiled with -fPIC on Solaris, but certain things can cause
non-PIC code to be generated even with that option. One is by the use
of "computed gotos" which is a gcc extension. I'm wondering if R uses
any of these.
Yes -- in the byte code interpreter in eval.c
luke
Thank you Luke. Do you know if there may be any others?
I do not.
Do you know if that bit of code gets compiled into all 3 of the R
libraries? I tried replacing
I do not know
#define NEXT() (__extension__ ({goto *(*pc++).v;}))
by a function which did absolutely nothing. The code built, but still
had the library issues.
I'm almost certain that the definition of NEXT will cause problems,
but I'm not convinced it is the only issue.
What happens if a non-GNU compiler is used? I assume these GNU
extensions don't get used, so how comes the code builds? Is there any
way I can disable the use of the GNU extensions, while still building
with gcc.
This particular bit It only uses the gcc extensions for gcc compilers,
and this can be turned off by defining NO_THREADED_CODE.
It is rather annoying that the code has __extension__ in it, which
disables the warnings about the use of GCC extensions.
http://gcc.gnu.org/onlinedocs/gcc/Alternate-Keywords.html
Why is there a need to hide the use of the extensions?
To avoid spurious warnings
I'd personally like to see just standard C used, without any
extensions. Then problems like I'm having would be less likely to occur.
This extention is very useful for implementing byte code interpreters,
which is why it is being used. As mentioned above, its use can be
turned off.
luke
That did not solve my problem. Every single shared library that R builds has
this issue. I've no idea what the hell is causing it, though computed gotos are
known as one possible source of the problems.
Is there any way to disable all GNU extensions for all files? It might be some
other GNUim that's causing it.
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
Dave
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Failure to load the recommended package Matrix (Was: [R] Can one get a list of recommended packages?)
On 06/14/10 10:05 AM, Ei-ji Nakama wrote: And if you look at the other R-help message posted by David Kirby you will find a link to the trouble ticket report in Sage as http://trac.sagemath.org/sage_trac/ticket/9201 From the link,... | kir...@t2:[~] $ echo $LD_LIBRARY_PATH | /usr/local/gcc-4.4.1-sun-linker/lib:/usr/local/gcc-4.4.1-sun-linker/lib/sparcv9:/usr/local/lib `/usr/local/gcc-4.4.1-sun-linker/lib/sparcv9' is 64bit, it is unnecessary. I think that this obstructs it. This is not the reason. If it picked up the wrong library, then there would be a message that there was the wrong ELF class, but no library whatever is being found. I've tried without the 'sparcv9' in LD_LIBRARY_PATH and it makes no difference whatsoever. I've tried on two SPARCs too, running different releases of Solaris 10. Using 'crle' might work, but that is not really a good answer, as it needs root access. It should be possible to install an application like R without being root. There is something wrong if LD_LIBRARY_PATH can't be used to locate libraries. I can build the whole of the Sage source code (around 300 MB) and don't see this failure elsewhere. Instead, there are a number of programs which link to libgcc_s.so.1. I stuck some further information at http://trac.sagemath.org/sage_trac/ticket/9201 but it basically just confirms what I've written above. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Fail to call AC_CACHE_CHECK on R 2.7.0 for Solaris
I've tried to build R 2.6.1 and 2.7.0 on Solaris 10 update 4 (SPARC) and
both configure ok, so you might ask why I suspect there is a problem.
I tried to build the maths program Sage
http://www.sagemath.org/
version 3.0.3alpha1. Sage fails when building R 2.6.1 - (Sage includes R
in the package). The relavant bit of Sage, which is only using an
unmodified R configure script is:
checking iconv.h usability... yes
checking iconv.h presence... yes
checking for iconv.h... yes
checking for iconv... in libiconv
checking whether iconv accepts "UTF-8", "latin1" and "UCS-*"... no
checking for iconvlist... yes
configure: error: --with-iconv=yes (default) and a suitable iconv is
not available
Looking at the Sage problem in detail, I believe I know the reason and
are somewhat surprised R builds at all on Solaris. I think this problem
is an R problem, not a Sage problem.
For some reason the R "configure" script was not happy with my readline,
but after trying to configure with the configure option
--with-readline=no
The R 2.6.1 source configured ok. I did not bother running 'make' but
there were
no failures when the configure script was run. I then repeated this
with the latest version of R (2.7.0) and got similar results.
Looking at the file configure.ac in R (both 2.6.1 and 2.7.0), I see:
## iconv headers and function.
if test "${use_iconv}" = yes; then
R_ICONV
if test "$r_cv_iconv_latin1" != yes; then
AC_MSG_ERROR([--with-iconv=yes (default) and a suitable iconv is
not available])
fi
else
AC_MSG_WARN([--with-iconv=no is deprecated and will be withdrawn
shortly])
fi
Clearly the value of r_cv_iconv_latin1 determines if this test passes
or fails and so whether the error message that I get is printed or not.
The variable r_cv_iconv_latin1 is never set directly in configure, but
by in a Macro called AC_CACHE_CHECK in the file m4/R.m4.
Looking in that macro r4/R.m4 we see:
AC_CACHE_CHECK([whether iconv accepts "UTF-8", "latin1" and "UCS-
*"],
[r_cv_iconv_latin1],
So it would appear to me that AC_CACHE_CHECK needs to be run in order
that r_cv_iconv_latin will be set properly. But looking at
configure.ac, I think AC_CACHE_CHECK is only called on Linux, and not
on Solaris. Obviously this could explain why this bit of Sage works on
Linux, but not Solaris.
## check for visible __libc_stack_end on Linux
case "${host_os}" in
linux*)
AC_CACHE_CHECK([for visible __lib_stack_end],
[r_cv_libc_stack_end],
[AC_RUN_IFELSE([AC_LANG_SOURCE([[
#include "confdefs.h"
#include
extern void * __libc_stack_end;
So it seems to me this will never work, as the the relevant macro is
not run on Solaris. It begs the obvious question why does this work
when I download the source of R. I can't see the answer to that one,
but there are reports of R failing to build on Solaris, but for me at
least, it configures ok.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Fail to call AC_CACHE_CHECK on R 2.7.0 for Solaris
Prof Brian Ripley wrote:
This is covered in the 'R Installation and Administration' manual that
INSTALL asked you to read. Specifically for Solaris:
Modern Solaris systems allow a large selection of Open Source software
to be installed via @command{pkg-get}: a Sparc Solaris 10 system came
with @code{libreadline} and @code{libiconv} and a choice of @code{gcc3}
and @code{gcc4} compilers, installed under @file{/opt/csw}. (You will
need GNU @code{libiconv}: the Solaris version of @code{iconv} is not
sufficiently powerful.)
R 2.7.0 is documented to build on several versions of Solaris in that
manual, so the problem is definitely not 'R on Solaris'.
You analysis is plain wrong. Search for r_cv_iconv_latin1 in
configure and you will see three lines which set it (plus one that
checks if it was set in the cache).
Thanks a lot. Clearly when I compiled R directly, it see my GNU libiconv
rather than the Sun supplied one, but when built as part of Sage, it see
the Sun one. That should be easy to fix.
Dave
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] SHLIB_CXXLDFLAGS needs quotes on Solaris section of admin manual.
In the admin manual, there is some information about flags etc for Solaris: CC="cc -xc99" CPPFLAGS=-I/opt/csw/include CFLAGS="-O -xlibmieee" F77=f95 FFLAGS=-O4 CXX=CC CXXFLAGS=-O FC=f95 FCFLAGS=$FFLAGS LDFLAGS=-L/opt/csw/lib SHLIB_CXXLDFLAGS=-G -lCstd Where as the CC command is quoted, the SHLIB_CXXLDFLAGS one is not. Failure to put quotes around it results in configure script aborting. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] SHLIB_CXXLDFLAGS needs quotes on Solaris section of admin manual.
Dr. David Kirkby wrote: In the admin manual, there is some information about flags etc for Solaris: CC="cc -xc99" CPPFLAGS=-I/opt/csw/include CFLAGS="-O -xlibmieee" F77=f95 FFLAGS=-O4 CXX=CC CXXFLAGS=-O FC=f95 FCFLAGS=$FFLAGS LDFLAGS=-L/opt/csw/lib SHLIB_CXXLDFLAGS=-G -lCstd Where as the CC command is quoted, the SHLIB_CXXLDFLAGS one is not. Failure to put quotes around it results in configure script aborting. i.e. I think it should read: SHLIB_CXXLDFLAGS="-G -lCstd" rather than SHLIB_CXXLDFLAGS=-G -lCstd __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
