Dear Johannes: Thank you for sending the link to "pythoninr". Looking at the page, under "Windows" there is the statement "One obviously needs to have R and Python installed." Our goal is to create a package which does not require that the user install Python prior to installing the R package. The use of Python should be seamless/invisible to the user. So pythoninr may be an interesting alternative to rPython/rPython-win but (based on my read of the documentation) it doesn't get me closer to the solution of embedding Python within the R package. Again, thanks for the reference, which I had not seen previously. Best, Bruce Hoff Sage Bionetworks
On Mon, Feb 29, 2016 at 11:16 PM, Johannes Ranke <jra...@uni-bremen.de> wrote: > Bruce, > > maybe you want to also have a look at PythonInR, which solves a similar, if > not the same, problem > > https://bitbucket.org/Floooo/pythoninr/ > > Johannes > > Am Montag, 29. Februar 2016, 13:01:06 schrieb Bruce Hoff: > > I am trying to create a self-contained R package wrapping Python that > works > > cross platform and have not been able to do this on Windows. There is > > already an R package which calls Python, requiring Python to be installed > > on the target machine: https://github.com/cjgb/rPython-win. When the R > > package is built it successfully links to the resident Python dll. > > > > I retrieved the Python source code plus associated Visual Studio projects > > as described here: https://docs.python.org/devguide/setup.html I ran > the > > Python 3.6 build and verified that rPython-win can link to the generated > > dll, as expected. In order to make a portable, self-contained R > package, I > > changed the build to create a _static_ Python library as described in the > > file PCbuild\readme.txt. This creates a 31MB file "python36.lib" but > when > > I try to build the rPython-win package under R i386 (and using the latest > > RTools) I get: > > > > gcc -m32 -shared -s -static-libgcc -o rPython.dll tmp.def pycall.o > > -LC:/cpython/PCbuild/win32 -lpython3stub -lpython36 > > -Ld:/RCompile/r-compiling/local/local323/lib/i386 > > -Ld:/RCompile/r-compiling/local/local323/lib > > -LC:/PROGRA~1/R/R-32~1.3/bin/i386 -lR > > C:/cpython/PCbuild/win32/python36.lib: *error adding symbols: File format > > not recognized* > > collect2.exe: error: ld returned 1 exit status > > no DLL was created > > ERROR: compilation failed for package 'rPython' > > > > I see some mention of the link error here: > > https://sourceware.org/bugzilla/show_bug.cgi?id=17910 > > It looks like a related bug was in binutils 2.25 on 2/27/2015. It seems > > like the fix would have made it into Rtools 3.3 since: > > 1) this page suggests that the aforementioned was resolved before the > > latest release of binutils, 2.25.1, 9/15/2015: > > https://sourceforge.net/projects/mingw/files/MinGW/Base/binutils/ > > 2) Installing Rtools 3.3, one can see that the binaries which are part of > > binutils (like ld.exe) are dated 9/22/2015. > > > > I don't know if MinGW is 'buggy', if I'm doing something wrong, and/or > what > > to do to fix the link error. > > > > Is there anyone on this list with experience linking an R package to a > > static library built on Windows using Visual Studio? > > > > Any suggestions are appreciated! > > > > [[alternative HTML version deleted]] > > > > ______________________________________________ > > R-package-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-package-devel > -- > PD Dr. Johannes Ranke > Kronacher Str. 8 > 79639 Grenzach-Wyhlen > [[alternative HTML version deleted]] ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
