[Rd] a R_PV problem
Dear all, When using gdb to debug my C code, I use R_PV to show the content of SEXP variables: SEXP sexp; // it is a data.frame SEXP colNames = getAttrib(sexp, R_NameSymbol); A strange thing is that after halting the program: (gdb) p R_PV(colNames) does not show the content of colNames. I am positive my code is right because if I insert "PrintValue(colNames);" in the c code, it will print the right value. My debug result shows that the variable "colNames" failed the "isObject" call. I am not sure whether this is a new feature or bug. Anyone can help? Thanks, Gang Liang __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R-SIG-Mac] Starting tcltk without Tk
Simon Urbanek wrote:
It turns out that the behavior of starting just Tcl was actually a bug.
Not completely. At least, loading of tcltk was correct when the "bug"
was there, but I totally agree that the mechanism used (according to the
presence or not of the DISPLAY variable is not the best one). It is not
true that there was no intention to allow loading tcltk without Tk.
Otherwise, why would you have this (tcltk.c, tcltk_init(), line 643 in
the R 2.7.0 source):
warning(_("no DISPLAY variable so Tk is not available"));
This message strongly suggests that starting tcltk without Tk is
allowed, and it also suggests the mechanism: by eliminating the DISPLAY
environment variable before starting tcltk. It is certainly
undocumented, most probably underused, and certainly requires a better
way to specify that the user does want to load Tk,... but at least, it
worked for me up to now.
Apparently the intention was to attempt to start Tk regardless of the
DISPLAY variable, because some TclTk implementation such as Aqua Tcl/Tk
don't require DISPLAY and thus would not be loaded. Due to a bug
(HAVE_AQUA was not included in Rconfig.h before R 2.7.0), though, this
was not the case. I'll leave it to tcltk users/maintainers to decide the
right way forward. Essentially I see two options:
1) status quo: tcltk always attempts to load Tk and fails on an error
2) allow some (possibly cross-platform) way of specifying that it is ok
to not load Tk - essentially make failure to load Tk non-fatal.
I vote for the second option.
Many thanks,
Philippe
Right now there is no (semantically correct) way to inhibit the loading
of Tk (DISPLAY is a sort of abuse and not a solution).
Cheers,
Simon
(CC to R-devel where this started...)
On May 5, 2008, at 9:12 AM, Simon Urbanek wrote:
Philippe,
I'm not quite sure why you are asking on a Mac list, but the error
comes from Tcl/Tk. I'd suggest asking on R-devel, the Tcl/Tk used in
the R binary is the same for R 2.6.x and 2.7.0 so it must be a change
in tcltk.
Cheers,
Simon
On May 4, 2008, at 7:01 AM, Philippe Grosjean wrote:
Hello,
Up to R 2.6.2, I used to start Tcl *without Tk* (I need only Tcl for
some part of my work, like a socket server written in Tcl only, for
instance) with this code under Mac OS X (particularly on this system,
because I don't want to start X11 just to use Tcl code, which is
required for Tk!):
> Sys.unsetenv("DISPLAY")
> library(tcltk)
I got then the message "no DISPLAY variable so Tk is not available",
but could work with Tcl without problems.
Now, with R 2.7.0, I got the following and Tcl failed to load:
Loading Tcl/Tk interface ... Error in fun(...) : no display name and
no $DISPLAY environment variable
Error : .onLoad failed in 'loadNamespace' for 'tcltk'
Error: package/namespace load failed for 'tcltk'
I try to locate the message "no display name and no $DISPLAY
environment variable" in the code but I cannot find it. Could someone
help me please?
I understand that starting Tcl without Tk from R is not an intended
behaviour, but would it be possible to include an option to do so?
> sessionInfo()
R version 2.7.0 Patched (2008-04-22 r45460)
i386-apple-darwin8.10.1
locale:
en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
Many thanks,
Philippe Grosjean
--
..<°}))><
) ) ) ) )
( ( ( ( (Prof. Philippe Grosjean
) ) ) ) )
( ( ( ( (Numerical Ecology of Aquatic Systems
) ) ) ) ) Mons-Hainaut University, Belgium
( ( ( ( (
..
___
R-SIG-Mac mailing list
[EMAIL PROTECTED]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
___
R-SIG-Mac mailing list
[EMAIL PROTECTED]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] a R_PV problem
On 06/05/2008 3:02 AM, pseudo wrote: Dear all, When using gdb to debug my C code, I use R_PV to show the content of SEXP variables: SEXP sexp; // it is a data.frame SEXP colNames = getAttrib(sexp, R_NameSymbol); A strange thing is that after halting the program: (gdb) p R_PV(colNames) does not show the content of colNames. I am positive my code is right because if I insert "PrintValue(colNames);" in the c code, it will print the right value. My debug result shows that the variable "colNames" failed the "isObject" call. I am not sure whether this is a new feature or bug. Anyone can help? Are you sure that getAttrib has been called? Depending on the optimization level under which your code was compiled, instructions may be re-ordered. gdb may show the instruction pointer after that line, even though that line hasn't been run yet. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] a R_PV problem
2008/5/6 pseudo <[EMAIL PROTECTED]>: [...] > A strange thing is that after halting the program: > > (gdb) p R_PV(colNames) > > does not show the content of colNames. I am positive my code is right > because if I insert "PrintValue(colNames);" in the c code, it will > print the right value. Have you tried: p Rf_PrintValue(colNames) from the gdb prompt? A. -- Antonio, Fabio Di Narzo Ph.D. student at Department of Statistical Sciences University of Bologna, Italy __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] a R_PV problem
From the C code: /* Ditto, but only for objects, for use in debugging */ so R_PV only prints for 'objects' (that is those with an S3 class, and if properly formed, those with an S4 class). I doubt a set of names has a class: to print those, use Rf_PrintValue. I am not sure why one would want to confine attention to 'objects', but the code has been that way 'for ever' (8 years). On Tue, 6 May 2008, Duncan Murdoch wrote: On 06/05/2008 3:02 AM, pseudo wrote: Dear all, When using gdb to debug my C code, I use R_PV to show the content of SEXP variables: SEXP sexp; // it is a data.frame SEXP colNames = getAttrib(sexp, R_NameSymbol); A strange thing is that after halting the program: (gdb) p R_PV(colNames) does not show the content of colNames. I am positive my code is right because if I insert "PrintValue(colNames);" in the c code, it will print the right value. My debug result shows that the variable "colNames" failed the "isObject" call. I am not sure whether this is a new feature or bug. Anyone can help? Are you sure that getAttrib has been called? Depending on the optimization level under which your code was compiled, instructions may be re-ordered. gdb may show the instruction pointer after that line, even though that line hasn't been run yet. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R-SIG-Mac] Starting tcltk without Tk
On May 6, 2008, at 3:06 AM, Philippe Grosjean wrote:
Simon Urbanek wrote:
It turns out that the behavior of starting just Tcl was actually a
bug.
Not completely. At least, loading of tcltk was correct when the
"bug" was there, but I totally agree that the mechanism used
(according to the presence or not of the DISPLAY variable is not the
best one). It is not true that there was no intention to allow
loading tcltk without Tk. Otherwise, why would you have this
(tcltk.c, tcltk_init(), line 643 in the R 2.7.0 source):
warning(_("no DISPLAY variable so Tk is not available"));
This message strongly suggests that starting tcltk without Tk is
allowed, and it also suggests the mechanism: by eliminating the
DISPLAY environment variable before starting tcltk. It is certainly
undocumented, most probably underused, and certainly requires a
better way to specify that the user does want to load Tk,... but at
least, it worked for me up to now.
Philippe, you missed the one important line - please read the whole
code - there is
#if !defined(Win32) && !defined(HAVE_AQUA)
before that and that is the crucial part.
Cheers,
Simon
Apparently the intention was to attempt to start Tk regardless of
the DISPLAY variable, because some TclTk implementation such as
Aqua Tcl/Tk don't require DISPLAY and thus would not be loaded. Due
to a bug (HAVE_AQUA was not included in Rconfig.h before R 2.7.0),
though, this was not the case. I'll leave it to tcltk users/
maintainers to decide the right way forward. Essentially I see two
options:
1) status quo: tcltk always attempts to load Tk and fails on an error
2) allow some (possibly cross-platform) way of specifying that it
is ok to not load Tk - essentially make failure to load Tk non-fatal.
I vote for the second option.
Many thanks,
Philippe
Right now there is no (semantically correct) way to inhibit the
loading of Tk (DISPLAY is a sort of abuse and not a solution).
Cheers,
Simon
(CC to R-devel where this started...)
On May 5, 2008, at 9:12 AM, Simon Urbanek wrote:
Philippe,
I'm not quite sure why you are asking on a Mac list, but the error
comes from Tcl/Tk. I'd suggest asking on R-devel, the Tcl/Tk used
in the R binary is the same for R 2.6.x and 2.7.0 so it must be a
change in tcltk.
Cheers,
Simon
On May 4, 2008, at 7:01 AM, Philippe Grosjean wrote:
Hello,
Up to R 2.6.2, I used to start Tcl *without Tk* (I need only Tcl
for some part of my work, like a socket server written in Tcl
only, for instance) with this code under Mac OS X (particularly
on this system, because I don't want to start X11 just to use Tcl
code, which is required for Tk!):
> Sys.unsetenv("DISPLAY")
> library(tcltk)
I got then the message "no DISPLAY variable so Tk is not
available", but could work with Tcl without problems.
Now, with R 2.7.0, I got the following and Tcl failed to load:
Loading Tcl/Tk interface ... Error in fun(...) : no display name
and no $DISPLAY environment variable
Error : .onLoad failed in 'loadNamespace' for 'tcltk'
Error: package/namespace load failed for 'tcltk'
I try to locate the message "no display name and no $DISPLAY
environment variable" in the code but I cannot find it. Could
someone help me please?
I understand that starting Tcl without Tk from R is not an
intended behaviour, but would it be possible to include an option
to do so?
> sessionInfo()
R version 2.7.0 Patched (2008-04-22 r45460)
i386-apple-darwin8.10.1
locale:
en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods
base
Many thanks,
Philippe Grosjean
--
..<°}))><
) ) ) ) )
( ( ( ( (Prof. Philippe Grosjean
) ) ) ) )
( ( ( ( (Numerical Ecology of Aquatic Systems
) ) ) ) ) Mons-Hainaut University, Belgium
( ( ( ( (
..
___
R-SIG-Mac mailing list
[EMAIL PROTECTED]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
___
R-SIG-Mac mailing list
[EMAIL PROTECTED]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] a R_PV problem
On Tue, 6 May 2008, Duncan Murdoch wrote:
> On 06/05/2008 3:02 AM, pseudo wrote:
> > Dear all,
> >
> > When using gdb to debug my C code, I use R_PV to show the content of
> > SEXP variables:
> >
> > SEXP sexp; // it is a data.frame
> > SEXP colNames = getAttrib(sexp, R_NameSymbol);
> >
> > A strange thing is that after halting the program:
> >
> > (gdb) p R_PV(colNames)
> >
> > does not show the content of colNames. I am positive my code is right
> > because if I insert "PrintValue(colNames);" in the c code, it will
> > print the right value. My debug result shows that the variable
> > "colNames" failed the "isObject" call. I am not sure whether this is a
> > new feature or bug. Anyone can help?
>
> Are you sure that getAttrib has been called? Depending on the
> optimization level under which your code was compiled, instructions may
> be re-ordered. gdb may show the instruction pointer after that line,
> even though that line hasn't been run yet.
R_PV(sexp) only prints if isObject(sexp) is true, i.e., if it
is "internally classed". Try using Rf_PrintValue(colNames) from
the debugger.
src/main/print.c contains:
/* Print an S-expression using global options */
void PrintValue(SEXP s)
{
PrintValueEnv(s, R_GlobalEnv);
}
/* Ditto, but only for objects, for use in debugging */
void R_PV(SEXP s)
{
if(isObject(s)) PrintValueEnv(s, R_GlobalEnv);
}
and include/Internals.h has the usual add-Rf_ #define:
#define PrintValue Rf_PrintValue
Bill Dunlap
Insightful Corporation
bill at insightful dot com
360-428-8146
"All statements in this message represent the opinions of the author and do
not necessarily reflect Insightful Corporation policy or position."
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] a R_PV problem
On Tue, May 6, 2008 at 5:23 AM, Antonio, Fabio Di Narzo <[EMAIL PROTECTED]> wrote: > 2008/5/6 pseudo <[EMAIL PROTECTED]>: > [...] > > > A strange thing is that after halting the program: > > > > (gdb) p R_PV(colNames) > > > > does not show the content of colNames. I am positive my code is right > > because if I insert "PrintValue(colNames);" in the c code, it will > > print the right value. > Have you tried: > p Rf_PrintValue(colNames) > from the gdb prompt? > Yes, I also tried "p Rf_PrintValue(colNames)", the outcome is the same. I can step in the r-base-core and what I found is that the "isObject" returns false. > A. > -- > Antonio, Fabio Di Narzo > Ph.D. student at > Department of Statistical Sciences > University of Bologna, Italy > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] a R_PV problem
On Tue, May 6, 2008 at 1:46 AM, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > > On 06/05/2008 3:02 AM, pseudo wrote: > > > Dear all, > > > > When using gdb to debug my C code, I use R_PV to show the content of > > SEXP variables: > > > > SEXP sexp; // it is a data.frame > > SEXP colNames = getAttrib(sexp, R_NameSymbol); > > > > A strange thing is that after halting the program: > > > > (gdb) p R_PV(colNames) > > > > does not show the content of colNames. I am positive my code is right > > because if I insert "PrintValue(colNames);" in the c code, it will > > print the right value. My debug result shows that the variable > > "colNames" failed the "isObject" call. I am not sure whether this is a > > new feature or bug. Anyone can help? > > > > Are you sure that getAttrib has been called? Depending on the optimization > level under which your code was compiled, instructions may be re-ordered. > gdb may show the instruction pointer after that line, even though that line > hasn't been run yet. > Yes, the getAttrib is called because the optimization is turned off. Gang __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] [BioC] RCurl loading problem with 64 bit linux distribution
Let's move this to R-devel. It's programming (not even R programming), and getting complex. One crucial issue issue is how you installed R -- from sources or as a binary. Also, I am assuming that this is x86_64 (there are other '64-bit' Linuxen). Library paths are determined by LD_LIBRARY_PATH, amongst other things (and not by PATH on Linux). With R built from the sources, this will include /usr/local/lib64, but I believe that for a binary build it does not -- look in R_HOME/etc/ldpaths to see. Also, you seem to have compiled curl to be in /usr/local/lib -- if this is an x86_64 system that might well not be found -- it is not where R's paths look. (It's a common issue with compiling autoconf-ed packages -- you need to set --libdir=/usr/local/lib64, say.) RCurl uses pkg_config to to find libcurl, and that does not by default look in /usr/local. So it is likely that it looked at the Ubuntu version and not the one you installed. I don't think that curl 7.18.1 is enough of an improvement to make all these hassles worthwhile -- I would do a 'make uninstall' on your own version. DTL and I have been having some private correspondence about this. At present RCurl_0.9-1 still segfaults for me because the configure detection isn't detecting (this is F8, curl 7.17.1). If you can, I'd wait until that is resolved. I have installed RCurl_0.8-3 for 'production' use. (It is still up at http://www.omegahat.org/RCurl/RCurl_0.8-3.tar.gz, it not obvious on the web pages.) On Wed, 7 May 2008, Mark Kimpel wrote: Duncan, I know have two version of libcurl on my system, the Ubuntu installed 7.18.0 and my newly compiled from source 7.18.1 (which I installed after my problems began with RCurl). I was afraid to uninstall 7.18.0 because Synaptic wanted to uninstall half of my system if I did so via my package manger. I must not have my PATH set up correctly because when I do curl --version, I get: curl 7.18.1 (x86_64-unknown-linux-gnu) libcurl/7.18.0 OpenSSL/0.9.8g zlib/ 1.2.3.3 libidn/1.1 Protocols: tftp ftp telnet dict ldap ldaps http file https ftps Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz So curl is new and libcurl is a version older. This probably isn't ideal, but may help us figure out what is going on because I ran nm against both versions of libcurl for libcurl 7.18.1: mkimpel-m90 /usr/local/lib: nm libcurl.so | grep Curl_base64_encode 9e30 T Curl_base64_encode for libcurl 7.18.0 mkimpel-m90 /usr/lib: nm libcurl.so | grep Curl_base64_encode nm: libcurl.so: no symbols That doesn't help, because Linux distros strip symbols. it looks like RCurl is still trying to link against 7.18.0, but, do I interpret your comments to mean that, if I set up my PATH correctly so that the newer version is found first, things might work? Regardless, I hope this is somewhat diagnostic. If I have screwed up the setup too much to make sense out of, perhaps one of the other guys with problems could also furnish the info. BTW, I did cc you on my post to R-help this evening (see below). Thanks for your help and all your development efforts, Mark romMark Kimpel <[EMAIL PROTECTED]>toLoyal Goff <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED], dateTue, May 6, 2008 at 9:18 PM On Wed, May 7, 2008 at 12:43 AM, Duncan Temple Lang <[EMAIL PROTECTED]> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all ~ I'm glad this made it to R-help (or R-devel) so that I saw it as this is the sort of problem that should be at least CC'ed to the package maintainer. ~ Yes, there was a change to RCurl yesterday with one of the changes being to synchronize code between libcurl and RCurl regarding base64 encoding which was causing a segfault with recent versions of libcurl. ~ The latest RCurl does not include the code for the Curl_base64_encode which was in the curl_base64.c file. The intent was to link against the on in libcurl, but what your reports suggest is that one some systems this is not available from libcurl.so. Can you confirm this with the nm output from libcurl.so ~nm libcurl.so | grep Curl_base64_encode Precisely where libcurl.so (or libcurl.so) will vary, but it is probably in /usr/local/lib/ and you can see by using ~curl-config --libs and seeing if there is -L in the output which will tell you where it is likely to be. If the symbol (Curl_base64_encode) is not there, there will be no output! ~ If that is the case, we will have to back to having our own copy of that routine and so we will end up with two versions - one for the old and one for the new and the configuration will endeavor to determine which is appropriate. ~ HTH ~ D. Mark Kimpel wrote: | Martin, | | Well, thanks for jumping in! We need all the help we can get ;) | | I changed the execute bit as you suggested and recompiled, no luck, still | the same error message. | | Below is the output you wanted me to look at, its a bit beyond me so I | include both a brie
Re: [Rd] [R] [BioC] RCurl loading problem with 64 bit linux distribution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Prof Brian Ripley wrote: | Let's move this to R-devel. It's programming (not even R programming), | and getting complex. | Indeed! | One crucial issue issue is how you installed R -- from sources or as a | binary. Also, I am assuming that this is x86_64 (there are other '64-bit' | Linuxen). | | Library paths are determined by LD_LIBRARY_PATH, amongst other things | (and not by PATH on Linux). With R built from the sources, this will | include /usr/local/lib64, but I believe that for a binary build it does | not -- look in R_HOME/etc/ldpaths to see. | | Also, you seem to have compiled curl to be in /usr/local/lib -- if this | is an x86_64 system that might well not be found -- it is not where R's | paths look. (It's a common issue with compiling autoconf-ed packages -- | you need to set --libdir=/usr/local/lib64, say.) | | RCurl uses pkg_config to to find libcurl, and that does not by default Not quite. It uses curl-config. We could move to a two tier system of using pkg-config and then curl-config, but that hasn't been necessary yet. | look in /usr/local. So it is likely that it looked at the Ubuntu | version and not the one you installed. | | I don't think that curl 7.18.1 is enough of an improvement to make all | these hassles worthwhile -- I would do a 'make uninstall' on your own | version. | | DTL and I have been having some private correspondence about this. At | present RCurl_0.9-1 still segfaults for me because the configure | detection isn't detecting (this is F8, curl 7.17.1). If you can, I'd | wait until that is resolved. I have installed RCurl_0.8-3 for | 'production' use. (It is still up at | http://www.omegahat.org/RCurl/RCurl_0.8-3.tar.gz, it not obvious on the | web pages.) | All previous versions are also available from the www.omegahat.org/R source repository. ~ D. | | On Wed, 7 May 2008, Mark Kimpel wrote: | |> Duncan, |> |> I know have two version of libcurl on my system, the Ubuntu installed |> 7.18.0 |> and my newly compiled from source 7.18.1 (which I installed after my |> problems began with RCurl). I was afraid to uninstall 7.18.0 because |> Synaptic wanted to uninstall half of my system if I did so via my package |> manger. I must not have my PATH set up correctly because when I do curl |> --version, I get: |> |> curl 7.18.1 (x86_64-unknown-linux-gnu) libcurl/7.18.0 OpenSSL/0.9.8g |> zlib/ |> 1.2.3.3 libidn/1.1 |> Protocols: tftp ftp telnet dict ldap ldaps http file https ftps |> Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz |> |> So curl is new and libcurl is a version older. This probably isn't ideal, |> but may help us figure out what is going on because I ran nm against both |> versions of libcurl |> |> for libcurl 7.18.1: |> mkimpel-m90 /usr/local/lib: nm libcurl.so | grep Curl_base64_encode |> 9e30 T Curl_base64_encode |> |> for libcurl 7.18.0 |> mkimpel-m90 /usr/lib: nm libcurl.so | grep Curl_base64_encode |> nm: libcurl.so: no symbols | | That doesn't help, because Linux distros strip symbols. | |> it looks like RCurl is still trying to link against 7.18.0, but, do I |> interpret your comments to mean that, if I set up my PATH correctly so |> that |> the newer version is found first, things might work? |> |> Regardless, I hope this is somewhat diagnostic. If I have screwed up the |> setup too much to make sense out of, perhaps one of the other guys with |> problems could also furnish the info. |> |> BTW, I did cc you on my post to R-help this evening (see below). |> |> Thanks for your help and all your development efforts, |> Mark |> |> |> romMark Kimpel <[EMAIL PROTECTED]>toLoyal Goff <[EMAIL PROTECTED]>, |> [EMAIL PROTECTED], |> [EMAIL PROTECTED], |> dateTue, May 6, 2008 at 9:18 PM |> |> |> On Wed, May 7, 2008 at 12:43 AM, Duncan Temple Lang |> <[EMAIL PROTECTED]> |> wrote: |> | | Hi all | | ~ I'm glad this made it to R-help (or R-devel) so that I saw it | as this is the sort of problem that should be at least CC'ed to the | package maintainer. | | ~ Yes, there was a change to RCurl yesterday with one of the changes | being to synchronize code between libcurl and RCurl regarding base64 | encoding | which was causing a segfault with recent versions of libcurl. | | ~ The latest RCurl does not include the code for the Curl_base64_encode | which was in the curl_base64.c file. The intent was to link against | the on in libcurl, but what your reports suggest is that one some | systems this is not available from libcurl.so. Can you confirm this with | the nm output from libcurl.so | | ~nm libcurl.so | grep Curl_base64_encode | | Precisely where libcurl.so (or libcurl.so) will vary, | but it is probably in /usr/local/lib/ and you can see | by using | | ~curl-config --libs | and seeing if there is -L in the output which will | tell you where it is likely to be. | | If the symbol (Curl_base64_encode) is not there, there will be no | output! | | | ~ If that is the case, we
