Re: [Rd] Linux distribution with gcc 4.8 and AddressSanitizer ?
On Thursday 18 April 2013 17:38:06 Thomas Petzoldt wrote: Dear R developers, I've got an information from Prof. Ripley regarding a bug found with AdressSanitizer in one of our packages. It is now fixed, thank you for this information. Now, I would like to run AddressSanitizer myself before submitting the patched package to CRAN. Is there a recommendation of a suitable Linux distribution with gcc 4.8, ideally an ISO image or (even better) a virtual appliance for VMware or VirtalBox? My Debian Wheezy machines have only 4.7.2. Thank you Thomas Petzoldt I am not sure about all the requisites above (regarding the virtual appliances although I know that they are available) but Fedora 19 (Alpha) that will be released today has gcc 4.8. Even although it has the Alpha moniker, and the corresponding stage, it is relatively stable and thus suitable for your requirements. Regards, -- José Abílio __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Using \u2030 in plot axis label - stack smashing
On 19/09/06, Prof Brian Ripley [EMAIL PROTECTED] wrote: Apparently FC6 will have different flags/ different default behaviour, at least for ld. Just for reference I have tested the default CFLAGS in FC-5 and FC-6. They are equal, namely: CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 this is common to all three supported archs, i386, x86_64 and ppc. (There is in addition an architecture specfic part after) Regarding the linker you are right as is discussed in the draft notes for FC6 release: http://fedora.redhat.com/docs/release-notes/fc6test2/#id3068132 -- José Abílio __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Build directory path saved in Meta/hsearch.rds
On 04/03/06, Prof Brian Ripley [EMAIL PROTECTED] wrote: I've made two changes for R 2.3.0 1) as the LibPath is not actually used, it is recorded as . (For compatibility we don't want to remove the field.) Since it was returned but not printed by help.search(), the actual installed path is returned instead. (Given that the return format of help.search is undocumented, I don't see how anyone could have made use of it without realizing it was subject to guesswork and to change.) 2) hsearch.rds could usefully be stored in compressed format, and so will be. I would like to thank you and Dirk for your answers (and Peter Daalgard FWIW :-). My concern was that R could use that path in some way. Usually this is not a problem because as Brian clearly told that path will be inexistent, the problem would exist if this temporary path could be exploited maliciously to inject code into R. I hope that these concerns don't sound too far fetched since sometimes the temporary directories are world writable. Thank you for the change, I am glad to see that this will be addressed for 2.3. Best regards, -- José Abílio __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] script to create rpm spec files from CRAN packages
Hi, I hope this is the right list to do this announcement. In order to facilitate my work submiting R packages to Fedora Extras I have create a python script that takes a CRAN package (tar.gz file) and from there it prints a first draft for a spec file. This script follows the Fedora conventions for rpms but I hope that with small changes this can be helpfull for other people. The script (released under GPL2) can be found here: http://www.fc.up.pt/pessoas/jamatos/R/cran2rpmspec All comments are welcome. :-) -- José Matos __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Build directory path saved in Meta/hsearch.rds
Hi,
in Fedora Extras we build R packages to a temporary directory. The
relevant section in
the spec file is this:
%build
cd ..; R CMD INSTALL %{packname} -l %{buildroot}%{_libdir}/R/library
It works. :-)
We noticed one problem though (I will assume working on ix86 here) the
temporary build path is saved in
/usr/lib/R/library/*/Meta/hsearch.rds, i.e. for each package.
To see this is enough to run strings over these file.
Is this a security concern? Does R uses this path in any way?
In case the answer is yes, it is safe to run sed over this file and do
a textual replacement?
Thanks and best regards,
--
José Matos
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Build directory path saved in Meta/hsearch.rds
On 03/03/06, José Matos [EMAIL PROTECTED] wrote:
Hi,
in Fedora Extras we build R packages to a temporary directory. The
relevant section in
the spec file is this:
%build
cd ..; R CMD INSTALL %{packname} -l %{buildroot}%{_libdir}/R/library
It works. :-)
We noticed one problem though (I will assume working on ix86 here) the
temporary build path is saved in
/usr/lib/R/library/*/Meta/hsearch.rds, i.e. for each package.
Searching a little bit more I see that Peter Daalgard came to the
same conclusion one month ago:
https://stat.ethz.ch/pipermail/r-help/2006-February/086069.html
To see this is enough to run strings over these file.
Is this a security concern? Does R uses this path in any way?
In case the answer is yes, it is safe to run sed over this file and do
a textual replacement?
Thanks and best regards,
--
José Matos
--
José Abílio
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Post processing need for installing packages in rpms.
Hello,
I maintain some packages in Fedora Extras for R related modules.
Until R 2.2.0 I used for post processing (both after installing and
removing the package) the following lines:
%{_bindir}/R CMD perl %{_libdir}/R/share/perl/build-help.pl --htmllists
cat %{_libdir}/R/library/*/CONTENTS %{_libdir}/R/doc/html/search/index.txt
Typically %{_bindir} is /usr/bin and %{_libdir} is /usr/lib or
/usr/lib64
The purpose of those lines is to enable the access to the module
documentation from R help. The first refers to html and the second to the
text help variant.
With R 2.2.0 build-help.pl no longer has the --htmllists option. Is
there any easy replacement, or is there any other method to achieve the same
results?
FWIW, I have searched trough the release notes as well as through the
documentation for sys admins and for package developers without any
success.
Best regards,
--
José Abílio
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Post processing need for installing packages in rpms.
Prof Brian Ripley wrote:
On Tue, 11 Oct 2005, [UTF-8] José Matos wrote:
Hello,I maintain some packages in Fedora Extras for R related
modules.
Until R 2.2.0 I used for post processing (both after installing
andremoving the package) the following lines:
%{_bindir}/R CMD perl %{_libdir}/R/share/perl/build-help.pl
--htmllistscat %{_libdir}/R/library/*/CONTENTS
%{_libdir}/R/doc/html/search/index.txt
Typically %{_bindir} is /usr/bin and %{_libdir} is /usr/lib
or/usr/lib64 The purpose of those lines is to enable the access to
the moduledocumentation from R help. The first refers to html and
the second to thetext help variant. With R 2.2.0 build-help.pl no
longer has the --htmllists option. Isthere any easy replacement,
or is there any other method to achieve the sameresults?
It is no longer needed: the information is now built by R at runtime.
It is good to know that. My work becomes easier now. :-)
FWIW, I have searched trough the release notes as well as through
thedocumentation for sys admins and for package developers without
anysuccess.
For an outsider it might not be obvious that the NEWS entry
o R_HOME/doc/html/packages.html is now remade by R not Perl code.
This may result in small changes in layout and a change in
encoding (to UTF-8 where supported).
refers to this. (Note that build-help.pl --htmllists was never documented
as part of R's API.)
Actually I notice that line, it looked suspicious but then I got
distracted by the last sentence and I have focused on the layout changes.
A posteriori it is easy to justify most of our failures. :-)
I checked Martyn Plummer's R.spec on CRAN, but that is out-of-date.
Please look at the R.spec in his current SRPM, which works for me.
Where do I get it?
I checked the spec files in
http://cran.at.r-project.org/bin/linux/redhat/SRPMS/R.spec
http://cran.at.r-project.org/bin/linux/redhat/SRPMS/R-2.2.0-2.fc3.src.rpm
since they have different dates, and they both show the same line with the
--htmlists parameter:
# Update package indices
%{_bindir}/R CMD perl %{_libdir}/R/share/perl/build-help.pl --htmllists
/dev/null 2/dev/null
[Last line was wrapped by my email composer.]
--
José Abílio
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] looks in liblapack.a not liblapack.so
Peter Dalgaard wrote:
Hmm. Doesn't look like it is actually working, though. Install
lapack-devel, configure --with-lapack, and make check dies with
running code in 'base-Ex.R' ...make[4]: *** [base-Ex.Rout] Error 1
make[4]: Leaving directory `/home/pd/r-devel/BUILD/tests/Examples'
make[3]: *** [test-Examples-Base] Error 2
[EMAIL PROTECTED] BUILD]$ tail tests/Examples/base-Ex.Rout.fail
kappa(x2 - cbind(x1,2:11))# high! [x2 is singular!]
[1] 8.351867e+16
hilbert - function(n) { i - 1:n; 1 / outer(i - 1, i, +) }
sv9 - svd(h9 - hilbert(9))$ d
kappa(h9)# pretty high!
[1] 728289254735
kappa(h9, exact = TRUE) == max(sv9) / min(sv9)
Error in La.svd(x, nu, nv) : BLAS/LAPACK routine 'DGEBRD' gave error code
-10 Execution halted
This happens on both x86_64 and x86 installs of FC4.
I am sorry Peter, I am trying really hard to replicate this bug but I have
not been able to see the same result, no matter what I try.
I have download the latest tar ball and then I run:
$ ./configure --with-lapack=-llapack -lblas
...
R is now configured for x86_64-unknown-linux-gnu
Source directory: .
Installation directory:/usr/local
C compiler:gcc -g -O2
C++ compiler: g++ -g -O2
Fortran compiler: gfortran -g -O2
Interfaces supported: X11
External libraries:readline
Additional capabilities: PNG, JPEG, iconv, MBCS, NLS
Options enabled: R profiling
Recommended packages: yes
$ make -j8
$ make check
It works.
OTOH I am not sure that configure is accepting my options. Looking into
config.log I don't see that value being used, and I noticed that the lapack
module it is still being built.
I read docs/manual/R-admin.html but without any difference. I have tried
different forms:
--with-lapack
--with-lapack=-llapack -lcblas
--with-lapack=-llapack -lblas
What am I missing?
I have a strong sense of deja vu regarding this error.
Thanks,
--
José Abílio
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] looks in liblapack.a not liblapack.so
Peter Dalgaard wrote: -L/usr/lib64 I think. I have #LAPACK_LIBS=-L/usr/lib64 -llapack (commented out now) in config.site. I'm sorry, it was my mistake. I forgot to install blas-devel where libblas.so is defined as a symbolic link to the correct library version. Since the configure script could not find the blas library it would immediately disallow the lapack usage. This is not obvious from configure's output... maybe an explicit message saying this would help here. So now it is enough ../R/configure --with-lapack :-) ../R/configure --with-lapack=-L/usr/lib64 -llapack seems to work with FC4/Opteron (even with the configure line, you still need to have at least --with-lapack on the command line, which is a bit of a bug -- or will be one, once we stop advising against using external lapack libs in the first place...). A line like External libraries:readline, BLAS(ATLAS), LAPACK(generic) Yes, I get this. For now I have BLAS(generic). shows that R is not using the internal versions of BLAS/LAPACK. (Of course, the ATLAS bit required more work...) The latest updates to lapack seem not to have worked. You are right, I am able to reproduce the bug. I will report it and report back when a solution is available. O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 Thanks, -- José Abílio __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] looks in liblapack.a not liblapack.so
Peter Dalgaard wrote: Prof Brian Ripley wrote: BTW, I don't understand how a Linux distro can supply ATLAS tuned to my CPU/FPU. Dr Goto has had about ten versions of his optimized BLAS covering just a small subset of i686 CPUs. So although a distro's ATLAS may be better than a generic BLAS, it seems that it is likely to be suboptimal, and perhaps disastrous (I've seen that with mobile Pentium chips using ATLAS tuned on desktop machines). So the recommendation must remain to tune ATLAS on your specific hardware. I don't think an RPM is restricted to contain only one version of the binaries, so in principle, the post-installer could adapt the installed version to your hardware, if it could narrow the choice down to a dozen versions or so. It's not easy though, since not only the CPU/FPU types factor in, but also cache sizes and memory speeds. Peter is right here. We can have rpms for i386, i486, i586, i686, athlon, ... One example of this kind of package is the kernel, but most applications the optimizations does not matter. The few packages shipped in Fedora Core who follow this scheme (and just for few subarchitecture, not for all) are: - kernel related - glibc - openssl The other possibility (orthogonal with the previous) is to ship the libraries optimized for different cpu features, like gmp (GNU arbitrary precision library) does: $ rpm -ql gmp-4.1.4-6.i386 /usr/lib/libgmp.so.3 /usr/lib/libgmp.so.3.3.3 /usr/lib/libgmpxx.so.3 /usr/lib/libgmpxx.so.3.0.5 /usr/lib/libmp.so.3 /usr/lib/libmp.so.3.1.7 /usr/lib/sse2/libgmp.so.3 /usr/lib/sse2/libgmp.so.3.3.3 /usr/lib/sse2/libgmpxx.so.3 /usr/lib/sse2/libgmpxx.so.3.0.5 /usr/lib/sse2/libmp.so.3 /usr/lib/sse2/libmp.so.3.1.7 and for 64 bits: $ rpm -ql gmp-4.1.4-6.x86_64 /usr/lib64/libgmp.so.3 /usr/lib64/libgmp.so.3.3.3 /usr/lib64/libgmpxx.so.3 /usr/lib64/libgmpxx.so.3.0.5 /usr/lib64/libmp.so.3 /usr/lib64/libmp.so.3.1.7 As I have told above usually this only applies to very few packages where performance is really important. Clearly this description fits to atlas. :-) -- José Abílio __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] looks in liblapack.a not liblapack.so
Martyn Plummer wrote: Fedora have just split off a separate lapack-devel package containing the static library and the symlink liblapack.so. (Mandrake/Mandriva has been doing this for some time. I don't know about SuSE). The up2date service will recognize that it needs to update lapack, but I guess that it won't install lapack-devel, as it doesn't know you need it. You are right. It might have been better to do this in the next release, rather than as an update to FC4, but there you go. Better install lapack-devel manually. lapack belongs to Extras and not to Core. Extras is a rolling release. The change was necessary to allow atlas to compile and interact with lapack. atlas is on the queue to Fedora Extras, it is in the review phase now. -- José Abílio __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
